===
"The security model does not apply when a servlet uses the RequestDispatcher to invoke a static resource or servlet using a forward or an include."
===
I don't think its possible to impose auth constraints for includes, it would contradict the spec. Since includes cannot set headers and host of other things, allowing this for authentication would be a PITA for implementors and break in many circumstances.
Adding constraints on forwards could be feasible but I don't like it (IMO, YMMV) since in an MVC style, your controller could go through a lot of work to set up the model only have the view deny access. This could cause a lot of confusion for developers.
Adding a constraint to the incoming URL is not a big deal if one knows this constraint before coding a webapp. But discovering this constraint after the webapp was created can make life miserable.
-Tim
Mike Curwen wrote:
But that's not quite the situation here...
It's still a request for a resource
1. request /dispatcher?page=fookey
2. dispatcher translates fookey to /somepage/somewhere.jsp
3. a request for /somepage/somewhere.jsp is made
4. somepage/somewhere.jsp has a security constraint not being honoured.
And this is because security constraints are only checked for
client-side requests, and not through forwarded or included requests
(serverside). Filters currently act this way (the filter mappings are
not honoured when server-side requests are made). Do you (or anyone else) think that AUTH mappings should be 'enhanced' as
well, so that forwards/includes will be checked? (like Filters have
changed for 2.4)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
