I'd stay clear of option #1 as a) you can't change your e-mail address and
b) if someone hijacks your notifications *before* you sign up yourself,
you're screwed!
Option #2 sounds good, though. Easier to implement on both ends!
My system was designed for when you can't trust the second server (in my
case the search engine, in your case the comment server) with your RCS
password, but in your case you run both servers, so giving one's password to
the other isn't a risk.
(In addition, option #2 makes it easier for us to implement for PyCS, as we
can just get PyCS to support the manila.radioHosting.setPrefs() function and
it can verify the RCS password directly :)
Cheers,
Phil
> Yes -- this makes sense.
>
> It's a bit more complicated than I'd hoped for however. The two other
> possible solutions I'm thinking of are:
>
> 1. Have Manila only accept the email address sent with the first
> setPrefs request. This would prevent someone from hijacking email
> notifications once a given usernum has been registered.
>
> 2. Have Radio send the MD5 hash of the user's RCS password in the
> setPrefs call along with information needed to call RCS via XML-RPC.
> Manila then makes an XML-RPC call to RCS to verify that the
> usernum/MD5-password pair is valid. If RCS says "ok", then we set the
> prefs.
something i just posted to radio-dev; copying it here for the record:
> Thanks for the input. Do you have any particular ideas in mind for how
> to authenticate, keeping in mind that Manila doesn't know anything
> about the community server the user is associated with?
>
> I have a couple of ideas, but would like to get your input first.
I implemented something for Python Community Server a while ago that isn't
being used yet (the idea is that you'd use it to authenticate to a search
engine that handles search for the community server).
Two new XML-RPC methods to go on the community server:
identity.getToken(usernum, password, reason)
returns a struct with a member 'flError' that indicates success, and 'token'
that contains an opaque token (some string -- I use the sha1 or md5 hash of
some random number). The server also stores the token, usernum and reason
in a table.
identity.validateToken(token)
returns a struct with a member 'flError' to indicate if something got messed
up on the server, 'flValid' to indicate if the token is valid, and if the
token _is_ valid, 'usernum' and 'reason' that contain the usernum & reason
values passed to getToken().
Tokens are deleted from the server when validated or 10 minutes after
generation (whichever comes first).
So... the process of authenticating yourself to the comment server would be:
USER: get token from community server with reason 'id for comment
notification change'
USER: call manila.radioHosting.setPrefs on comment server, giving it the
token as well as usernum and data
COMMENT SERVER: validate token with community server. if it validates, make
sure the usernums match and the reason is 'id for comment notification
change', and if so, change the notification data.
i.e.:
USER: token = community_server.identity.getToken(usernum, password, 'id for
comment server')
USER: comment_server.manila.radioHosting.setPrefs(token, usernum, data)
COMMENT SERVER: x = community_server.validateToken(token)
if not x.flValid: fail
if x.reason != 'id for comment server': fail
if x.usernum != usernum: fail
update user data
Make sense?
BTW we've been talking about this on the PyCS mailing list as well; in PyCS
the comments are served by the main community server. What would be really
good for us would be if Radio could pass the value of
flCommentNotificationEnabled in the struct sent to xmlStorageSystem.ping(),
as that would shortcut this whole thing in that case.
Cheers,
Phil :)
Yeah, and at the moment it has a serious security problem in that there are
no passwords anywhere, so I wouldn't suggest cloning this particular
interface any time soon!
I've posted a response to Jake's RPC, so let's see what happens there.
For PyCS it would be easier & safer to get the user to tell the server in
its ping() call, or add a new method to xmlStorageSystem (or
radioCommunityServer) that sets the 'flNotifyNewComments' flag...
Cheers,
Phil :)
----- Original Message -----
From: "Georg Bauer" <gb@murphy.bofh.ms>
To: "PyCS List" <pycs-devel@lists.sourceforge.net>
Sent: Saturday, August 30, 2003 8:13 AM
Subject: [PyCS-devel] Fwd: [radio-dev] RFC: comment notification for Radio
via email
> Hi!
>
> Just read this on the radio-dev list. I think we don't need it, as we
allways
> know who to send comment notifications to. But we don't have ways to set
> preferences per user currently. So maybe we should think about this a bit
how to
> give people the same functionality. Comments? Ideas?
>
> bye, Georg
>
> ====== Forwarded Message ======
> Date: 29.08.2003 12:52 Uhr
> Received: 29.08.2003 21:52 Uhr +0200
> From: jake@userland.com (Jake Savin)
> To: manila-dev@yahoogroups.com, radio-dev@yahoogroups.com
>
> In conjunction with a similar feature for Manila, we're working on a
> feature for notifying Radio users via email when new comments are
> posted to their sites.
>
> We'd like to give developers an opportunity to comment on the
> implementation before releasing the feature.
>
> This message is cross-posted to manila-dev because Manila hosts the
> comments for Radio users, and some of the implementation of this
> feature will be in Manila.
>
>
> *** Preferences in Radio
>
> There's only one new preference for this feature -- a checkbox for
> whether to send comment notification via email. On the Prefs -> Weblog
> -> Comments page:
>
> [x] Check this box to receive notification via email when new comments
> are posted.
>
> The default is checked. The value of the pref is stored at
> weblogData.prefs.flCommentNotificationEnabled.
>
> Comments are sent to the email address specified on the Prefs -> Basic
> Preferences -> User Identity page, which is stored at
> weblogData.prefs.authorMailAddress.
>
>
> *** Connecting to the comments site
>
> Any Manila site can host comments for a Radio weblog, and Manila
> currently has no direct way of knowing where to send the emails, or
> whether to send them at all. Radio needs a way to send this information
> to the Manila site that hosts its comments.
>
> The most flexible way to do this is for Radio to make an XML-RPC call
> to the Manila site, but first Radio needs enough information about the
> site to make the RPC call. Radio does this by making a request to the
> comments page, whose URL is the one bit of data that Radio has about
> the comments site. The request has an argument in the URL c=getRpcInfo,
> which means "send me your XML-RPC information". Here's an example
> request:
>
> GET /comments?c=getRpcInfo HTTP/1.0
> Host: radiocomments.userland.com
>
> The body of the response is XML. It contains information needed to call
> the Manila site using XML-RPC. Here's an example response:
>
> HTTP/1.1 200 OK
> Connection: close
> Content-Length: 139
> Content-Type: text/xml
>
> <rpcInfo>
> <server>radiocomments.userland.com</server>
> <port>80</port>
> <path>/RPC2</path>
> <methodName>manila.radioHosting.setPrefs</methodName>
> <siteName>radioComments</siteName>
> </rpcInfo>
>
> This request is made by radio.thread.agents.pingCloud, and the data is
> stored in a table at weblogData.prefs.commentServer. (The request is
> made only once.)
>
> Once Radio has the XML-RPC information, it makes the following XML-RPC
> call to the Manila site, also from radio.thread.agents.pingCloud, to
> set preferences for comment notification:
>
> manila.radioHosting.setPrefs (siteName, usernum, data) -- returns true
>
> siteName is the canonical name of the Manila site that hosts comments
> for the Radio weblog, as returned in XML in the above request.
>
> usernum is the Radio user's usernum, which corresponds to the "u"
> argument in the comment pop-up window URLs.
>
> data is a struct which contains the following sub-elements:
>
> flNotifyNewComments -- a boolean, true if the user wants comment
> notification via email (corresponding to the new preference described
> above)
>
> sendNotificationTo -- a string, the email address notification will be
> sent to
>
> We're using a struct for the data parameter in case more information
> needs to be sent to Manila using the setPrefs call in the future.
>
>
> *** Manila implementation
>
> Manila stores metadata about comments in the radioHosting sub-table of
> the site's #newsSite table.
>
> A new sub-table of the radioHosting table named userPrefs will store
> preferences for the Radio users whose comments the Manila site is
> hosting. This sub-table is populated by calls from Radio to
> manila.radioHosting.setPrefs, and contains two sub-items,
> flNotifyNewComments and sendNotificationTo.
>
> When a new comment is posted to a Radio site, Manila checks to see if
> the corresponding usernum has preferences defined in the
> ["#newsSite"].radioHosting.userPrefs sub-table. If defined, and if the
> value of flNotifyNewComments is true, then Manila will send email
> notification of the new comment to the email address defined by
> sendNotificationTo.
>
>
> *** Comments and Questions
>
> If you have comments or questions, please post them as a response to
> this message.
>
> Thanks,
> -Jake
>
>
> ------------------------ Yahoo! Groups Sponsor ---------------------~-->
> Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
> Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada.
> http://www.c1tracking.com/l.asp?cid=5511
> http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/nhFolB/TM
> ---------------------------------------------------------------------~->
>
> To unsubscribe from this group, send an email to:
> radio-dev-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
> ====== End Forwarded Message ======
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> PyCS-devel mailing list
> PyCS-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pycs-devel
>
Hi!
Just read this on the radio-dev list. I think we don't need it, as we allways
know who to send comment notifications to. But we don't have ways to set
preferences per user currently. So maybe we should think about this a bit how to
give people the same functionality. Comments? Ideas?
bye, Georg
====== Forwarded Message ======
Date: 29.08.2003 12:52 Uhr
Received: 29.08.2003 21:52 Uhr +0200
From: jake@userland.com (Jake Savin)
To: manila-dev@yahoogroups.com, radio-dev@yahoogroups.com
In conjunction with a similar feature for Manila, we're working on a
feature for notifying Radio users via email when new comments are
posted to their sites.
We'd like to give developers an opportunity to comment on the
implementation before releasing the feature.
This message is cross-posted to manila-dev because Manila hosts the
comments for Radio users, and some of the implementation of this
feature will be in Manila.
*** Preferences in Radio
There's only one new preference for this feature -- a checkbox for
whether to send comment notification via email. On the Prefs -> Weblog
-> Comments page:
[x] Check this box to receive notification via email when new comments
are posted.
The default is checked. The value of the pref is stored at
weblogData.prefs.flCommentNotificationEnabled.
Comments are sent to the email address specified on the Prefs -> Basic
Preferences -> User Identity page, which is stored at
weblogData.prefs.authorMailAddress.
*** Connecting to the comments site
Any Manila site can host comments for a Radio weblog, and Manila
currently has no direct way of knowing where to send the emails, or
whether to send them at all. Radio needs a way to send this information
to the Manila site that hosts its comments.
The most flexible way to do this is for Radio to make an XML-RPC call
to the Manila site, but first Radio needs enough information about the
site to make the RPC call. Radio does this by making a request to the
comments page, whose URL is the one bit of data that Radio has about
the comments site. The request has an argument in the URL c=getRpcInfo,
which means "send me your XML-RPC information". Here's an example
request:
GET /comments?c=getRpcInfo HTTP/1.0
Host: radiocomments.userland.com
The body of the response is XML. It contains information needed to call
the Manila site using XML-RPC. Here's an example response:
HTTP/1.1 200 OK
Connection: close
Content-Length: 139
Content-Type: text/xml
<rpcInfo>
<server>radiocomments.userland.com</server>
<port>80</port>
<path>/RPC2</path>
<methodName>manila.radioHosting.setPrefs</methodName>
<siteName>radioComments</siteName>
</rpcInfo>
This request is made by radio.thread.agents.pingCloud, and the data is
stored in a table at weblogData.prefs.commentServer. (The request is
made only once.)
Once Radio has the XML-RPC information, it makes the following XML-RPC
call to the Manila site, also from radio.thread.agents.pingCloud, to
set preferences for comment notification:
manila.radioHosting.setPrefs (siteName, usernum, data) -- returns true
siteName is the canonical name of the Manila site that hosts comments
for the Radio weblog, as returned in XML in the above request.
usernum is the Radio user's usernum, which corresponds to the "u"
argument in the comment pop-up window URLs.
data is a struct which contains the following sub-elements:
flNotifyNewComments -- a boolean, true if the user wants comment
notification via email (corresponding to the new preference described
above)
sendNotificationTo -- a string, the email address notification will be
sent to
We're using a struct for the data parameter in case more information
needs to be sent to Manila using the setPrefs call in the future.
*** Manila implementation
Manila stores metadata about comments in the radioHosting sub-table of
the site's #newsSite table.
A new sub-table of the radioHosting table named userPrefs will store
preferences for the Radio users whose comments the Manila site is
hosting. This sub-table is populated by calls from Radio to
manila.radioHosting.setPrefs, and contains two sub-items,
flNotifyNewComments and sendNotificationTo.
When a new comment is posted to a Radio site, Manila checks to see if
the corresponding usernum has preferences defined in the
["#newsSite"].radioHosting.userPrefs sub-table. If defined, and if the
value of flNotifyNewComments is true, then Manila will send email
notification of the new comment to the email address defined by
sendNotificationTo.
*** Comments and Questions
If you have comments or questions, please post them as a response to
this message.
Thanks,
-Jake
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/nhFolB/TM
---------------------------------------------------------------------~->
To unsubscribe from this group, send an email to:
radio-dev-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
====== End Forwarded Message ======