I guess it is so they can have one servlet method per HTTP method
The spec includes doGet(), doPost(), doPut(), doDelete(), doHead(), doOptions(), doTrave()
HTTP/1.0 has doGet, doPut, doHead. HTTP/1.1 adds the others.
-- Jason Lea
Bailey, Shane C. wrote:
Jason,
That makes since about the user (hacker) recreating the form on POSTing. Why the original separation in the Servlet then, any ideas?
I would do the check at the top of the action. It seems more flexible than having to put your form actions in a certain area.
Thanks.
BTW, SecurityFilter is running smoothly :-)
-----Original Message-----
From: Jason Lea [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 6:21 PM
To: Struts Users Mailing List
Subject: Re: Allowing only POST for form submittal ????
Hi Shane,
I don't think it really matters.
Say you have a hidden field containing an id in your form that is posted back to an action. A user could copy that page to their hard disk, modify the field and then submit it. They would still be POSTing so your action would be happy. You still need to verify the id is ok, or user has permission to access that id.
If you had some reason to only allow POSTs then you might be able to check in the action, or I think you can do that with a security contraint in web.xml:
<security-constraint> <web-resource-collection> <web-resource-name>allow only POSTs</web-resource-name> <url-pattern>/postonly/*.do</url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <role-name>no-member-role</role-name> </auth-constraint> </security-constraint>
This basically means if someone tries to use GET (eg a normal request to the action) they would have to be a member of the role 'no-member-role'. Since we won't have anyone in this role, nobody can use GET for these actions. All other methods are allowed.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
