If the standard HTTP authentication doesn't work for you, I'd use a
cookie to carry an authentication token. This way you avoid creating a
session on the server just to hold the authentication details and load
balancing remains trivial since any instance can service any request.
When a user requests a page without authorisation, redirect to a login
form which generates the cookie then redirects them back to the original
page. Logout is unnecessary if the cookie has a short expiry, but could
remove the cookie from the client if you wanted.
The RESTful Web Services book has some good examples on authentication
(including custom extensions like Amazon's). I recommend you get a copy
if you haven't already - there's a link from here
http://www.restlet.org/documentation/books
Regards,
Michael.
Davide Angelocola wrote:
I'm very confused about the logout action... the server should maintains a
session? there is the need of a transient resource? i.e. a /user/session?
this should be not restful, right?
On Thursday 06 September 2007 22:47:18 Stanczak Group wrote:
I would guess you would have to send a message telling them to login
using that role. So you would then check that role in your Guard and if
it fails send them to that page to login as that role.
Davide Angelocola wrote:
Hi,
this is my first post on this mailing list. I'm wondering about porting
a servlet/JSP webapp to REST. I've several roles this webapp and I
allow the same user to have multiple roles, but only one role at once
can do login. In this scenario I use the server session to store the
username and role.
In respect of a restful design how to implement the login/logout
actions? Any idea/hint would be appreciated.
