RE: [Acegisecurity-developer] Maven Build in CVS
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Ben Alex > Sent: Wednesday, June 09, 2004 1:52 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [Acegisecurity-developer] Maven Build in CVS > > Thanks to Carlos Sanchez for providing an initial Maven build > file. I've just checked it into CVS along with some required > changes to library names. > > Would others running from CVS please check if this works. As > previously stated, I haven't used Maven before. It seems to > build the main JAR correctly, and I guess that's the main > requirement for being added to iBiblio. It's not required to build the jar with maven, you have to provide a project.xml with at least dependencies, id, name, currentVersion and groupId. But if you use maven everything is easier ;) just check "maven create-upload-bundle" There is a common directory layout that I've seen in almost every maven project and you should consider althought is not mandatory. This improves readability of maven projects. src/java for java classes src/conf for resources src/test for test classes and test resources In project.properties there are lots of properties not needed by maven. Also those related to the build can be moved to build.properties (as debug=on) > > What is the best practise on which libraries we should be > keeping in CVS now that we have a Maven build file? When you have tested that everything works with maven I suggest to remove those jars available at ibiblio (keep only those that I've sent you) Also I have guessed some version numbers, but if everything works that should be ok ;) > > Comments/feedback appreciated. > > Carlos, are you on the acegisecurity-developer list? Yes > > Luke, have you had a chance to look at running builds for > Acegi Security alongside Spring as yet? > > Thanks > Ben > > > > --- > This SF.Net email is sponsored by: GNOME Foundation Hackers > Unite! GUADEC: The world's #1 Open Source Desktop Event. > GNOME Users and Developers European Conference, 28-30th June > in Norway http://2004/guadec.org > ___ > Acegisecurity-developer mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > > --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] HttpServletRequest getters
There is to some extent the question of what is the servlet path
supposed to be to a filter, since the filter executes outside the
context of one particular servlet or another. So I think this is where
the problem stems from. At the time the filter is invoked, the actual
servlet which will handle the request is not necessarilly known (at
least that's how I read it). As such, a filter should not rely on the
getServletPath method. It should rely on the request url, the context
path, but that's it...
Ben Alex wrote:
Hi everyone
The Acegi Security System for Spring (http://acegisecurity.sourceforge.net)
uses HttpServletRequest getters in a filter. I do all the development of the
project using Jetty, but we've had a report of problems with WebSphere
5.1.1. I'm writing to the Jetty list in the hope of gaining some
clarification as to the correct behaviour of different HttpServletRequest
getters.
Here are our filter logging directives:
logger.debug("REQ url: " + httpRequest.getRequestURL());
logger.debug("REQ servlet path: " + httpRequest.getServletPath());
logger.debug("REQ context path: " + httpRequest.getContextPath());
logger.debug("REQ path info: " + httpRequest.getPathInfo());
logger.debug("REQ path translated " + httpRequest.getPathTranslated());
logger.debug("REQ request url: " + httpRequest.getRequestURL());
Using Jetty 4.2.17 it returns:
REQ url: http://localhost:8080/contacts/j_acegi_security_check
REQ servlet path: /j_acegi_security_check
REQ context path: /contacts
REQ path info: null
REQ path translated null
REQ request url: http://localhost:8080/contacts/j_acegi_security_check
Using WebSphere 5.1.1 (on a different machine) it returns:
REQ url: http://localhost:9080/Permit/j_acegi_security_check
REQ servlet path: /
REQ context path: /Permit
REQ path info: j_acegi_security_check
REQ path translated
/home/mark/Repositories/permit/PermitWeb/WebContent/j_acegi_security_check
REQ request url: http://localhost:9080/Permit/j_acegi_security_check
So, is getServletPath() and getPathInfo() correct for Jetty or WebSphere?
We're trying to detect the getServletPath() output as per Jetty (ie
/j_acegi_security_check) so we know our filter should do something.
Any advice appreciated.
Ben
---
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
___
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
---
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
___
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] HttpServletRequest getters
Thanks for the info, Colin.
Ben, should we then be using the Request
URL...
and doing some String VooDoo ala
httpRequest.getRequestURL().endsWith(filterProcessesUrl)
or pick off the last token and compare..
whatever
Regardless, let me know how and when
you are going to fix this.. OR
Let me know if you wanted me to submit
a bug report and patch
Thanks,
Mark
Colin Sampaleanu <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
06/09/04 08:40 AM
Please respond to acegisecurity-developer
To:
[EMAIL PROTECTED]
cc:
Subject:
Re: [Acegisecurity-developer] HttpServletRequest
getters
There is to some extent the question of what is the
servlet path
supposed to be to a filter, since the filter executes outside the
context of one particular servlet or another. So I think this is where
the problem stems from. At the time the filter is invoked, the actual
servlet which will handle the request is not necessarilly known (at
least that's how I read it). As such, a filter should not rely on the
getServletPath method. It should rely on the request url, the context
path, but that's it...
Ben Alex wrote:
>Hi everyone
>
>The Acegi Security System for Spring (http://acegisecurity.sourceforge.net)
>uses HttpServletRequest getters in a filter. I do all the development
of the
>project using Jetty, but we've had a report of problems with WebSphere
>5.1.1. I'm writing to the Jetty list in the hope of gaining some
>clarification as to the correct behaviour of different HttpServletRequest
>getters.
>
>Here are our filter logging directives:
>
>logger.debug("REQ url: " + httpRequest.getRequestURL());
>logger.debug("REQ servlet path: " + httpRequest.getServletPath());
>logger.debug("REQ context path: " + httpRequest.getContextPath());
>logger.debug("REQ path info: " + httpRequest.getPathInfo());
>logger.debug("REQ path translated " + httpRequest.getPathTranslated());
>logger.debug("REQ request url: " + httpRequest.getRequestURL());
>
>Using Jetty 4.2.17 it returns:
>
>REQ url: http://localhost:8080/contacts/j_acegi_security_check
>REQ servlet path: /j_acegi_security_check
>REQ context path: /contacts
>REQ path info: null
>REQ path translated null
>REQ request url: http://localhost:8080/contacts/j_acegi_security_check
>
>Using WebSphere 5.1.1 (on a different machine) it returns:
>
>REQ url: http://localhost:9080/Permit/j_acegi_security_check
>REQ servlet path: /
>REQ context path: /Permit
>REQ path info: j_acegi_security_check
>REQ path translated
>/home/mark/Repositories/permit/PermitWeb/WebContent/j_acegi_security_check
>REQ request url: http://localhost:9080/Permit/j_acegi_security_check
>
>
>So, is getServletPath() and getPathInfo() correct for Jetty or WebSphere?
>We're trying to detect the getServletPath() output as per Jetty (ie
>/j_acegi_security_check) so we know our filter should do something.
>
>Any advice appreciated.
>
>Ben
>
>
>
>---
>This SF.Net email is sponsored by: GNOME Foundation
>Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
>GNOME Users and Developers European Conference, 28-30th June in Norway
>http://2004/guadec.org
>___
>Acegisecurity-developer mailing list
>[EMAIL PROTECTED]
>https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
>
>
---
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
___
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] URL redirection when session expires
Hi, When the session expires, the login screen comes up (if I try to click some link). However, it tries to redirect me (as it should) to the page that I was trying to access. Since I was storing some objects in the session to display in this new page, they are no longer there since this is a new session. This results in a null pointer kind of exception Is there a way to force the URL redirection to the defaultTargetUrl or any other page rather than the one that is stored in AbstractProcessingFilter.ACEGI_SECURITY_TARGET_URL_KEY. Say for certain pages, I always want the user to be redirected to the base page from where they can start again. Is this something that is not security related ? If not, then I guess I will have to handle these programmatically. Thanks Shishir --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
RE: [Acegisecurity-developer] URL redirection when session expires
Hi Shishir > When the session expires, the login screen comes up (if I try > to click some link). However, it tries to redirect me (as it > should) to the page that I was trying to access. Since I was > storing some objects in the session to display in this new > page, they are no longer there since this is a new session. > > This results in a null pointer kind of exception > > > Is there a way to force the URL redirection to the > defaultTargetUrl or any other page rather than the one that > is stored in AbstractProcessingFilter.ACEGI_SECURITY_TARGET_URL_KEY. > > Say for certain pages, I always want the user to be > redirected to the base page from where they can start again. > > Is this something that is not security related ? > > If not, then I guess I will have to handle these programmatically. No, you can't do that directly within Acegi Security. A fundamental problem is how Acegi Security would differentiate between a legitimate first request for the secured resource in which ACEGI_SECURITY_TARGET_URL_KEY should be honoured, versus an exired request that should have its ACEGI_SECURITY_TARGET_URL_KEY ignored. I guess we could have a boolean "ignoreRedirectUrl", which if true always redirects to defaultTargetUrl. Would this be of interest to others? I'd suggest writing a filter that ensures valid objects exist in the session. If they don't exist, either redirect to the start page or create them on-the-fly. HTH Ben --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
RE: [Acegisecurity-developer] HttpServletRequest getters
Hi Mark I'd prefer an exact match, but given the containers don't provide a HttpServletRequest getter which consistently can be used for an exact comparison, we'll have to do some String VooDoo. A slightly more restrictive alternative (in that it would fire incorrectly less often) would be: httpRequest.getRequestURL().endsWith(httpRequest.getContextPath() + filterProcessesUrl); Colin, do you think this would create any additional issues? Mark, I don't mind making the change, but I'm just stepping cautiously as it is obviously a shade of grey between various containers. Would you mind trying the above code and letting me know if it works? If it does, and I make it on my development build and if it still passes the four container integration tests, we'll commit it to CVS. Best regards Ben From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark St Godard Sent: Thursday, 10 June 2004 12:22 AM To: [EMAIL PROTECTED] Subject: Re: [Acegisecurity-developer] HttpServletRequest getters Thanks for the info, Colin. Ben, should we then be using the Request URL... and doing some String VooDoo ala httpRequest.getRequestURL().endsWith(filterProcessesUrl) or pick off the last token and compare.. whatever Regardless, let me know how and when you are going to fix this.. OR Let me know if you wanted me to submit a bug report and patch --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] HttpServletRequest getters
I think that should generally work... I'm short of time right now (basically for the last 3-4 weeks actually), so didn't look too much, but I presume you would change the usage in FilterInvocation.getRequestUrl() ? That's the only place I can see outside of tests that's using getServletPath()... Ben Alex wrote: Hi Mark I'd prefer an exact match, but given the containers don't provide a HttpServletRequest getter which consistently can be used for an exact comparison, we'll have to do some String VooDoo. A slightly more restrictive alternative (in that it would fire incorrectly less often) would be: httpRequest.getRequestURL().endsWith(httpRequest.getContextPath() + filterProcessesUrl); Colin, do you think this would create any additional issues? Mark, I don't mind making the change, but I'm just stepping cautiously as it is obviously a shade of grey between various containers. Would you mind trying the above code and letting me know if it works? If it does, and I make it on my development build and if it still passes the four container integration tests, we'll commit it to CVS. Best regards Ben From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark St Godard Sent: Thursday, 10 June 2004 12:22 AM To: [EMAIL PROTECTED] Subject: Re: [Acegisecurity-developer] HttpServletRequest getters Thanks for the info, Colin. Ben, should we then be using the Request URL... and doing some String VooDoo ala httpRequest.getRequestURL().endsWith(filterProcessesUrl) or pick off the last token and compare.. whatever Regardless, let me know how and when you are going to fix this.. OR Let me know if you wanted me to submit a bug report and patch --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
RE: [Acegisecurity-developer] URL redirection when session expires
Hi Ben, I think ignoreRedirectUrl is good idea. Enhancing on that, would it make sense to have a property type attribute , which will have a key URL and the URL that needs to be redirected to. If the existing URL ends with any one of the above, then redirect to the valid url as defined in the props value. If none matches, then defaultURL is picked up. If ignoreRedirectUrl is on, then straight away redirect to the default. Thanks Shishir -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Alex Sent: Wednesday, June 09, 2004 5:47 PM To: [EMAIL PROTECTED] Subject: RE: [Acegisecurity-developer] URL redirection when session expires Hi Shishir > When the session expires, the login screen comes up (if I try to click > some link). However, it tries to redirect me (as it > should) to the page that I was trying to access. Since I was storing > some objects in the session to display in this new page, they are no > longer there since this is a new session. > > This results in a null pointer kind of exception > > > Is there a way to force the URL redirection to the defaultTargetUrl or > any other page rather than the one that is stored in > AbstractProcessingFilter.ACEGI_SECURITY_TARGET_URL_KEY. > > Say for certain pages, I always want the user to be redirected to the > base page from where they can start again. > > Is this something that is not security related ? > > If not, then I guess I will have to handle these programmatically. No, you can't do that directly within Acegi Security. A fundamental problem is how Acegi Security would differentiate between a legitimate first request for the secured resource in which ACEGI_SECURITY_TARGET_URL_KEY should be honoured, versus an exired request that should have its ACEGI_SECURITY_TARGET_URL_KEY ignored. I guess we could have a boolean "ignoreRedirectUrl", which if true always redirects to defaultTargetUrl. Would this be of interest to others? I'd suggest writing a filter that ensures valid objects exist in the session. If they don't exist, either redirect to the start page or create them on-the-fly. HTH Ben --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
RE: [Acegisecurity-developer] URL redirection when session expires
Hi Shishir > I think ignoreRedirectUrl is good idea. > > Enhancing on that, would it make sense to have a property > type attribute , which will have a key URL and the URL that > needs to be redirected to. > If the existing URL ends with any one of the above, then > redirect to the valid url as defined in the props value. If > none matches, then defaultURL is picked up. If > ignoreRedirectUrl is on, then straight away redirect to the default. Could you send me a patch (or full class) of what you have in mind? Thanks Ben --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
RE: [Acegisecurity-developer] HttpServletRequest getters
Hi Ben, I have tried a modified version of your original code snippet: httpRequest.getRequestURL().toString().endsWith( httpRequest.getContextPath() + filterProcessesUrl); Note: getRequestURL returns a java.lang.StringBuffer (odd, anyway thats something new I learned today :) or also could be reworked to: String requestUrl = httpRequest.getRequestURL().toString(); requestUrl.endsWith(httpRequest.getContextPath() + filterProcessesUrl); So other than checks for null, etc... it works fine on both of the servlet / app servers that I use: WebSphere Platform 5.1 [BASE 5.1.0 b0344.02] Host Operating System is Linux, version 2.4.21-9.0.1.EL Java version = J2RE 1.4.1 IBM J9 build 20030915 (JIT enabled) Tomcat 4.1.30 Using CATALINA_BASE: /usr/local/jakarta-tomcat-4.1.30 Using CATALINA_HOME: /usr/local/jakarta-tomcat-4.1.30 Using JAVA_HOME: /opt/j2sdk1.4.2_04 Thanks and let me know if you need anything Mark |-+---> | | "Ben Alex" <[EMAIL PROTECTED]> | | | Sent by:| | | [EMAIL PROTECTED]| | | ceforge.net | | | | | | | | | 06/09/2004 04:57 PM | | | Please respond to | | | acegisecurity-developer | |-+---> >--| | | | To: <[EMAIL PROTECTED]> | | cc: | | Subject: RE: [Acegisecurity-developer] HttpServletRequest getters | | | | | >--| Hi Mark I'd prefer an exact match, but given the containers don't provide a HttpServletRequest getter which consistently can be used for an exact comparison, we'll have to do some String VooDoo. A slightly more restrictive alternative (in that it would fire incorrectly less often) would be: httpRequest.getRequestURL().endsWith(httpRequest.getContextPath() + filterProcessesUrl); Colin, do you think this would create any additional issues? Mark, I don't mind making the change, but I'm just stepping cautiously as it is obviously a shade of grey between various containers. Would you mind trying the above code and letting me know if it works? If it does, and I make it on my development build and if it still passes the four container integration tests, we'll commit it to CVS. Best regards Ben From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark St Godard Sent: Thursday, 10 June 2004 12:22 AM To: [EMAIL PROTECTED] Subject: Re: [Acegisecurity-developer] HttpServletRequest getters Thanks for the info, Colin. Ben, should we then be using the Request URL... and doing some String VooDoo ala httpRequest.getRequestURL().endsWith(filterProcessesUrl) or pick off the last token and compare.. whatever Regardless, let me know how and when you are going to fix this.. OR Let me know if you wanted me to submit a bug report and patch --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
