I think this one has come up in discussion before.  It's really more of a JSF 
issue.  There is an open ticket for a new shale feature that would allow 
plugging in security in a custom navigation handler.

http://issues.apache.org/struts/browse/STR-2788

Gary

-------------- Original message -------------- 
From: "Ian.Priest" <[EMAIL PROTECTED]> 

> The main problem with that solution is that I'd rather not have to use 
> redirect everywhere as it will affect performance. 
> 
> Secondly, how would I configure the navigation rule? 
> 
> My current view is /welcome.html so that's easy 
> 
> 
> /welcome.html 
> 
> My navigation case outcome is dialog:secure... 
> 
> 
> dialog:secure 
> 
> 
> But what is my to-view id? Is it the first page of the dialog? 
> 
> /secure/page1.html 
> 
> That can't be right as my dialog starts with an action rather than a 
> page view... 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ... 
> 
> So my to-view-id would somehow have to refer to the action that starts 
> the dialog. Is that possible? 
> 
> Athird issue here is that (I believe) DialogNavigationHandler intercepts 
> the outcome of dialog:secure and deals with it, so the navigation case 
> is never invoked anyway? 
> 
> Cheers, 
> Ian. 
> 
> 
> -----Original Message----- 
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: 24 April 2006 12:53 
> To: user@struts.apache.org 
> Subject: RE: Acegi with shale and clay 
> 
> Hi 
> 
> Have you tried to define a navigation rule, and add to that 
> rule ? 
> 
> Hermod 
> 
> -----Original Message----- 
> From: Ian.Priest [mailto:[EMAIL PROTECTED] 
> Sent: Monday, April 24, 2006 1:28 PM 
> To: Struts Users Mailing List 
> Subject: Acegi with shale and clay 
> 
> 
> Hi, 
> 
> I'm using Shale/Clay to create an application. I'd like to protect the 
> app with acegi's URL protection but I don't see a way to integrate with 
> the response rendering. 
> 
> Here's an example: (all pages are rendered via Clay full html). I have 
> the structure 
> 
> /welcome.html 
> /logon.html 
> /secure/page1.html 
> /secure/page2.html 
> 
> the secure pages should only be accessable by those who have logged on 
> using logon.html. The secure/.. Pages are defined as a dialog called 
> "secure". 
> 
> In welcome.html i have an actionlink whose action is dialog:Secure 
> 
> I configure acegi to protect urls as follows: 
> 
> > class="org.acegisecurity.intercept.web.FilterSecurityInterceptor"> 
> 
> 
> 
> 
> 
> 
> 
> 
> CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON 
> PATTERN_TYPE_APACHE_ANT 
> /secure/**=ROLE_USER 
> /**=ROLE_ANONYMOUS 
> 
> 
> 
> 
> If I now hit my application at welcome.html I'm assigned role ANONYMOUS 
> and all is well. However, if I click on the link to the "secure" dialog 
> acegi doesn't redirect me to logon.html. The request generated when I 
> click on the actionlink appears to be a request for /welcome.html which 
> acegi says it's ok to access anonymously. Shale's dialog manager then 
> works out that the action is dialog:Secure and causes page1 of that 
> dialog to render, apparently without doing either a forward or a rediect 
> to /secure/page1.html. (In web.xml I have the mapping to acegi as 
> follows: 
> 
> Acegi Filter Chain Proxy 
> /* 
> FORWARD 
> REQUEST 
> 
> So forwards should also fire the filter). 
> That means acegi never has a chance to intercept the request. (Once I'm 
> in the dialog on page1.html, if I click on the next button I am 
> redirected to the logon.html page - acegi correctly intercepts the 
> /secure/page1.html request that is made). 
> 
> How can I intercept Shale's page building and view rendering mechanisms 
> to ensure that my site's urls are secured correctly? 
> 
> Cheers, 
> Ian. 
> 
> 
> 
> --------------------------------------------------------------------- 
> To unsubscribe, e-mail: [EMAIL PROTECTED] 
> For additional commands, e-mail: [EMAIL PROTECTED] 
> 
> 
> 
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 
> * * 
> 
> This email with attachments is solely for the use of the individual or 
> entity to whom it is addressed. Please also be aware that the DnB NOR 
> Group cannot accept any payment orders or other legally binding 
> correspondence with customers as a part of an email. 
> 
> This email message has been virus checked by the virus programs used in 
> the DnB NOR Group. 
> 
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 
> * * 
> 
> 
> --------------------------------------------------------------------- 
> 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] 
> 

Reply via email to