securityfilter-user — Security Filter Users list

Re: [securityfilter-user] Security Filter and Tomcat 7

[Christopher S. <ch...@ch...>]

Matthew,

On 12/13/11 5:54 PM, Matthew Hixson wrote:
> Hi Chris, I'm finally getting back to trying to make our app run with Tomcat 7.

Sorry, I only now noticed this message. This mailing list doesn't get a
great amount of traffic :(

> Isn't this a change that should be made to security filter so that it
> runs correctly with Tomcat 7?  I'd be willing to bet that other
> people have and will continue to run into this problem.
>
> I had written my own Realm implementation and this worked just
> great, however my current exception doesn't even look like execution
> reaches my realm class.
> 
> Dec 13 14:03:44 SEVERE thr:13 u:- c:org.apache.jsp.e_jsp m:_jspService java.lang.NoSuchMethodError: org.apache.catalina.Realm.hasRole(Ljava/security/Principal;Ljava/lang/String;)Z
> at org.securityfilter.realm.catalina.CatalinaRealmAdapter.isUserInRole(CatalinaRealmAdapter.java:108)
> at org.securityfilter.filter.SecurityFilter.doFilter(SecurityFilter.java:214)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)

Yeah, the problem is that the CatalinaRealmAdapter class is built
against a quite-old version of Tomcat's "Realm" class.

A while back, when I upgraded to a newer version of Tomcat (5.5? 6.0?) I
just bit the bullet and wrote my own Realm from scratch (in fact,
stealing a lot of Tomcat's DataSourceRealm code).

Tomcat's Realms are much more difficult to work with, now. They used to
be fairly lightweight and not have too many hooks back into their own
non-public API (that is to say, the part of the API that should be stable).

Now, you basically have to hook-into their own internals so that things
like logging and, etc. work without throwing NPEs and stuff like this.
This is another one of those cases: you have to provide a "Wrapper"
object to the Realm.hasRole method in order for it to work, and that
requires reaching into Tomcat's internals to get an object that
represents the current webapp.

That's not a trivial thing to so, especially when there's a bunch of
different versions out there that all need to work. It's worse to break
backward-compatibility IMO than it is to fail to support a new version
moving forward: you don't want to surprise people who don't know
something's changing.
> My realm is defined in security-filter.xml as:
> 
> <realm className="com.company.authentication.MyRealm">

Presumably, this class extends CatalinaRealmAdapter or is wrapped-up in
CatalinaRealmAdapter? How are you doing that, exactly?

You have a few options right now:

1. Bail on CatalinaRealmAdapter and write your own Realm (or I can give
   you my DataSourceRealm if you want it).

2. Override the isUserInRole in MyRealm and figure out how to get
   the proper parameter to Tomcat's Realm interface.

3. Help me work out a solution that can be used across multiple versions
   of Tomcat.

Honestly, the usefulness of this project was significantly diminished
when Oracle published Servlet 3.0 because securityfilter's primary job
in the real world was to allow webapps to accept logins without first
requiring the user to request a protected resource (and it took long
enough... thanks Sun/Oracle). Yes, other things have been built-into sf
as well ("remember me", parameter-forwarding, etc.) but all that stuff
can be provided by filters that are orthogonal to actual authentication
and authorization.

I don't see a great future for sf, other than continuing to exist in its
current form. I once had aspirations of re-writing the entire thing in a
more modular way (have you seen some of the code in there?) but I kept
coming back to the same question: does anyone really need sf anymore? I
don't want to spend a bunch of time on it if it's slowly going to die. I
still use it on all my own projects because it has features that would
be difficult to get into containers (such as forwarding certain request
parameters after the authentication stage to the next resource that is
requested, or being able to get the IP address of the request for
logging authentication failures). I do use my own heavily-customized
realm (that extends the DataSourceRealm I sometimes give-out to users of
sf) but that could be re-written as a subclass of Tomcat's
DataSourceRealm if I didn't need sf for anything else.

Anyhow, I'm open to any thoughts you might have about, well, anything :)

Thanks,
-chris

Re: [securityfilter-user] Security Filter and Tomcat 7

[Matthew H. <hi...@po...>]

Hi Chris, I'm finally getting back to trying to make our app run with Tomcat 7.  Isn't this a change that should be made to security filter so that it runs correctly with Tomcat 7?  I'd be willing to bet that other people have and will continue to run into this problem.
  I had written my own Realm implementation and this worked just great, however my current exception doesn't even look like execution reaches my realm class.

Dec 13 14:03:44 SEVERE thr:13 u:- c:org.apache.jsp.e_jsp m:_jspService java.lang.NoSuchMethodError: org.apache.catalina.Realm.hasRole(Ljava/security/Principal;Ljava/lang/String;)Z
at org.securityfilter.realm.catalina.CatalinaRealmAdapter.isUserInRole(CatalinaRealmAdapter.java:108)
at org.securityfilter.filter.SecurityFilter.doFilter(SecurityFilter.java:214)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:928)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:300)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)

My realm is defined in security-filter.xml as:

<realm className="com.company.authentication.MyRealm">

Thanks,
  -M@

On Sep 29, 2011, at 12:55 PM, Christopher Schultz wrote:

