Not sure if this is a support or a design question. I'm using jGuard 1.0.3 in a web application for a while. One thing jGuard does, which is now causing me problems, is redirects.
Is there a reason jGuard uses redirects and not forwards? I'd like to understand your rationale behind using them to better understand the best way forward for my present situation.
The problem I have is that my site is "multi-tenant." I.e. one web application, but treated by my clients as multiple separate applications.
The root application url is:
Client one access his site using:
Client two accesses his site using:
… etc. etc..
I have a central set of permissions based on the "root application". I run a filter **outside jguard** so that jguard only ever sees/considers requests as if they are to the "root application" and this setup works well in most regards except when jGuard does a redirect.
A redirect tells the clients browser that he is being moved… but I absolutely don't want this! An example might be the best way to explain.
If a user opens a fresh browser session and browses to:
I intercept that request in my filter and do a 'server side forward' (i.e. invisible to the clients browser) to www.example.com
JGuard then grabs the request and performs a guest authentication (correctly) but then **redirects** the user to www.example.com
The redirect updates the clients browser and they end up on www.example.com and not on www.example.com/client1 where they expected to be.
Is the above clear? I appreciate it's an unusual configuration but in my case jGuards use of redirect and not forward is causing me significant problems, so I wondered was there a reason for it.
If I might refine this a little bit - it's the use of one redirect in particular that seems incorrect:
When a client opens a fresh browser session, and browses to an application managed by jGuard for the first time:
jGuard intercepts the request
jGuard authenticates the user as a 'guest'
jGuard checks the uri accessed is permissable for the guest user
if the permissions are correct, jGuard redirects the user to the desired uri.
It is this redirection that seems genuinely wrong to me.
I've no problem with redirection for access denied, for authentication failed, etc.as in those cases 'redirection' is in fact what is happening.
But for the first case, 'forward' is really the correct action, no?
i'm agree with you:
an authentication succeed event, might not always conclude to a redirect.
the user of jguard should choose between a redirect and a forward action.
this is not yet implemented in jguard.
you have 2 options to fullfill quickly your request:
-override in the classpath the accessFilter class (http://jguard.svn.sourceforge.net/viewvc/jguard/jguard/tags/1.0.4/jguard/jguard-jee/src/main/java/net/sf/jguard/jee/authentication/http/AccessFilter.java?revision=3160&view=markup) ,i.e ship in your code an updated version, especially in the postAuthenticationProcess method, to support the 'forward' way.
- code a servletFilter, which intercept the redirect response, to transform it into a new http request, without exiting the JVM.
hope it helps,
Thanks for that.
Well - I agonized about it for a while and then decided to edit the accessFilter class. I really don't like tinkering with third party libraries but in this case it just seemed the best approach.
So I did the following:
// 13/04/11 TK, Replaced...
//AuditManager.addEvent(subject," user is authenticated "," redirect to "+redirectURI);
AuditManager.addEvent(subject," user is authenticated "," forward to "+redirectURI);
// The difference between req.getRequestDispatcher(redirectURI) and
// ServletContext.getRequestDispatcher(redirectURI) is that the former
// can take a relative path, the latter CAN NOT
… in the postAuthenticationProcess method. It seems to work just fine.
Thanks for the heads up. Looking forward to version 2 final now!
Any idea if the feature "the user of jguard should choose between a redirect and a forward action" will be included in version 2 (fingers crossed!!)
Thanks and regards,
thanks to share your patch!
the 2.0 will try to not contains too many new features, to have a reasonable shipping date..(according to the last stable release, this rewriting is very slow, i'm agree).
but this feature seems crucial for performance and usability.
we will try to add it to the final 2.0 release.
just a feedback on your proposal:
i've added on the git trunk ,the 'dispatch' choice of redirect/foward, for actions done by jguard.
this mechanism is controlled with urlpermission, in the actions field (separated with ',') .
now, if no dispatch value is specified, the forward way is used, but you can define a DISPATCH or FORWARD value in the actions field of any URLPermission in your jguardFilter.xml file, used by jguard to react (logonURI, accessDeniedURI and so on…).
here is a configuration file example used in a junit test, to validate this feature:
<?xml version="1.0" encoding="UTF-8"?>
<!-- Uri to access to the authentication form -->
<parameter key="logonURI" value="/Logon.do,REDIRECT"/>
<!-- uri to be authenticated. The action property of the authentication form MUST NOT be set to j_security_check. -->
<parameter key="logonProcessURI" value="/LogonProcess.do*"/>
<!-- uri to to be unauthenticated -->
<parameter key="logoffURI" value="/Logoff.do*"/>
<parameter key="loginField" value="login"/>
<!-- Parameter's name of the form's field which holds the password. All values are accepted except j_password. -->
<parameter key="passwordField" value="password"/>
<parameter key="goToLastAccessDeniedUriOnSuccess" value="true"/>
<!-- Uri when the user authentication failed. -->
<parameter key="authenticationFailedURI" value="/AuthenticationFailed.do*,REDIRECT"/>
<!-- Index uri of your web application. -->
<parameter key="authenticationSucceedURI" value="/index.jsp,,REDIRECT"/>
<!-- uri when access to a ressource is denied -->
<parameter key="accessDeniedURI" value="/AccessDenied.do*,REDIRECT"/>
Log in to post a comment.