Thanks Rob for the clarification, it seems the URL/query parameters are encrypted before any data is sent.
Mitch > -----Original Message----- > From: Peter Lacey [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 02, 2007 3:13 PM > To: [email protected] > Subject: Re: Restful Login/Identifier > > Googling... Googling... Rob's right. The URL will not be > visible if SSL is in use. His latter point is valid though. > So my second suggestion is currently feeling better. > > Pete > > Rob Heittman wrote: > > > > No, SSL operates at the transport layer. It is not > sniffable in transit. > > > > One highly undesirable feature, though, is that it will be > recorded in > > logfiles, which are generally not treated with care. > > > > ----- Original Message ----- > > From: "Mitch Stewart" <[EMAIL PROTECTED]> > > To: [email protected] > > Sent: Tuesday, October 2, 2007 3:02:49 PM (GMT-0500) > America/New_York > > Subject: RE: Re: Restful Login/Identifier > > > > If you place the password inside the URL as a parameter, > won't that be > > "sniffable" because the URL contents are not encrypted via > SSL, only > > the payload of the request? I think that's why Basic Authentication > > sends the data inside the body of the POST as opposed to parameters > > within a URL. > > > > Mitch > > > > > -----Original Message----- > > > From: Peter Lacey [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, October 02, 2007 2:55 PM > > > To: [email protected] > > > Subject: Re: Restful Login/Identifier > > > > > > I have only just started mussing over the very same idea. In my > > > thinking the URLs would be much more readable. The core user > > > resource would be something like > http://example.com/users/{uname} > > > To use this for authentication purposes, an application would > > > receive credentials from the user, and GET a URL like the > following > > > from the RESTful authentication service: > > > https://example.com/users/{uname},{passwd} (note the use > of SSL). > > > That could return the same resource as the previous URL, but more > > > usefully could return, say, a SAML token appropriate for > the asking > > > application. > > > > > > Of course, one should not just assume that the proposed > URI scheme > > > will last forever, so a better solution is for a client to first > > > request a form (from a "cool" URL), e.g., > > > http://example.com/authentication_form. > > > That form will contain the necessary fields to populate and > > > (assuming it's an HTML form) will allow you to construct a URL. > > > However, in this case the URL would end up looking something like > > > this: > > > https://example.com/users?uname=placey&passwd=sekrit. > Which isn't > > > as pretty as the other version, but serves the same > purpose and uses > > > a standard recipe for link construction. > > > > > > Pete > > > > > > > > > JC wrote: > > > > I am trying to develop a Restful login system. Using a web > > > service I > > > > want to identify a user based on their user name and > > > password, but I > > > > am not sure the best (Restful) approach. > > > > > > > > I would like to avoid the RPC approach of calling an > authenticate > > > > method, passing in a user name and password. > > > > > > > > The best (Restful) solution I have come up w/ so far is to have > > > > the URL HTTPS://www.example.com/user/{user}. The {user} > > > placeholder would > > > > be the MD5 value of the concatenated string of user > name + password. > > > > > > > > Ex. > > > > User name: MyName > > > > Password: MyPassword > > > > {user} = MD5(MyName+MyPassword) > > > > > > > > If the user is found return a XML representation of the > > > user, if not > > > > return a > > > > 404 error. > > > > > > > > Thoughts, comments, suggestions? > > > > > > > >