> Matt,
> 
> On 9/1/2011 7:17 PM, Matthew Hixson wrote:
>> I am trying to get our webapp working with Tomcat 7 and am finding
>> that Security Filter is failing because it is compiled against an
>> older servlet spec.
> 
> The servlet spec is backward-compatible, so that's not the issue.
> 
>> Has Security Filter been obsoleted by Tomcat's
>> <security-constraint> support?
> 
> <security-constraint> has been a part of the spec (it's not
> Tomcat-specific) since the beginning. No spec changes have altered the
> capabilities of securityfilter.
> 
>> Sep 01 15:58:25 INFO thr:14 u:- c:org.apache.jsp.e_jsp m:_jspService --- IN E.JSP ---
>> java.lang.NoSuchMethodError:
> org.apache.catalina.Realm.hasRole(Ljava/security/Principal;Ljava/lang/String;)Z
>> 	at org.securityfilter.realm.catalina.CatalinaRealmAdapter.isUserInRole(CatalinaRealmAdapter.java:108)
> 
> Tomcat's internal classes have changed. The CatalinaRealmAdapter was
> built originally for a Tomcat 4/5 integration and, unfortunately, over
> time it has diverged more and more from what sf expects and can use.
> 
> One solution is to provide "adapter" classes for all versions of Tomcat
> (and WebLogic, and Jetty, and...). Another solution is to implement your
> own Realm yourself. That's what I have done: I have a DataSourceRealm
> built using some of Tomcat's code as a basis, but doesn't reference any
> of Tomcat's classes, etc. This code runs happily on versions of Tomcat
> going from 4.3 through the latest 7.0 (I know because I've been using sf
> in this way through all those versions... actually skipped 5.0 to don't
> take my word for it).
> 
> I've been asked for my DataSourceRealm implementation a few times, so
> maybe it's time to put it into CVS. You can download it here at the
> bottom of the page:
> http://www.christopherschultz.net/projects/java/
> 
> -chris
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1_______________________________________________
> securityfilter-user mailing list
> sec...@li...
> https://lists.sourceforge.net/lists/listinfo/securityfilter-user

Re: [securityfilter-user] Security Filter and Tomcat 7

[Christopher S. <ch...@ch...>]

Matt,

On 9/1/2011 7:17 PM, Matthew Hixson wrote:
> I am trying to get our webapp working with Tomcat 7 and am finding
> that Security Filter is failing because it is compiled against an
> older servlet spec.

The servlet spec is backward-compatible, so that's not the issue.

> Has Security Filter been obsoleted by Tomcat's
> <security-constraint> support?

<security-constraint> has been a part of the spec (it's not
Tomcat-specific) since the beginning. No spec changes have altered the
capabilities of securityfilter.

> Sep 01 15:58:25 INFO thr:14 u:- c:org.apache.jsp.e_jsp m:_jspService --- IN E.JSP ---
> java.lang.NoSuchMethodError:
org.apache.catalina.Realm.hasRole(Ljava/security/Principal;Ljava/lang/String;)Z
> 	at org.securityfilter.realm.catalina.CatalinaRealmAdapter.isUserInRole(CatalinaRealmAdapter.java:108)

Tomcat's internal classes have changed. The CatalinaRealmAdapter was
built originally for a Tomcat 4/5 integration and, unfortunately, over
time it has diverged more and more from what sf expects and can use.

One solution is to provide "adapter" classes for all versions of Tomcat
(and WebLogic, and Jetty, and...). Another solution is to implement your
own Realm yourself. That's what I have done: I have a DataSourceRealm
built using some of Tomcat's code as a basis, but doesn't reference any
of Tomcat's classes, etc. This code runs happily on versions of Tomcat
going from 4.3 through the latest 7.0 (I know because I've been using sf
in this way through all those versions... actually skipped 5.0 to don't
take my word for it).

I've been asked for my DataSourceRealm implementation a few times, so
maybe it's time to put it into CVS. You can download it here at the
bottom of the page:
http://www.christopherschultz.net/projects/java/

-chris

[securityfilter-user] Security Filter and Tomcat 7

[Matthew H. <hi...@po...>]

I am trying to get our webapp working with Tomcat 7 and am finding that Security Filter is failing because it is compiled against an older servlet spec.  Has Security Filter been obsoleted by Tomcat's <security-constraint> support? 
  Thanks,
   -M@

Sep 01 15:58:25 INFO thr:14 u:- c:org.apache.jsp.e_jsp m:_jspService --- IN E.JSP --- java.lang.NoSuchMethodError: org.apache.catalina.Realm.hasRole(Ljava/security/Principal;Ljava/lang/String;)Z
	at org.securityfilter.realm.catalina.CatalinaRealmAdapter.isUserInRole(CatalinaRealmAdapter.java:108)
	at org.securityfilter.filter.SecurityFilter.doFilter(SecurityFilter.java:214)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:405)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:279)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:300)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:680)

[securityfilter-user] Bypass SecurityFilter on local host

[Martin D. <mar...@gm...>]

I would like to know if it is possible to bypass SecurityFilter filter if a
user logs in locally (from a browser running on the machine where the Web
server is running). I am preferably looking for a way that would not require
to modify SecurityFilter sources, although I am open to changes if it is the
only possible way to go.

Martin

[securityfilter-user] Help with message

[Gregory F. <gre...@gm...>]

Hi,

I'm using SecurityFilter to the validation of the user, how do I show an
error message of access to the database when the database is shut down?

-- 
Regards,
Gregory Fontenele
Developer
Linux User #478399
Skype: gregoryfontenele

Re: [securityfilter-user] getting parameters from j_security_check form

[Christopher M. <C_M...@ma...>]

Chris, thanks for the quick reply!  As it happens I actually just 
finished method #1 -- in this case I just needed the filter to set a 
session attribute from the extra parameter in the login form, which 
appears to be working.  If it starts to cause problems or get hairy 
later, I'll take a look at FlexibleSecurityRealm too.


On 6/11/2009 10:45 AM, Christopher Schultz wrote:
>> Is it possible to access an extra parameter in the
>> j_security_check form using SecurityFilter?
>>      
> There are several ways:
>
> 1. Write your own filter that runs before or after sf and do whaetever
> you want.
>
> 2. Implement your own Realm that implenents FlexibleSecurityRealm which
> has full access to the request object. You can pull-out any information
> you'd like.
>
> I like #2 because it's much more likely to work properly (!) and you
> probably want to implement your own Realm in this case, anyway.
>
> I do this on my current project in order to log failed logins' source IP
> address (available from the request object).
>
> In order to use FlexibleSecurityRealm, I believe you need to get the
> latest sf code from CVS and compile it yourself (it's no big deal, you
> just have to have Apache ant and a JDK installed).
>
> I hope that helps,
> -chris
>
>    
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> ------------------------------------------------------------------------
>
> _______________________________________________
> securityfilter-user mailing list
> sec...@li...
> https://lists.sourceforge.net/lists/listinfo/securityfilter-user
>    

