How to exclude in object definitions store

Hi,

I want to secure everything but my welcome and logon page in my filterInvocationInterceptor. I do not have a /secure prefix. How can I accomplish that, without having to specify [a-z&&[^lw]] (everything not starting with l (of logon) or w (of welcome)) and [l[a-z&&[^o]] (not starting with lo) ... ? I just want to define the pages I don't want to secure.

I tried to define as first item \A/logon.*\Z= (to set it to no role required) but that gives a NullPointerException.

Stefaan.

http://www.mail-archive.com/acegisec.../msg00191.html

Copy for benefit of the forums:

This is presently not possible. There are two main ways it could be done:

AbstractSecurityInterceptor gets new code after its if (attr != null) and debug message. The new code iterates attr and if it finds any "anonymous" property, it immediately calls callback.proceedWithObject(object). The problems with this approach include the ContextHolder may be null or not contain a SecureContext, any Authentication object on it may be incorrect, and no run as replacement may take place. This is because these capabilities are part of AbstractSecurityInterceptor and rely on the SecureContext being on the ContextHolder, which for truly anonymous users is not possible. For securing HTTP requests these issues are somewhat benign, but a major problem if any invocations take place to business objects that want to check the ContextHolder or require elevated permissions.

The alternative (better) approach is to write a filter that checks for a HttpSession attribute keyed against HttpSessionIntegrationFitler.ACEGI_SECURITY_AUTHEN TICATION_KEY. If it is null, create an Authentication object with a username and password acceptable to your authentication manager. This will in turn be populated onto the ContextHolder by the AutoIntegrationFilter or HttpSessionIntegrationFilter (your choice). The benefit of this approach is there aren't any "magic" keywords, stronger security is offered due to full execution of the Acegi Security stack, and you can have different types of anonymous users for different areas of your application. On a less positive note, the AbstractSecurityIntercetor will not be able to tell between this "automatic" Authentication object and a "real" Authentication object. Being unable to distinguish, it will always see a valid Authentication object and thus never throw a AuthenticationCredentialsNotFoundException. This will mean you cannot have the webapp automatically guide the user into logging in. Instead you'll need some sort of advanced handling of an AccessDeniedException, as it might genuinely be access denied or it might simply be the user hasn't logged in properly. This is normally handled by SecurityEnforcementFilter sending a 403 code. You might like to subclass SecurityEnforcementFilter and have it automatically clear the HttpSession attribute and redirect to a login page (in the event of an "automatic" Authentication object) or send the 403 if they're already logged in.

As you can see, it's not as black and white as it first appears. You'd probably have less work to simply make your request URIs reflect the sample application. ie:

/* = not secured (also where login form lives)
/some_subdirectory/* = secured