-
Correct: securityfilter was originally written to work with the Tomcat 4 Realms. In the intervening versions, changes within Tomcat have been made that break the interoperability between securityfilter and Tomcat's Realm implementations.
Even when the API is compatible (for instance, with Tomcat 5.0 or 5.5, I think), catalina.jar now has dependencies on the actual runtime instances of...
2009-09-29 20:37:36 UTC in SecurityFilter
-
Mats,
I don't believe anyone has done this, primarily because it would break compatibility with the servlet specification. sf uses PCRE's internally, so it should not be hard to add general regular expression capabilities to the URL matching code. Note that the next major version of sf is basically being re-written from scratch, along with the pattern-matching code. This will give me the...
2009-08-12 14:26:47 UTC in SecurityFilter
-
Mats,
For option #1, there is no need to recompile securityfilter. If you write a class called org.securityfilter.authenticator.BasicAuthenticator and put it in your WEB-INF/classes directory, it /should/ override the one in the sf JAR file.
A custom realm is not necessary as pivot points out: merely putting the Principal in the proper place in the session will cause sf to honor it. (This...
2009-08-10 20:04:54 UTC in SecurityFilter
-
Mats,
There is no option in securityfilter to skip the authentication step. You are free to use the code as you see fit, though: you could write your own filter that uses the code available in securityfilter to perform only authentication.
You could also adapt your existing filter to be an authentication Realm for securityfilter and use them together, instead of trying to split...
2009-08-09 22:02:52 UTC in SecurityFilter