Re: [securityfilter-user] getting parameters from j_security_check form

[Christopher S. <ch...@ch...>]

Chris

On 6/10/2009 5:29 PM, Christopher Maloof wrote:
> I'm working on an app that uses JNDI Realm authentication, and I'd like 
> the user to be able to pass additional parameters through the login page 
> (say, a third field besides username and password).
> 
> I think it's not possible to do this through regular container-based 
> authentication.

Correct. Container-managed auth implementations will hide the
authentication request from your webapp, and you can't get the data.

> Is it possible to access an extra parameter in the 
> j_security_check form using SecurityFilter?

Yes.

> If so, how?

There are several ways:

1. Write your own filter that runs before or after sf and do whaetever
you want.

2. Implement your own Realm that implenents FlexibleSecurityRealm which
has full access to the request object. You can pull-out any information
you'd like.

I like #2 because it's much more likely to work properly (!) and you
probably want to implement your own Realm in this case, anyway.

I do this on my current project in order to log failed logins' source IP
address (available from the request object).

In order to use FlexibleSecurityRealm, I believe you need to get the
latest sf code from CVS and compile it yourself (it's no big deal, you
just have to have Apache ant and a JDK installed).

I hope that helps,
-chris

[securityfilter-user] getting parameters from j_security_check form

[Christopher M. <C_M...@ma...>]

I'm working on an app that uses JNDI Realm authentication, and I'd like 
the user to be able to pass additional parameters through the login page 
(say, a third field besides username and password).

I think it's not possible to do this through regular container-based 
authentication.  Is it possible to access an extra parameter in the 
j_security_check form using SecurityFilter?  If so, how?  Any help is 
appreciated...

Thanks very much,
Chris

Re: [securityfilter-user] SecurityFilter doing authentication upon logout?

[Christopher S. <ch...@ch...>]

Matt,

On 5/5/2009 6:51 PM, Matthew Hixson wrote:
> We have a method that updates the database with the last time that a  
> user logs in.  I put a Thread.dumpStack() call in my method,  
> updateLastLogin().  The problem I have is that upon logout execution  
> ends up passing through this method again which, of course, has the  
> result of logging to the database the time that the user logged out.

That's definitely odd. What version of sf are you using?

> While logging in the stack trace looks like this.
> 
> java.lang.Exception: Stack trace
> 	at java.lang.Thread.dumpStack(Thread.java:1176)
> 	at mycompany.SpecialAuthenticator.updateLastLogin(SpecialAuthenticator.java:36)
> 	at com.mycompany.authentication.SARealm.authenticate(SARealm.java:140)
> 	at org.securityfilter.realm.catalina.CatalinaRealmAdapter.authenticate(CatalinaRealmAdapter.java:95)
> 	at org.securityfilter.authenticator.FormAuthenticator.processLogin(FormAuthenticator.java:297)
> 	at org.securityfilter.filter.SecurityFilter.doFilter(SecurityFilter.java:144)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>       [...]

[snip]

> While logging out it produces this:
> 
> java.lang.Exception: Stack trace
> 	at java.lang.Thread.dumpStack(Thread.java:1176)
> 	at mycompany.SpecialAuthenticator.updateLastLogin(SpecialAuthenticator.java:36)
> 	at com.mycompany.authentication.SARealm.authenticate(SARealm.java:140)
> 	at org.securityfilter.realm.catalina.CatalinaRealmAdapter.authenticate(CatalinaRealmAdapter.java:95)
> 	at org.securityfilter.authenticator.FormAuthenticator.processLogin(FormAuthenticator.java:284)
> 	at org.securityfilter.filter.SecurityFilter.doFilter(SecurityFilter.java:144)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>       [...]

Hmm... the line numbers are different in the call to
CatalinaRealmAdapter.authenticate from FormAuthenticator.processLogin.
Have you been hacking the sf code yourself, or is everything as you got
it from the original dist package?

> So, why does
> org.securityfilter.authenticator.FormAuthenticator.processLogin() end
> up getting called when the user is logging out? My relevant part of
> securityfilter-config.xml looks like:
> 
> <login-config>
>      <auth-method>FORM</auth-method>
>      <form-login-config>
>        <form-login-page>/login.jsp</form-login-page>
>        <form-error-page>/login.jsp?err=1</form-error-page>
>        <form-default-page>/members/index.jsp</form-default-page>
>        <form-logout-page>/logout.jsp</form-logout-page>

What about your <security-constraint> sections?

>        <!-- remember-me config -->

Does disabling <remember-me> have any effect on this behavior?

> I put some debug code into my /logout.jsp to see if that were somehow  
> triggering something, but the stack trace happens before execution  
> even enters logout.jsp.

Right: the filter executes before any servlet (or JSP) code does.

> Any thoughts on how I can prevent my Realm's authenticate() method
> being called upon logout?  And am I incorrect in assuming that  
> authenticate() should only be called upon initial login?

Generally, yes. Don't be fooled by the call to processLogin: this method
is called to /determine/ if the request is for a login and take
appropriate actions.

