I nominiate Option 2 as well
--- In email@example.com, "Phillip Pearson" <pp@m...> wrote:
> I'd stay clear of option #1 as a) you can't change your e-mail
> 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
> 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()
> it can verify the RCS password directly :)
> > 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.