i think you can apply http authentication by realm and all resources in that realm use the same authentication, quoting from web:
"A realm is a URI, such as "/admin" and all resources under that URI, such as "/admin/moderation" and "/admin/users"."
for your use cases tho, you would need to use either BASIC + SSL or attempt to use DIGEST...
there is also the user-experience problem of having logins managed by pop-ups. maybe not an issue for internal systems but customers might not understand so well.
yes, it is true that cookies are a server owned attribute... my take on it is that rest is violated when the cookie is used to determine the content of a url. if the use of cookies is limited to only authenticating a session and *access* to resources, not content, then the entire system (URI space) is entirely restul.
you can then swap out cookie authentication for http authentication once it finally gets sorted out :)
i guess the issue with cookies might be that they can be too handy?
cam
On 30/03/2011, at 4:01 PM, Arthur Yeo wrote:
> 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.