On 3/7/06, James Reynolds <[EMAIL PROTECTED]> wrote:
>
> >If you are using J2EE container managed security, why not use the
> standard
> >declarative security constraint on a url-pattern? You then assign
> roles
> >to the constraint and to groups and/or users.
> >
> >Gary
>
> Thanks Gary,
>
> Maybe I'm misunderstanding Craig's response (below). Perhaps he is
> referring to page-by-page control, while you are referring to a url
> pattern that encompasses all contents of a folder (/members_only/*). Is
> that the subtle difference here?
There is a subtle but important issue. Container managed security only
operates on the original URL to which a GET or POST was directed ... it does
*not* apply to RequestDispatcher.forward() calls. In JSF terms, that means
you can protect the form submit, but it is up to the application to decide
whether or not navigation to a particular page is allowed.
The RFE being discussed here could do something like a custom navigation
handler with a pluggable strategy for choosing whether or not navigation
(according to the navigation rules) is actually going to be permitted or
not. One implementation of this strategy could be based on user roles, but
you could also do something more fine grained or context sensitive (since
the strategy implementation would have access to FacesContext, it can do
whatever it needs).
Craig
> Shale's filters do indeed intercept whatever requests it is mapped to,
>
> > but there are two important things to understand with respect to
> > container managed security:
> >
> > * Container managed security is applied *before* any filters
> > (including the one that Shale provides).
> >
> > * Container managed security is applied *only* on the
> > initial request, not on RequestDispatcher.forward() calls.
> > In JSF (and therefore Shale) apps, that means you can
> > protect the incoming form submits (they will be mapped
> > to something like "/editCustomer.jsf" if you are using
> > extension mapping, and the page being submitted was
> > "/editCustomer.jsp").
> >
> > The second issue means that it is your application's responsibility to
>
> > decide whether or not the user should be allowed to navigate to a
> > particular page. Container managed security won't help you there. That
>
> > being said, it might be interesting for Shale to deliver a custom JSF
> > navigation handler that would optionally impose that sort of control
> > ("only a manager can navigate to the salary details page").
> >
> > Craig
> >
> > -----Original Message-----
> > > From: James Reynolds [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, March 03, 2006 3:02 PM
> > > To: Struts Users Mailing List
> > > Subject: Shale & Container Managed Security
> > >
> > >
> > > I'm a newbie setting up container managed security for a basic
> > > Shale-blank application. For my first attempt, I'm trying a simple
> > > BASIC authentication but I'm having troubles so I'm trying to rule
> out
> >
> > > the unknowns.
> > >
> > > My question for this list is, does Shale have an impact on
> traditional
> >
> > > Container Managed Security Methods?
> > >
> > > Thanks
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
