Hi Mad, It looks like some things are out of place. The key is to have the most specific/qualified URL first, with the more generic/catch-all ones at the bottom of the list. Think of it as 'the first match wins'. So you would probably want your url config to be this:
/web/app/user/role1/**= authc,roles[USER_ROLE1] /web/app/user/role2/**= authc,roles[USER_ROLE2] /web/app/user/** = authc,roles[USER] /web/app/admin/role1/** = authc,roles[ADM_ROLE1] /web/app/admin/role2/** = authc,roles[ADM_ROLE2] /web/app/admin/** = authc,roles[ADM] /web/app/** = authc If for example, the last two lines were reversed, say to: /web/app/** = authc /web/app/admin/** = authc,roles[ADM] and a request for /web/app/some/path/here.htm came in, then only the 'authc' filter chain would be executed, because it would scan through the URL definitions, and the '/web/app/**' would definitely match the '/web/app/some/path/here.htm' request URL thereby 'short circuiting' the remaining URL definitions. So as a rule of thumb, always ensure your more specific URLs are listed at the top and the more generic ones at the bottom. Also note that only the chain for that particulary matching URL pattern is executed - it does not execute filter chains for every matching pattern, which is why I added the 'authc' to the front of all the url patterns above - to indicate that a user should be both authenticated _and_ have a certain role. Of course your application may not actually require that - I was just showing an example. As far as authorization info invalidation, and assuming you're subclassing AuthorizingRealm, you can call the protected clearCachedAuthorizationInfo(PrincipalCollection pc) method from the subclass. This will clear out any cached authorization information that may exist. Typically people will call this when they modify the authz model at runtime to ensure the next security check will pick up (and cache) the newest information. Ehcache is still supported as part of the build's apache-shiro-ehcache module, it is just not enabled by default. You must explicitly configure an Ehcache-based CacheManager. The apache-shiro-all-<version>.jar file contains these classes as well as (naturally) the apache-shiro-ehcache-<version>.jar. I hope this helps! Cheers, Les On Sun, Jul 12, 2009 at 5:09 PM, mad rug <[email protected]> wrote: > Hi, > > I'm still waiting for some help on this. I tried changing the way these > rules are written (more restrictive first, list full requirements list - as > authc, roles[X]) but nothing worked. I really don't know what I'm missing. > > Any help is welcome! > Cheers! > > > On Wed, Jul 8, 2009 at 9:24 AM, mad rug <[email protected]> wrote: > >> Hi, >> >> Well, I could solve half the problem. I included >> configClassName=org.apache.shiro.spring.SpringIniWebConfiguration and >> securityManagerBeanName=securityManager in web.xml and now I can check for >> roles. I did it programatically and through tags and it worked nice. >> >> My url filters are not working the way I expected yet. Here is my web.xml >> filter definition: >> <filter> >> <filter-name>ShiroFilter</filter-name> >> >> <filter-class>org.apache.shiro.web.servlet.ShiroFilter</filter-class> >> <init-param> >> <param-name>configClassName</param-name> >> >> <param-value>org.apache.shiro.spring.SpringIniWebConfiguration</param-value> >> </init-param> >> <init-param> >> <param-name>securityManagerBeanName</param-name> >> <param-value>securityManager</param-value> >> </init-param> >> <init-param> >> <param-name>config</param-name> >> <param-value> >> [filters] >> shiro.loginUrl = /web/login >> authc.successUrl = /web/app/home >> >> [urls] >> /web/app/**=authc >> /web/app/admin/**= roles[ADM] >> /web/app/admin/role1/**= roles[ADM_ROLE1] >> /web/app/admin/role2/**= roles[ADM_ROLE2] >> /web/app/user/**= roles[USER] >> /web/app/user/role1/**= roles[USER_ROLE2] >> /web/app/user/role2/**= roles[USER_ROLE2] >> </param-value> >> </init-param> >> </filter> >> <filter-mapping> >> <filter-name>ShiroFilter</filter-name> >> <url-pattern>/web/*</url-pattern> >> </filter-mapping> >> >> Authentication is correctly requested for any /web/app url, but any other >> role applies. I can use a ADM user to access a url like /web/app/user/role1 >> without restrictions. This is the log for the page request: >> [org.apache.shiro.web.servlet.ShiroFilter] No security filter chain >> configured for the current request. Using default. >> >> And since I'm here, a few questions: >> - as Shiro does not handle roles updates (it does not store them back), >> how can I invalidate/refresh roles cache for some user or a group of users >> when I know it is needed? >> - without ehcache (looks like the devs removed them), what's the best >> production-oriented cache solution/implementation available? >> >> Thanks again! >> >> >> On Tue, Jul 7, 2009 at 9:55 PM, mad rug <[email protected]> wrote: >> >>> Hi Les, >>> >>> I didn't had code problems, I just used JSecurity 0.9 because I always >>> avoid to use dev codebase. As I saw that some bug fixes were already on >>> Shiro (SHIRO-66), I replaced JSecurity. I did little testing since this >>> change, but my issues remain. This is the error calling hasRole(): >>> >>> java.lang.IllegalStateException: Configuration error: No realms have >>> been configured! One or more realms must be present to execute an >>> authorization operation. >>> at >>> org.apache.shiro.authz.ModularRealmAuthorizer.assertRealmsConfigured(ModularRealmAuthorizer.java:149) >>> at >>> org.apache.shiro.authz.ModularRealmAuthorizer.hasRole(ModularRealmAuthorizer.java:308) >>> at >>> org.apache.shiro.mgt.AuthorizingSecurityManager.hasRole(AuthorizingSecurityManager.java:182) >>> at >>> org.apache.shiro.subject.DelegatingSubject.hasRole(DelegatingSubject.java:228) >>> at mypackage.MyController.referenceData(MyController.java:99) >>> ... >>> >>> That's the same error, it was triggered in the same place, just that it >>> now throws a new exception. >>> And about shiro, was ehcache support removed? I couldn't locate >>> EhCacheManager. >>> >>> Thanks >>> >>> >>> On Tue, Jul 7, 2009 at 5:06 PM, Les Hazlewood <[email protected]>wrote: >>> >>>> Hi Mad, >>>> >>>> By your class names, that means you're using JSecurity 0.9.0 final and >>>> not using Shiro's codebase yet. Do you have any problems using the Shiro >>>> codebase? >>>> >>>> I ask because it would be much easier for me to play with things with >>>> the dev environment I already have set up centered around Shiro. >>>> >>>> Thoughts? >>>> >>>> Cheers, >>>> >>>> Les >>>> >>>> >>>> On Tue, Jul 7, 2009 at 3:15 PM, mad rug <[email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm facing some issues using JSecurity in my project. Authentication >>>>> works perfect (JDBC based login, require login for protected URLs), but >>>>> authorization is not. >>>>> I set up a JdbcRealm, following the Spring sample bundled with >>>>> JSecurity. Most of it is unchanged from the sample (I change it to my own >>>>> URLs, custom JDBC queries). >>>>> >>>>> When I debug my app and check the authenticated Subject, its >>>>> securityManager is using classpath:org/jsecurity/cache/ehcache/ehcache.xml >>>>> as config file. The first time I try to check anything involving >>>>> authorization, I get this: >>>>> 10:49:21,421 INFO [RealmSecurityManager] No Realms configured. >>>>> Defaulting to failsafe PropertiesRealm. >>>>> ... >>>>> 10:49:21,546 INFO [EhCacheManager] Using preconfigured EHCache named >>>>> [org.jsecurity.realm.text.PropertiesRealm-1-authorization] >>>>> 10:49:23,687 ERROR [[secureWeb]] Servlet.service() for servlet >>>>> secureWeb threw exception >>>>> java.util.NoSuchElementException >>>>> at java.util.Collections$EmptySet$1.next(Collections.java:2912) >>>>> at >>>>> java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1010) >>>>> at >>>>> org.jsecurity.realm.SimpleAccountRealm.getAuthorizationCacheKey(SimpleAccountRealm.java:159) >>>>> ... >>>>> >>>>> In my JBoss logs, I see that the security manager seems to be created >>>>> multiple times (the config file was read multiple times), all of getting >>>>> config from classpath:org/jsecurity/cache/ehcache/ehcache.xml, except one, >>>>> which loads my config file (classpath:myconfig-ehcache.xml). This is the >>>>> Spring config for my securityManager: >>>>> <bean id="securityManager" >>>>> class="org.jsecurity.web.DefaultWebSecurityManager"> >>>>> <property name="realm" ref="jdbcRealm"/> >>>>> <property name="sessionMode" value="jsecurity"/> >>>>> <property name="cacheManager" ref="cacheManager"/> >>>>> </bean> >>>>> <bean id="cacheManager" >>>>> class="org.jsecurity.cache.ehcache.EhCacheManager"> >>>>> <property name="cacheManagerConfigFile" > >>>>> <value>classpath:myconfig-ehcache.xml</value> >>>>> </property> >>>>> </bean> >>>>> >>>>> I believe this bean is not being injected into objects that need >>>>> security manager, and they are creating their own default copies, with >>>>> default config. For example: if I remove JSecurityFilter completely from >>>>> web.xml, one of these securityManager creations with default config is >>>>> gone. >>>>> I also just found about references in web.xml inline ini >>>>> (securityManager.cacheManager = $cacheManager), but I couldn't refer to >>>>> the >>>>> Spring managed bean. Do I have to repeat the cacheManager config in this >>>>> file (ultimately creating a second securityManager), or I can somehow >>>>> refer >>>>> to the same object created by Spring, or vice versa? I see that there is >>>>> some SpringIniWebConfiguration, but I couldn't find how to use it. >>>>> Debugging the creation of DefaultWebSecurityManagers, some of these >>>>> wrong managers are created in the stack of IniWebConfiguration, so I hope >>>>> the Spring version can help me. >>>>> >>>>> Another approach I took: I debugged a hasRole() call to see where >>>>> things went wrong, and inside RealmSecurityManager.ensureRealms() no >>>>> realms >>>>> were found, and the default PropertiesRealm was loaded. A resolved bug >>>>> (SHIRO-66) says it is caused by a securityManager which is a proxy (I >>>>> believe it is my case here, I use proxies, just don't know if the >>>>> securityManager was proxied as well). I'd like to avoid using Shiro before >>>>> 1.0, also because I'm having problems building Shiro (missing >>>>> dependencies), >>>>> and I prefer GA releases. Can I do some workaround for this? >>>>> >>>>> Additional notes, don't know if somehow relevant: >>>>> - my environment: JBoss 4.2.1, JSecurity 0.9, Spring 2.5.6, DataNucleus >>>>> Plataform 1.1 (JDO), Java 1.6. >>>>> - all my libs and dependencies (Spring, JSecurity, JCaptcha...) are on >>>>> jboss (servers libs folder); I did it to reduce deploy size; >>>>> - my DAOs and Spring beans (including security manager) are defined in >>>>> a parent application, so that the two web projects/contexts that make the >>>>> whole application can share the same beans (it works nice AFAIK). >>>>> >>>>> Well, that's a lot of info. Sorry about my previous mail, I hadn't >>>>> properly investigated the issue. Hope I can get some help now =) >>>>> Guess I said all I knew about my situation. If there is some missing >>>>> link, please tell me. >>>>> >>>>> Thanks! >>>>> >>>> >>>> >>> >> >
