Hi Les, Thanks for your mail. I solved the filter problem... I again used more restrictive rules first, and also fixed my url typos :-)
About AuthorizingRealm, I do not subclass any Shiro class, just set custom queries for JdbcRealm. I use JDO for data access in my project, but kept authorization using JDBC (when I get some time, I'll try subclassing to use JDO). Thanks for the cache clearing tip. Once I stress out some other issues, I'll post them ;-) Thanks again! On Wed, Jul 15, 2009 at 2:09 AM, Les Hazlewood <[email protected]>wrote: > 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! >>>>>> >>>>> >>>>> >>>> >>> >> >
