You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Les Hazlewood <lh...@apache.org> on 2009/07/07 22:06:21 UTC

Re: JSecurity loading default security managers / ensureRealms() issue

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 <ma...@gmail.com> 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!
>

Re: JSecurity loading default security managers / ensureRealms() issue

Posted by mad rug <ma...@gmail.com>.
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 <lh...@apache.org>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 <ma...@gmail.com> 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 <ma...@gmail.com> 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 <ma...@gmail.com> 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 <lh...@apache.org>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 <ma...@gmail.com> 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!
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: JSecurity loading default security managers / ensureRealms() issue

Posted by Les Hazlewood <lh...@apache.org>.
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 <ma...@gmail.com> 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 <ma...@gmail.com> 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 <ma...@gmail.com> 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 <lh...@apache.org>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 <ma...@gmail.com> 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!
>>>>>
>>>>
>>>>
>>>
>>
>

Re: JSecurity loading default security managers / ensureRealms() issue

Posted by mad rug <ma...@gmail.com>.
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 <ma...@gmail.com> 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 <ma...@gmail.com> 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 <lh...@apache.org>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 <ma...@gmail.com> 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!
>>>>
>>>
>>>
>>
>

Re: JSecurity loading default security managers / ensureRealms() issue

Posted by mad rug <ma...@gmail.com>.
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 <ma...@gmail.com> 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 <lh...@apache.org>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 <ma...@gmail.com> 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!
>>>
>>
>>
>

Re: JSecurity loading default security managers / ensureRealms() issue

Posted by mad rug <ma...@gmail.com>.
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 <lh...@apache.org> 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 <ma...@gmail.com> 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!
>>
>
>