The FormAuthenticator first checks to see if you are using a persistent
log manager (you are) and uses the remembered credentials for
authentication (that's on line 284, as in your second stack trace). Your
second case appears to match this.

Whether you are using a persistent manager or not, FormAuthenticator
continues with the standard login mechanism (which appears to be shown
in your second stack trace). The request is checked (endsWith) against
the loginSubmitPattern which defaults to "/j_security_check". What does
your <filter> configuration look like for sf? Are you passing-in any
<filter-init-param>s?

Can you post the URLs you are using that end up with stack traces #1 and
#2? Is there any forwarding or redirecting going on?

I suspect that you have "persistent logins" enabled and so when you hit
logout.jsp, you are being re-logged-in using the persistent manager.
Although the persistent manager is supposed to forget your login
/before/ trying to log you in again.

I think there might be a bug in the persistent login manager, because
the rememberingLogin() method is this:

      if (getCookieValue(request.getCookies(), COOKIE_REMEMBERME,
"false").equals("true")) {
         return true;
      } else {
         return false;
      }

During a logout request, any persistent login cookies will be sent along
with the request as usual. The logout will trigger the persistent
manager to forget your login. The subsequent login check uses the cookie
/still in the request/ to log you back in. Duh.

No offense to the original authors of this code, but I somewhat recently
inherited this project, and I've never used the PersistentManager
myself. It seems like the PersistentManager has a relatively big bug,
here, in that it is not possible to log out. :)

Are you willing to recompile sf? If so, try making the following changes:

1. In DefaultPersistentManager.forgetLogin, add this code:

request.setAttribute("persistentLoginManager.logout", Boolean.TRUE);

2. Change DefaultPersistentManager.rememberingLogin to this:

   return getCookieValue(request.getCookies(),
                         COOKIE_REMEMBERME,
                         "false").equals("true"))
          &&
!Boolean.TRUE.equals(request.getAttribute("persistentManager.logout"))
          ;

See if that fixes your logout problem.

-chris

[securityfilter-user] SecurityFilter doing authentcation upon logout?

[Matthew H. <hi...@po...>]

We have a method that updates the database with the last time that a  
user logs in.  I put a Thread.dumpStack() call in my method,  
updateLastLogin().  The problem I have is that upon logout execution  
ends up passing through this method again which, of course, has the  
result of logging to the database the time that the user logged out.

My Realm, SARealm, extends SecurityFilter's TrivialCatalinaRealm.

While logging in the stack trace looks like this.

java.lang.Exception: Stack trace
	at java.lang.Thread.dumpStack(Thread.java:1176)
	at  
mycompany 
.SpecialAuthenticator.updateLastLogin(SpecialAuthenticator.java:36)
	at com.mycompany.authentication.SARealm.authenticate(SARealm.java:140)
	at  
org 
.securityfilter 
.realm 
.catalina.CatalinaRealmAdapter.authenticate(CatalinaRealmAdapter.java: 
95)
	at  
org 
.securityfilter 
.authenticator.FormAuthenticator.processLogin(FormAuthenticator.java: 
297)
	at  
org.securityfilter.filter.SecurityFilter.doFilter(SecurityFilter.java: 
144)
	at  
org 
.apache 
.catalina 
.core 
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 
235)
	at  
org 
.apache 
.catalina 
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at  
org 
.apache 
.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java: 
233)
	at  
org 
.apache 
.catalina.core.StandardContextValve.invoke(StandardContextValve.java: 
191)
	at  
org 
.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java: 
128)
	at  
org 
.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java: 
102)
	at  
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java: 
568)
	at  
org 
.apache 
.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at  
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java: 
286)
	at  
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java: 
845)
	at org.apache.coyote.http11.Http11Protocol 
$Http11ConnectionHandler.process(Http11Protocol.java:583)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java: 
447)
	at java.lang.Thread.run(Thread.java:613)

While logging out it produces this:

java.lang.Exception: Stack trace
	at java.lang.Thread.dumpStack(Thread.java:1176)
	at  
mycompany 
.SpecialAuthenticator.updateLastLogin(SpecialAuthenticator.java:36)
	at com.mycompany.authentication.SARealm.authenticate(SARealm.java:140)
	at  
org 
.securityfilter 
.realm 
.catalina.CatalinaRealmAdapter.authenticate(CatalinaRealmAdapter.java: 
95)
	at  
org 
.securityfilter 
.authenticator.FormAuthenticator.processLogin(FormAuthenticator.java: 
284)
	at  
org.securityfilter.filter.SecurityFilter.doFilter(SecurityFilter.java: 
144)
	at  
org 
.apache 
.catalina 
.core 
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 
235)
	at  
org 
.apache 
.catalina 
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at  
org 
.apache 
.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java: 
233)
	at  
org 
.apache 
.catalina.core.StandardContextValve.invoke(StandardContextValve.java: 
191)
	at  
org 
.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java: 
128)
	at  
org 
.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java: 
102)
	at  
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java: 
568)
	at  
org 
.apache 
.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at  
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java: 
286)
	at  
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java: 
845)
	at org.apache.coyote.http11.Http11Protocol 
$Http11ConnectionHandler.process(Http11Protocol.java:583)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java: 
447)
	at java.lang.Thread.run(Thread.java:613)

So, why does  
org.securityfilter.authenticator.FormAuthenticator.processLogin() end  
up getting called when the user is logging out?  My relevant part of  
securityfilter-config.xml looks like:

<login-config>
     <auth-method>FORM</auth-method>
     <form-login-config>
       <form-login-page>/login.jsp</form-login-page>
       <form-error-page>/login.jsp?err=1</form-error-page>
       <form-default-page>/members/index.jsp</form-default-page>
       <form-logout-page>/logout.jsp</form-logout-page>
       <!-- remember-me config -->
          <remember-me  
className 
= 
"org 
.securityfilter.authenticator.persistent.DefaultPersistentLoginManager">
             <!-- optional settings for default persistent login  
manager -->
             <remember-me-param name="cookieLife" value="1"/><!--  
number of days -->
             <remember-me-param name="protection" value="all"/><!--  
all, none, validation, encryption -->
             <remember-me-param name="useIP" value="false"/>
             <remember-me-param name="encryptionAlgorithm" value="DES"/>
             <remember-me-param name="encryptionMode" value="ECB"/>
             <remember-me-param name="encryptionPadding"  
