Thanks, Cam, for responding. I appreciate it.
HTTP auth itself does not require a session but it only authenticate a
single rsrc. It will be a poor UX design if the website requires the user to
be authenticated for every rsrc he touches. What's the common solution to
get around this besides maintaining a session, which is non-RESTful?
Cookies would work but the content of a cookie is usually something
generated by the Server which the client lugs around. The client does not
understand its content, only the server does. This means the cookie is a
appl state maintained by the Server. RESTful is now violated.
On Wed, Mar 30, 2011 at 5:37 AM, Cameron Heavon-Jones <cmhjones_at_gmail.com>wrote:
> Hi Arthur,
>
> My personal take on maintaining user authentication and still be restful
> would be to use HTTP authentication. This is what it was designed for and
> modern browsers send authentication information with every request
> eliminating the need to maintain session on the server.
>
> Alternatively , i find no problem in using cookies for maintaining session
> authentication. It's why they were invented back in the 90s and the gap in
> the HTTP spec remains to be filled by another method.
>
> I don't think it needs to be difficult...both of these methods are
> perfectly Restful, IMO, as they conform to the HTTP specification.
>
> cam
>
> On 30/03/2011, at 1:31 AM, Arthur Yeo wrote:
>
> > Hi All,
> >
> > After a user gets authenticated, what do you recommend to handle the
> concept of a session without breaking the RESTful paradigm?
> > It seems like all post-login requests to the server needs to include some
> kind of nonce or token to identify the "session" so to speak.
> > If that's so, the server needs to understand and store that token to
> validate it for every incoming request.
> > Wouldn't that break the RESTful paradigm since the server is now storing
> application state?
> >
> > --
> > Arthur Y.
>
>
--
Arthur Y.