If you are not using container managed persistence, where the
HttpRequest values are being set in the environment, you probably don't
want to use the Principal or PrincipalAware interface, or even to wrap
the HttpServletRequest (this email was in response to using a servlet
wrapper to re-implement code already present in s2).
Options I've used are creating an interceptor to access the security
context (I've not used JAAS personally), and then create an annotation
to signify actions/methods that need security information assigned to
them. The same annotation, or another, could also be used to
declaratively configure those actions that require a specific role from
the security context in order to be invoked.
/Ian
Chris Pratt wrote:
On 9/18/07, Ian Roughley <[EMAIL PROTECTED]> wrote:
By implementing the PrincipalAware interface, the Principal object will
be injected into the action with those values from the request (the
user, roles, etc.). The values can be be used in the action, or the
Principal can be exposed with a setter for the actions to use.
But if you don't use Container Managed Authentication, how do you get
the Principal into the request so that PrincipalAware can inject it,
without using a ServletFilter?
(*Chris*)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