value="PKCS5Padding"/>
             <!-- encryption keys; customize for each application -->
             <!-- NOTE: these kys must be specified AFTER other  
encryption settings -->
             <remember-me-param name="validationKey" value="<my key>"/>
             <remember-me-param name="encryptionKey" value="<my other  
key>"/>
          </remember-me>
     </form-login-config>
   </login-config>

I put some debug code into my /logout.jsp to see if that were somehow  
triggering something, but the stack trace happens before execution  
even enters logout.jsp.
   Any thoughts on how I can prevent my Realm's authenticate() method  
being called upon logout?  And am I incorrect in assuming that  
authenticate() should only be called upon initial login?
   Thanks for any feedback,
    -M@

Re: [securityfilter-user] Start page

[Christopher S. <ch...@ch...>]

Torgeir,

On 2/13/2009 7:41 PM, Torgeir Veimo wrote:
> On 14 Feb 2009, at 07:52, Martin Dubuc wrote:
> 
>> I would like to confirm first of all that I can force securityfilter  
>> to load a specific page after a login that was requested because of  
>> a session timing out. If it is the case, I am wondering if there are  
>> any signs I could monitor to help figure out why I am presented with  
>> a blank page.
> 
> Securityfilter redirects to the page which the user tried to load  
> before the login page. It only goes to the stat page if no previous  
> page was requested, eg the user went directly to the login page. If  
> you need different behaviour, you probably have to patch securityfilter.

The CVS version of securityfilter allows you to override the page you go
to after login, regardless of any previously-saved request.

Along with your credentials, you can provide the following parameters to
j_security_check:

param name		value
forward			The URL to forward to.
forward-mode		"forward" or "redirect" (default=redirect)
forward-parameters	"true" or "false" (default=false)

That last parameter can be used to have securityfilter include all the
parameters sent to the login form along to the 'forward' URL. The
credentials as well as the 'forward' configuration parameters are all
removed from any query string used for redirection.

If you read the code for FormAuthenticator.java, you'll see all these
parameters documented at the top of the class.

-chris

Re: [securityfilter-user] Start page

[Torgeir V. <to...@po...>]

On 14 Feb 2009, at 07:52, Martin Dubuc wrote:

> I would like to confirm first of all that I can force securityfilter  
> to load a specific page after a login that was requested because of  
> a session timing out. If it is the case, I am wondering if there are  
> any signs I could monitor to help figure out why I am presented with  
> a blank page.


Securityfilter redirects to the page which the user tried to load  
before the login page. It only goes to the stat page if no previous  
page was requested, eg the user went directly to the login page. If  
you need different behaviour, you probably have to patch securityfilter.

-- 
Torgeir Veimo
to...@po...

[securityfilter-user] Start page

[Martin D. <mar...@gm...>]

I was expecting securityfilter is to make it possible for an application to
automatically load a specific page after a successful user login. I have
configured the login-config property in the securityfilter-config.xml as
follows:

   <login-config>
        <auth-method>FORM</auth-method>
        <form-login-config>
            <form-login-page>/login.jsp</form-login-page>
            <form-error-page>/loginError.jsp</form-error-page>
            <form-default-page>/test.html</form-default-page>
        </form-login-config>
    </login-config>

I would expect with such setup that the Web application always presents page
test.html after a successful login.

