Jason Hunter wrote:
>
> Hans Bergsten wrote:
>
> > If you use POST as intended, it's only for requests that change
> > something on the server.
>
> Actually, to be clear, the way I believe it works is that POST must be
> used for things that change something on the server, but you're free to
> use POST anytime even if it doesn't change anything on the server --
> such as when passing 2K of parameter information.
Yes, you're right. The spec says:
"In particular, the convention has been established that the GET and
HEAD methods should never have the significance of taking an action
other than retrieval. These methods should be considered "safe." This
allows user agents to represent other methods, such as POST, PUT and
DELETE, in a special way, so that the user is made aware of the fact
that a possibly unsafe action is being requested."
Since browsers usually treat POST requests differently than GET
requests, I tend to use POST only for requests that really change
something, e.g. store info in a database or submit a purchase request,
and let the request display a confirmation page by doing a redirect
to another URL. This way the risk of someone reloading or bookmarking the
POST request is minimized, and the problem with getting prompted about
reloading the page when the user uses the Back button disappears.
Also, requests that contain too many parameters to be handled by a
GET are usually the ones that change info on the server; simple database
lookups normally doesn't carry a lot of parameters.
> > I feel that the best thing is to
> > always redirect to the applications main page if the request
> > that triggered the login form to be displayed was a POST request,
>
> Well, if you know for a fact that the original request was a POST that
> wouldn't change something on the server, like a username/password
> submit, then you can treat it like a GET. But you need to be 100%
> sure.
A username/password submit is a special case in the scenario discussed
here; username/password is only passed from the login form (using POST).
The login page doesn't check if a user is logged in, so there's no
reason to do a redirect/forward to the login page after successful
authentication.
> > A possible way out for POST requests is to keep the current user's
> > name in a hidden field in the POST form. It will then end up being
> > saved as a hidden field also in the login form. In the authentication
> > code you can then check if the new user is the same as the old user,
> > and only forward to the originally requested URL if they are the same.
>
> Except that's pretty easy to fake. I'd recommend using an id value
> which corresponded to a data structure on the server that contained the
> username.
The way I look at it, using an id value doesn't really make this approach
any more secure; if it maps directly to a userid it's as easy to fake.
No matter if you use the user name or some id, in order to fake it you
still need to know the password as well.
Anyway, I still believe the best approach for this type of authentication
with automatic redirect/forward to the originally requested URL is to
only do the redirect for GET requests.
--
Hans Bergsten [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
