<security-constraint>
<web-resource-collection>
<web-resource-name>default</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>admin</web-resource-name>
<url-pattern>/buckets/200908/bucket/*</url-pattern>
<http-method>DELETE</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
After setting that in my web.xml file and deploying, I was able to immediately curl and browse and verify that http redirects to https.
$ curl -i -X GET http://mrtidy.appspot.com/buckets/200908/bucket/
HTTP/1.1 302 Found
Location: https://mrtidy.appspot.com/buckets/200908/bucket/
Date: Mon, 05 Oct 2009 02:14:42 GMT
Content-Type: text/html
Server: Google Frontend
Content-Length: 0
X-XSS-Protection: 0
Super duper.
$ curl -i -X DELETE https://mrtidy.appspot.com/buckets/200908/bucket/1
HTTP/1.1 302 Found
Location: https://www.google.com/accounts/ServiceLogin?service=ah&continue=https://mrtidy.appspot.com/_ah/login%3Fcontinue%3Dhttps://mrtidy.appspot.com/buckets/200908/bucket/1<mpl=gm&ahname=...2
Date: Mon, 05 Oct 2009 02:22:26 GMT
Content-Type: text/html
Server: Google Frontend
Content-Length: 0
X-XSS-Protection: 0
I was hoping for a 403 there. I guess it isn't bad but I don't like it that an auth failure gives a 302 status rather than 403. Thinking about now whether I want to stick with this convenience or move the authz for DELETE to code and return my 403 status.
No comments:
Post a Comment