However, when the user logs in, the application does not load the test.html
Web page (I might have seen the application load it once, but other times,
it didn't load that page). The biggest problem I am facing is the handling
of the case where a session times out and the user clicks on a link on the
page while the session is invalidated. Currently, securityfilter rightfully
forwards to the login page, but after the login, it seems like it is either
trying to resume where it left off, or loads the index.html page (instead of
test.html). The page that is returned is blank. The source shows that the
Ajax4Jsf library has been busy building the page, but only partially. It is
not clear to me what the interactions are between Tomcat, Ajax4Jsf and
securityfilter.

I would like to confirm first of all that I can force securityfilter to load
a specific page after a login that was requested because of a session timing
out. If it is the case, I am wondering if there are any signs I could
monitor to help figure out why I am presented with a blank page.

Martin

Re: [securityfilter-user] filter-mapping

[Christopher S. <ch...@ch...>]

Martin,

On 2/13/2009 2:53 PM, Martin Dubuc wrote:
> On Wed, Feb 11, 2009 at 3:36 PM, Christopher Schultz <ch...@ch...> wrote:
>>
>> Can you explain a little more about the CGI stuff? I don't see why
>> securityfilter would be interfering with your CGI scripts. Can you give
>> me some more details?
> 
> I think I figured out what the problem is. The CGI scripts on my Web server
> were global to all applications. Is it possible that in that context when
> they are invoked, since they are not part of my application, the server
> thinks it needs to authenticate the user once again, which triggers the Web
> server to invoke the securityfilter? I solved my issue by moving the CGI
> scripts inside the application and now things are working as expected.

If your CGI scripts were deployed under another context, securityfilter
shouldn't have been involved at all. securityfilter will only be applied
to the URLs that are being served by the context (webapp) in which
securityfilter is configured. If you have multiple webapps, each with
securityfilter running, they don't communicate, so you'll have to
authentication separately for each one.

If you had your CGI scripts deployed into the ROOT application (that is,
the default app that is used if no other context prefixes match (like
/my-app), and you had securityfilter running both in the ROOT and some
other context (like /my-app), then you could be running into this
separate authentication problem.

>> Do you have container-managed security set up in Tomcat's server.xml as
>> well as securityfilter? That might be confusing things. Remember that
>> securityfilter-config.xml should contain all your <security-constraint>
>> setup, and web.xml should have none of this stuff leftover. Otherwise,
>> you'll have sf and Tomcat fighting each other.
> 
> 
> I am not sure if it makes any difference, but I had kept the security-role
> inside web.xml. I have since moved it into securityfilter-config.xml. It
> doesn't seem to make a difference one way or another.

I don't believe <security-role> is enough to trigger the use of Tomcat's
container-managed authentication and authorization. I think you need
<security-constraint> in order for TC to start doing that. So, you
should be okay.

> Thanks for your help. It was important for me to be told that securityfilter
> should be able to work with error handling and CGI emulation.

Yeah, securityfilter hardly does anything at all, really. If
authentication is necessary, it sends those requests to the login page.
Submitting the login page obviously invokes securityfilter to do the
authentication. After that, URLs are checked for authorization
requirements and 403 responses are sent for requests for which
authenticated users are not authorized.

There's no messing with headers, proxying of requests or anything like
that (except that, after successful authentication, the original request
that triggered the authentication is "re-played" back to the servlet
container). You should be able to wrap nearly everything to
securityfilter and it should work (relatively) transparently.

-chris

Re: [securityfilter-user] filter-mapping

[Martin D. <mar...@gm...>]

I investigated the problems I reported much deeper and, with help from the
pointers you gave me, I was able to fix the issues with regards to CGI
emulation and error handling. See below for more details.

On Wed, Feb 11, 2009 at 3:36 PM, Christopher Schultz <
ch...@ch...> wrote:

> Martin,
>
> On 2/11/2009 1:19 PM, Martin Dubuc wrote:
> > I have experimented with security-filter the last few days and although
> it
> > solves some of the issues I was trying to fix for a long time, there are
> > things I can't do anymore with this filter in place.
> >
> > One area of concern is CGI scripts. I use CGI emulation in Tomcat to run
> > some legacy CGI scripts and it looks like these scripts are not
> compatible
> > with the security-filter. I also have some issues with some files, for
> > instance the error.jsp file that should be displayed when an exception is
> > thrown. Currently, when an exception occurs, the login form is presented
> > instead of error.jsp (it looks like the system redirects to login.jsp
> > instead of error.jsp).
>
> If you are getting login.jsp showing instead of error.jsp, then you
> probably have your <security-constraint> elements (in
> securityfilter-config.xml) set to something too restrictive. Remember if
> error.jsp is protected, you'll be forced to login before you can see it ;)
>

I have looked into the error.jsp redirect issue and found that there were
problems with my code. Nothing to worry about as far as securityfilter is
concerned.


> Can you explain a little more about the CGI stuff? I don't see why
> securityfilter would be interfering with your CGI scripts. Can you give
> me some more details?
>

I think I figured out what the problem is. The CGI scripts on my Web server
were global to all applications. Is it possible that in that context when
they are invoked, since they are not part of my application, the server
thinks it needs to authenticate the user once again, which triggers the Web
server to invoke the securityfilter? I solved my issue by moving the CGI
scripts inside the application and now things are working as expected.


> > I thought I might be able to get around these problems by specifying a
> > filter mapping, but I can't get that to work. I would like to have the
> > security filter applied only on files that end with the jsf extension
> (for
> > instance main.jsf), but I can't get this to work. If I specify a filter
> > mapping /main.jsf, I can never get out of the login page (after I submit
> the
> > login page, the system redisplays the login page again and again). There
> are
> > no error logs reported in the catalina.out file.
> >
> > Even specifying a filter mapping of *.jsf does not work. If I specify the
> > following filter:
> >
> >     <filter-mapping>
> >         <filter-name>Security Filter</filter-name>
> >         <url-pattern>*.jsf</url-pattern>
> >     </filter-mapping>
> >
> > I get an HTTP status 404 when I try to access any page in my application.
>
> This looks like a legitimate filter mapping, and should only apply to
> *.jsf files (see section 11 of the servlet spec for more information).
>
> Are saying that a filter-mapping for /main.jsf causes all pages to
> redirect to the login page no matter what? That's odd, since
> securityfilter should only be kicking-in for requests to /main.jsf. And,
> if you use a filter-mapping of *.jsp then everything 404s?
>
> Hmm... if securityfilter were actually failing, I would expect a 500
> Internal Server Error, not a 404.
>

I am not sure why the filters didn't load properly, but in the end, I don't
need to worry about this anymore. Moving the CGI scripts inside the
application has cleared the redirection to login.jsp problem and I don't
need special filters to bypass other filters like securityfilter.


> Do you have container-managed security set up in Tomcat's server.xml as
> well as securityfilter? That might be confusing things. Remember that
> securityfilter-config.xml should contain all your <security-constraint>
> setup, and web.xml should have none of this stuff leftover. Otherwise,
> you'll have sf and Tomcat fighting each other.


I am not sure if it makes any difference, but I had kept the security-role
inside web.xml. I have since moved it into securityfilter-config.xml. It
doesn't seem to make a difference one way or another.


> Also note that you'll have to map j_security_check to securityfilter,
> otherwise you'll never be able to log in ;)
>
> > When I run certain CGI scripts, I get this log:
> > INFO: cgi: runCGI: bad header line "<html><head><meta
> http-equiv="refresh"
> > content="0;URL=/system/login.jsp"></head></html>
> >
> > It looks like when I try to run this script, the application redirects to
> > login.jsp first and this confuses the CGI emulator.
>
> securityfilter uses 302 FOUND HTTP responses to perform redirections,
> not META HTTP-EQUIV tricks. Whatever you are seeing here is coming from
> somewhere else.
>
> > Some other CGI scripts, the application just transitions to the login
> page
> > and I don't see any error or info logs in catalina.out.
> >
> > Do you understand what might be happening and is there a solution?
>
> Honestly, I have no idea what's going on. Let's get some more info. Try
> to keep your responses on the mailing list.
>
> -chris
>
>
Thanks for your help. It was important for me to be told that securityfilter
should be able to work with error handling and CGI emulation.

Martin

Re: [securityfilter-user] filter-mapping

[Christopher S. <ch...@ch...>]

Martin,

On 2/11/2009 1:19 PM, Martin Dubuc wrote:
> I have experimented with security-filter the last few days and although it
> solves some of the issues I was trying to fix for a long time, there are
> things I can't do anymore with this filter in place.
> 
> One area of concern is CGI scripts. I use CGI emulation in Tomcat to run
> some legacy CGI scripts and it looks like these scripts are not compatible
> with the security-filter. I also have some issues with some files, for
> instance the error.jsp file that should be displayed when an exception is
> thrown. Currently, when an exception occurs, the login form is presented
> instead of error.jsp (it looks like the system redirects to login.jsp
> instead of error.jsp).

If you are getting login.jsp showing instead of error.jsp, then you
probably have your <security-constraint> elements (in
securityfilter-config.xml) set to something too restrictive. Remember if
error.jsp is protected, you'll be forced to login before you can see it ;)

Can you explain a little more about the CGI stuff? I don't see why
securityfilter would be interfering with your CGI scripts. Can you give
me some more details?

> I thought I might be able to get around these problems by specifying a
> filter mapping, but I can't get that to work. I would like to have the
> security filter applied only on files that end with the jsf extension (for
> instance main.jsf), but I can't get this to work. If I specify a filter
> mapping /main.jsf, I can never get out of the login page (after I submit the
> login page, the system redisplays the login page again and again). There are
> no error logs reported in the catalina.out file.
>
> Even specifying a filter mapping of *.jsf does not work. If I specify the
> following filter:
> 
>     <filter-mapping>
>         <filter-name>Security Filter</filter-name>
>         <url-pattern>*.jsf</url-pattern>
>     </filter-mapping>
> 
> I get an HTTP status 404 when I try to access any page in my application.

This looks like a legitimate filter mapping, and should only apply to
*.jsf files (see section 11 of the servlet spec for more information).

Are saying that a filter-mapping for /main.jsf causes all pages to
redirect to the login page no matter what? That's odd, since
securityfilter should only be kicking-in for requests to /main.jsf. And,
if you use a filter-mapping of *.jsp then everything 404s?

Hmm... if securityfilter were actually failing, I would expect a 500
Internal Server Error, not a 404.

Do you have container-managed security set up in Tomcat's server.xml as
well as securityfilter? That might be confusing things. Remember that
securityfilter-config.xml should contain all your <security-constraint>
setup, and web.xml should have none of this stuff leftover. Otherwise,
you'll have sf and Tomcat fighting each other.

Also note that you'll have to map j_security_check to securityfilter,
otherwise you'll never be able to log in ;)

> When I run certain CGI scripts, I get this log:
> INFO: cgi: runCGI: bad header line "<html><head><meta http-equiv="refresh"
> content="0;URL=/system/login.jsp"></head></html>
> 
> It looks like when I try to run this script, the application redirects to
> login.jsp first and this confuses the CGI emulator.

securityfilter uses 302 FOUND HTTP responses to perform redirections,
not META HTTP-EQUIV tricks. Whatever you are seeing here is coming from
somewhere else.

> Some other CGI scripts, the application just transitions to the login page
> and I don't see any error or info logs in catalina.out.
> 
> Do you understand what might be happening and is there a solution?

Honestly, I have no idea what's going on. Let's get some more info. Try
to keep your responses on the mailing list.

-chris

Re: [securityfilter-user] TrivialCatalinaRealm vs. TrivialSecurityRealm

[Christopher S. <ch...@ch...>]

Martin,

Martin Dubuc wrote:
> I have seen to examples of realms, TrivialSecurityRealm and
> TrivialCatalinaRealm, in the securityfilter filter and am wondering what
> is the difference between these two. When would one want to use one over
> the other?

These Realm implementations are intended to be used as demonstration
realms; they shouldn't be used for production.

TrivialSecurityRealm has hard-coded username, password, and roles
refined, and is a securityfilter-specific class.

TrivialCatalinaRealm is the same as TrivialSecurityRealm except that it
implements Tomcat's Realm interface instead of securityfilter's internal
Realm interface.

-chris

[securityfilter-user] TrivialCatalinaRealm vs. TrivialSecurityRealm

[Martin D. <mar...@gm...>]

I have seen to examples of realms, TrivialSecurityRealm and
TrivialCatalinaRealm, in the securityfilter filter and am wondering what is
the difference between these two. When would one want to use one over the
other?

Martin

Re: [securityfilter-user] Security Filter not activated within Eclipse + Web Tools Platform

[Jonathan O'D. <jon...@eu...>]

 
Hi Torgeir,

Thanks for your suggestion - that's not the problem - I have
securityfilter.jar in the WEB-INF/lib folder and if I remove it, on startup,
I get the following error in the tomcat logs :

2008-11-18 14:36:20 StandardContext[/eurokom6]: Exception starting filter
Security Filter
java.lang.ClassNotFoundException: org.securityfilter.filter.SecurityFilter
	at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav
a:1541)
	at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav
a:1386)
	at
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilter
Config.java:205)

