Re: [OT] RE: Shale & Container Managed Security
>From: "Craig McClanahan" <[EMAIL PROTECTED]> > > On 3/7/06, James Reynolds wrote: > > > > > > >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 > > > > > > I think I understand: if I use an action method to forward a user to a > > different page based on its String name in my Faces-Config.xml, I'm > > basically employing RequestDispatcher.forward(), which circumvents the > > container managed security. Did I get it? > > > Yep. As Gary points out, you could make your navigation rules use redirects > and the constraints would still be applied, but you'd have to deal with > passing state information yourself. > > In theory, couldn't I set a role property for each page in its > > element and then conditionally render the page, or > > redirect elsewhere, based on my user's role stored in session? > > > The DTD for a managed-bean entry is fixed, and doesn't include a place for > this information. It will need to be configured elsewhere. But I'm not > sure that the managed bean entry would be the correct place anyway ... > although it is typical to have a backing bean per view, this is not > required. > True. I forgot about the case where your action contains the literal outcome and not a EL binding. I see now why the navigation handler is the right place. > If so, should this evaluation take place in the init() method of every > > page's bean, or is there a better way to handle it globally? > > > My thinking was that this sort of thing could be provided either as a custom > NavigationHandler that consulted extra information before allowing the > standard navigation rule to be applied, and/or made a service object > available that could be consulted by your application action (and would also > be used by the custom NavigationHandler). This sort of thing would let you > use a rules engine, or compose custom logic, that the framework would ask > "is it ok to go from here to there, for this particular user, at this > particular time?". > I like the idea of making a service and then you could use it for the visibility of widgets in a "rendered" binding beside "forward" navigation. Almost seems like a job for common chains? Gary > Thanks > > > Craig >
Re: [OT] RE: Shale & Container Managed Security
On 3/7/06, James Reynolds <[EMAIL PROTECTED]> wrote: > > > >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 > > > I think I understand: if I use an action method to forward a user to a > different page based on its String name in my Faces-Config.xml, I'm > basically employing RequestDispatcher.forward(), which circumvents the > container managed security. Did I get it? Yep. As Gary points out, you could make your navigation rules use redirects and the constraints would still be applied, but you'd have to deal with passing state information yourself. In theory, couldn't I set a role property for each page in its > element and then conditionally render the page, or > redirect elsewhere, based on my user's role stored in session? The DTD for a managed-bean entry is fixed, and doesn't include a place for this information. It will need to be configured elsewhere. But I'm not sure that the managed bean entry would be the correct place anyway ... although it is typical to have a backing bean per view, this is not required. If so, should this evaluation take place in the init() method of every > page's bean, or is there a better way to handle it globally? My thinking was that this sort of thing could be provided either as a custom NavigationHandler that consulted extra information before allowing the standard navigation rule to be applied, and/or made a service object available that could be consulted by your application action (and would also be used by the custom NavigationHandler). This sort of thing would let you use a rules engine, or compose custom logic, that the framework would ask "is it ok to go from here to there, for this particular user, at this particular time?". Thanks Craig
RE: [OT] RE: Shale & Container Managed Security
>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 I think I understand: if I use an action method to forward a user to a different page based on its String name in my Faces-Config.xml, I'm basically employing RequestDispatcher.forward(), which circumvents the container managed security. Did I get it? In theory, couldn't I set a role property for each page in its element and then conditionally render the page, or redirect elsewhere, based on my user's role stored in session? If so, should this evaluation take place in the init() method of every page's bean, or is there a better way to handle it globally? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] RE: Shale & Container Managed Security
Now I get it completely (I'm still getting up to speed on a lot of
this). Thanks!
-Original Message-
From: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 07, 2006 1:26 PM
To: Struts Users Mailing List
Subject: RE: [OT] RE: Shale & Container Managed Security
>From: "James Reynolds" <[EMAIL PROTECTED]>
>
> >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?
>
Oh, right. I guess you would also have to use "redirects" instead of
"forwards" for
navigation since the forwards are trusted.
viewSalary
/secured/viewSalary.faces
You could also add programmatic checks in your "action"
methods to return outcomes based on security.
Gary
>
> > 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]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] RE: Shale & Container Managed Security
>From: "James Reynolds" <[EMAIL PROTECTED]>
>
> >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?
>
Oh, right. I guess you would also have to use "redirects" instead of
"forwards" for
navigation since the forwards are trusted.
viewSalary
/secured/viewSalary.faces
You could also add programmatic checks in your "action"
methods to return outcomes based on security.
Gary
>
> > 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]
>
Re: [OT] RE: Shale & Container Managed Security
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]
>
>
RE: [OT] RE: Shale & Container Managed Security
>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?
> 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]
Re: [OT] RE: Shale & Container Managed Security
>From: "James Reynolds" <[EMAIL PROTECTED]>
>
> Thank you Craig, that's very helpful to understand.
>
> There are two things I was hoping to accomplish with Container Managed
> Security.
>
> 1. Ensuring that a user is logged in before serving up protected pages.
> I believe this is handled easily by using a Servlet Filter to check for
> a required session object (like username), similar to the example
> provided by Kito Mann in JSF in Action.
>
> 2. Protecting certain parts of the site based on a user's role. This is
> where I'm having difficulty. Among Shale/JSF programmers, is there a
> popular/best practice for implementing this requirement?
>
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
> Any advice would be appreciated.
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig
> McClanahan
> Sent: Friday, March 03, 2006 4:52 PM
> To: Struts Users Mailing List
> Subject: Re: Shale & Container Managed Security
>
> On 3/3/06, James Reynolds wrote:
> >
> > Allow me to refine my question. I'm wondering if the Shale filter is
> > intercepting requests to the container. Do I need to adjust the
> > filter mapping? Is there an FM somewhere that I should R?
>
>
> 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]
>