etc...


When I replace the securityfilter.jar, the .jar deploys fine : 

2008-11-18 14:37:52 WebappLoader[/eurokom6]: Deploy JAR
/WEB-INF/lib/securityfilter.jar to
C:\Jonathan\workspace8\.metadata\.plugins\org.eclipse.wst.server.core\tmp1\w
tpwebapps\eurokom6\WEB-INF\lib\securityfilter.jar

Thanks again,

Jonathan.


-----Original Message-----
From: Torgeir Veimo [mailto:to...@po...] 
Sent: 18 November 2008 13:11
To: Jonathan O'Donovan
Cc: sec...@li...
Subject: Re: [securityfilter-user] Security Filter not activated within
Eclipse + Web Tools Platform


On 18 Nov 2008, at 22:53, Jonathan O'Donovan wrote:

> I am wondering if anyone can point me in the right direction here.  
> Any suggestions would be helpful.


You're not able to log in? Maybe the class for the configured realm is not
found in the specific class loader setup employed by eclipse?

--
Torgeir Veimo
to...@po...

Re: [securityfilter-user] Security Filter not activated within Eclipse + Web Tools Platform

[Torgeir V. <to...@po...>]

On 18 Nov 2008, at 22:53, Jonathan O'Donovan wrote:

> I am wondering if anyone can point me in the right direction here.  
> Any suggestions would be helpful.


You're not able to log in? Maybe the class for the configured realm is  
not found in the specific class loader setup employed by eclipse?

-- 
Torgeir Veimo
to...@po...

[securityfilter-user] Security Filter not activated within Eclipse + Web Tools Platform

[Jonathan O'D. <jon...@eu...>]

Hi All,

I am having a problem with the securityfilter when deploying using Web Tools
Platform in Eclipse. Does anyone know of any issues when using the security
filter with Eclipse, specifically with the Web tools platform?. I have read
the following 
 
http://wiki.eclipse.org/WTP_Tomcat_FAQ.
 
Note that when launching a server with the WTP, a new instance of the server
is created under a new cataline.base. This may be causing the problem?
 
 
I am running the following 
 
Eclipse Ganymede V3.4.1
Web Tools : 1.1.20x Tomcat 4.1
JSDK 1.6

 
I have added the project to the server with no problems and can execute/step
through servlets on the server. If I disable the security filter by
commenting
it out of web.xml the site functions the same as a non Eclipse deploy.
However, if I include the security config, it does not appear to be
functioning and I cannot log into my site when running/debugging within
Eclipse.

The security filter is set up in web.xml as follows :   <filter>
<filter-name>Security Filter</filter-name>
<filter-class>org.securityfilter.filter.SecurityFilter</filter-class>
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/securityfilter-config.xml</param-value>
<description>Configuration file location (this is the default
value)</description>
</init-param>
<init-param>
<param-name>validate</param-name>
<param-value>true</param-value>
<description>Validate config file if set to true</description>
</init-param>
<init-param>
<param-name>loginSubmitPattern</param-name>
<param-value>/sflogin</param-value>
<description>This is the action used by the login form (in place of the
standard "j_security_check")</description>
</init-param>
</filter>  <!-- map all requests to the SecurityFilter, control what it does
with configuration settings -->

  <filter-mapping>
<filter-name>Security Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>  <security-role>
<role-name>administrator</role-name>
</security-role>
<security-role>
<role-name>user</role-name>
</security-role>




The security filter config file is as follows :



<securityfilter-config>


<security-constraint>
<display-name>The Customer area of the XXX web site.</display-name>
<web-resource-collection>
<web-resource-name>UserArea</web-resource-name>
<url-pattern>/servUserArea</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>administrator</role-name>
<role-name>user</role-name>
</auth-constraint>
</security-constraint>


<security-constraint>
<display-name>Administration of the XX Web site.</display-name>
<web-resource-collection>
<web-resource-name>AdminArea</web-resource-name>
<url-pattern>/servAdminArea</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>administrator</role-name>
</auth-constraint>
</security-constraint>



<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/servPublicArea?view=login</form-login-page>
<form-error-page>/servPublicArea?view=loginerror</form-error-page>
<form-default-page>/servUserArea?view=usermain</form-default-page>
</form-login-config>
</login-config>



<!-- start with a Catalina realm adapter to wrap the Catalina realm defined
below -->
<realm className="org.securityfilter.realm.catalina.CatalinaRealmAdapter" />



<realm className="org.apache.catalina.realm.JDBCRealm">
<realm-param name="connectionName" value="client"/>
<realm-param name="connectionPassword" value="XXX"/>
<realm-param name="connectionURL" value="XXX"/>
<realm-param name="driverName" value="oracle.jdbc.driver.OracleDriver"/>
<realm-param name="userCredCol" value="password"/>
<realm-param name="userNameCol" value="username"/>
<realm-param name="userTable" value="auth_users"/>
<realm-param name="roleNameCol" value="role_name"/>
<realm-param name="userRoleTable" value="tomcat_roles"/>
<realm-param name="debug" value="1"/>
</realm>


</securityfilter-config>



The site works fine when I set it up on a normal Tomcat installation (ie
without Eclipse/WTP) so I know there is no problem connecting to the
database realm.

I am wondering if anyone can point me in the right direction here. Any
suggestions would be helpful.

Many thanks in advance,
Jonathan.

Re: [securityfilter-user] strange redirect issue with user-data-constraint

[Christopher S. <ch...@ch...>]

Matthew,

Matthew Hixson wrote:
> The problem I'm seeing is that on our testing and production machines  
> the browser gets stuck in an infinite loop.  Hitting the page causes a  
> 302 Temporarily Moved response to be sent to the browser.  However,  
> all of the following response are exactly the same so its telling a  
> client that asks for https://www.site.com/foo/bar/index.jsp that the  
> page has been moved to https://www.site.com/foo/bar/index.jsp.

Hmm. This is a new feature that has not been extensively tested, so it's
entirely possible that there's a bug in my implementation.

If you could create a small WAR that demonstrates the problem it would
help me out a lot.

Thanks,

-chris

Re: [securityfilter-user] strange redirect issue with user-data-constraint

[Matthew H. <hi...@po...>]

On Nov 12, 2008, at 7:41 PM, Torgeir Veimo wrote:

>
> On 13 Nov 2008, at 13:23, Matthew Hixson wrote:
>
>> Any ideas?
>
>
> Is there an apache frontend on the production systems?

No, there isn't.
  -M@

Re: [securityfilter-user] strange redirect issue with user-data-constraint

[Torgeir V. <to...@po...>]

On 13 Nov 2008, at 13:23, Matthew Hixson wrote:

> Any ideas?


Is there an apache frontend on the production systems?

-- 
Torgeir Veimo
to...@po...