You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@shiro.apache.org by Harshdeep S Jawanda <hs...@gmail.com> on 2017/03/27 11:53:24 UTC

Session management on GAE

Hi all,

I am trying to get a better understanding of how Shiro does session
management on Google App Engine (a few things seem to be behaving
counter-intuitively), so I'll start by asking some questions:

   1. Does Shiro use the _ah_SESSION entities to manage session persistence
   on GAE?
   2. If so, what is the relationship between the key (name/ID) of the
   _ah_SESSION entity and the value stored in the JSESSIONID cookie?
   3. To put it differently, how does DefaultWebSessionManager know that if
   the JSESSIONID value is X, I have to lookup entity Y in the GAE datastore?

I have set the session-timeout to 1440 (24 hours) in web.xml, but logins
seem to expire before then (cookie life is set to 5 days): if I login now,
do nothing after that, and refresh the page in, say, 13 hours, I am shown
as logged out (depending entirely on Shiro for logins, not doing any other
hanky-panky).

It does seem like the value of the _expires field in the _ah_SESSION
entities is being set to 24 hours from now.

Regards,
Harshdeep S Jawanda

Re: Session management on GAE

Posted by Harshdeep S Jawanda <hs...@gmail.com>.

I am only aware of session-config in web.xml for setting session timeout.
That only sets the cookie to last for the duration of the browser session.

Sent from my Moto X2

On 29-Mar-2017 22:05, "Harshdeep S Jawanda" <hs...@gmail.com> wrote:

> What are you referring to?
>
> GAE only supports Servlet 2.5 specification (so far). I am unaware of any
> configuration in web.xml (which is supported) that will tell the Servlet
> container to keep the session cookie's expires field refreshed upon every
> activity.
>
> Sent from my Moto X2
>
> On 29-Mar-2017 19:29, "Brian Demers" <br...@gmail.com> wrote:
>
>> You _should_ be able to do this with standard servlet configuration (a
>> web.xml, or a equivalent code). Shiro will just use the available session
>> from your container.
>>
>> On Wed, Mar 29, 2017 at 12:56 AM, Harshdeep S Jawanda <
>> hsjawanda@gmail.com> wrote:
>>
>>> I have verified the following:
>>>
>>>    - ServletContainerSessionManager integrates with the underlying way
>>>    in which GAE manages HTTP sessions, so should be the choice for people
>>>    using Shiro on GAE.
>>>    - Prepending _ahs to the value of JSESSIONID cookie gives the ID of
>>>    the _ah_SESSION entity in the GAE datastore (should this data be of use to
>>>    anybody else in the future).
>>>    - Setting session-timeout in web.xml works on GAE also (I'd had some
>>>    doubts regarding this).
>>>    - The JSESSIONID cookie resulting from the Shiro login process has
>>>    no expires value, therefore is valid for the current session only.
>>>
>>> Here is what I want to achieve:
>>>
>>>    1. I want to set an expires value on the JSESSIONID cookie so that
>>>    it isn't lost when the user closes the browser.
>>>       1. I can achieve this by setting the maxAge of the cookie
>>>       explicitly in my login handler (after successful login). However this still
>>>       leaves behind one issue...
>>>       2. Just like the _expires value of the _ah_SESSION entity gets
>>>    updated every time a logged-in user uses the site (so that session remains
>>>    valid for X time from last activity), I want the expires value of the
>>>    JSESSIONID cookie to also get updated.
>>>
>>> How do I achieve this 2nd part? Shiro doesn't seem to handle this
>>> automatically: is there some setting I have missed? Remember, I have to use
>>> ServletContainerSessionManager and it doesn't have the
>>> sessionIdCookie.maxAge property (plus I don't think the expires value gets
>>> auto-updated every time anyway).
>>>
>>> Is my only viable option to create my own Filter?
>>>
>>> Or does an auto-refreshing cookie leave a security hole and is therefore
>>> inadvisable?
>>>
>>> Regards,
>>> Harshdeep S Jawanda
>>>
>>> On 29 March 2017 at 06:42, Harshdeep S Jawanda <hs...@gmail.com>
>>> wrote:
>>>
>>>> But where does DefaultWebSessionManager keep the session? In RAM? Then
>>>> how and when  does it decide to end a session?
>>>>
>>>> Because of App Engine's peculiar nature (instances may be stopped and
>>>> started at any time based on load, and consecutive calls from the same user
>>>> may end up going to different instances), sessions have to be stored in
>>>> their built-in Datastore.
>>>>
>>>> I had always thought that Shiro on GAE interacts with these sessions
>>>> and uses them to correspond its own idea/implementation of sessions. You're
>>>> saying that's not the case?
>>>>
>>>>
>>>> Regards,
>>>> Harshdeep S Jawanda
>>>>
>>>> On 29 March 2017 at 02:36, Brian Demers <br...@gmail.com> wrote:
>>>>
>>>>> I cannot speak to anything specific to GAE, but the
>>>>> DefaultWebSessionManager "owns" the creation of the sessionId.  If you want
>>>>> the container to control it, then you would use the
>>>>> ServletContainerSessionManager:
>>>>>
>>>>> https://github.com/apache/shiro/blob/master/web/src/main/jav
>>>>> a/org/apache/shiro/web/session/mgt/ServletContainerSessionManager.java
>>>>>
>>>>> On Mon, Mar 27, 2017 at 7:53 AM, Harshdeep S Jawanda <
>>>>> hsjawanda@gmail.com> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I am trying to get a better understanding of how Shiro does session
>>>>>> management on Google App Engine (a few things seem to be behaving
>>>>>> counter-intuitively), so I'll start by asking some questions:
>>>>>>
>>>>>>    1. Does Shiro use the _ah_SESSION entities to manage session
>>>>>>    persistence on GAE?
>>>>>>    2. If so, what is the relationship between the key (name/ID) of
>>>>>>    the _ah_SESSION entity and the value stored in the JSESSIONID cookie?
>>>>>>    3. To put it differently, how does DefaultWebSessionManager know
>>>>>>    that if the JSESSIONID value is X, I have to lookup entity Y in the GAE
>>>>>>    datastore?
>>>>>>
>>>>>> I have set the session-timeout to 1440 (24 hours) in web.xml, but
>>>>>> logins seem to expire before then (cookie life is set to 5 days): if I
>>>>>> login now, do nothing after that, and refresh the page in, say, 13 hours, I
>>>>>> am shown as logged out (depending entirely on Shiro for logins, not doing
>>>>>> any other hanky-panky).
>>>>>>
>>>>>> It does seem like the value of the _expires field in the _ah_SESSION
>>>>>> entities is being set to 24 hours from now.
>>>>>>
>>>>>> Regards,
>>>>>> Harshdeep S Jawanda
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>

Re: Session management on GAE

Posted by Harshdeep S Jawanda <hs...@gmail.com>.

What are you referring to?

GAE only supports Servlet 2.5 specification (so far). I am unaware of any
configuration in web.xml (which is supported) that will tell the Servlet
container to keep the session cookie's expires field refreshed upon every
activity.

Sent from my Moto X2

On 29-Mar-2017 19:29, "Brian Demers" <br...@gmail.com> wrote:

> You _should_ be able to do this with standard servlet configuration (a
> web.xml, or a equivalent code). Shiro will just use the available session
> from your container.
>
> On Wed, Mar 29, 2017 at 12:56 AM, Harshdeep S Jawanda <hsjawanda@gmail.com
> > wrote:
>
>> I have verified the following:
>>
>>    - ServletContainerSessionManager integrates with the underlying way
>>    in which GAE manages HTTP sessions, so should be the choice for people
>>    using Shiro on GAE.
>>    - Prepending _ahs to the value of JSESSIONID cookie gives the ID of
>>    the _ah_SESSION entity in the GAE datastore (should this data be of use to
>>    anybody else in the future).
>>    - Setting session-timeout in web.xml works on GAE also (I'd had some
>>    doubts regarding this).
>>    - The JSESSIONID cookie resulting from the Shiro login process has no
>>    expires value, therefore is valid for the current session only.
>>
>> Here is what I want to achieve:
>>
>>    1. I want to set an expires value on the JSESSIONID cookie so that it
>>    isn't lost when the user closes the browser.
>>       1. I can achieve this by setting the maxAge of the cookie
>>       explicitly in my login handler (after successful login). However this still
>>       leaves behind one issue...
>>       2. Just like the _expires value of the _ah_SESSION entity gets
>>    updated every time a logged-in user uses the site (so that session remains
>>    valid for X time from last activity), I want the expires value of the
>>    JSESSIONID cookie to also get updated.
>>
>> How do I achieve this 2nd part? Shiro doesn't seem to handle this
>> automatically: is there some setting I have missed? Remember, I have to use
>> ServletContainerSessionManager and it doesn't have the
>> sessionIdCookie.maxAge property (plus I don't think the expires value gets
>> auto-updated every time anyway).
>>
>> Is my only viable option to create my own Filter?
>>
>> Or does an auto-refreshing cookie leave a security hole and is therefore
>> inadvisable?
>>
>> Regards,
>> Harshdeep S Jawanda
>>
>> On 29 March 2017 at 06:42, Harshdeep S Jawanda <hs...@gmail.com>
>> wrote:
>>
>>> But where does DefaultWebSessionManager keep the session? In RAM? Then
>>> how and when  does it decide to end a session?
>>>
>>> Because of App Engine's peculiar nature (instances may be stopped and
>>> started at any time based on load, and consecutive calls from the same user
>>> may end up going to different instances), sessions have to be stored in
>>> their built-in Datastore.
>>>
>>> I had always thought that Shiro on GAE interacts with these sessions and
>>> uses them to correspond its own idea/implementation of sessions. You're
>>> saying that's not the case?
>>>
>>>
>>> Regards,
>>> Harshdeep S Jawanda
>>>
>>> On 29 March 2017 at 02:36, Brian Demers <br...@gmail.com> wrote:
>>>
>>>> I cannot speak to anything specific to GAE, but the
>>>> DefaultWebSessionManager "owns" the creation of the sessionId.  If you want
>>>> the container to control it, then you would use the
>>>> ServletContainerSessionManager:
>>>>
>>>> https://github.com/apache/shiro/blob/master/web/src/main/jav
>>>> a/org/apache/shiro/web/session/mgt/ServletContainerSessionManager.java
>>>>
>>>> On Mon, Mar 27, 2017 at 7:53 AM, Harshdeep S Jawanda <
>>>> hsjawanda@gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am trying to get a better understanding of how Shiro does session
>>>>> management on Google App Engine (a few things seem to be behaving
>>>>> counter-intuitively), so I'll start by asking some questions:
>>>>>
>>>>>    1. Does Shiro use the _ah_SESSION entities to manage session
>>>>>    persistence on GAE?
>>>>>    2. If so, what is the relationship between the key (name/ID) of
>>>>>    the _ah_SESSION entity and the value stored in the JSESSIONID cookie?
>>>>>    3. To put it differently, how does DefaultWebSessionManager know
>>>>>    that if the JSESSIONID value is X, I have to lookup entity Y in the GAE
>>>>>    datastore?
>>>>>
>>>>> I have set the session-timeout to 1440 (24 hours) in web.xml, but
>>>>> logins seem to expire before then (cookie life is set to 5 days): if I
>>>>> login now, do nothing after that, and refresh the page in, say, 13 hours, I
>>>>> am shown as logged out (depending entirely on Shiro for logins, not doing
>>>>> any other hanky-panky).
>>>>>
>>>>> It does seem like the value of the _expires field in the _ah_SESSION
>>>>> entities is being set to 24 hours from now.
>>>>>
>>>>> Regards,
>>>>> Harshdeep S Jawanda
>>>>>
>>>>
>>>>
>>>
>>
>

Re: Session management on GAE

Posted by Brian Demers <br...@gmail.com>.

You _should_ be able to do this with standard servlet configuration (a
web.xml, or a equivalent code). Shiro will just use the available session
from your container.

On Wed, Mar 29, 2017 at 12:56 AM, Harshdeep S Jawanda <hs...@gmail.com>
wrote:

> I have verified the following:
>
>    - ServletContainerSessionManager integrates with the underlying way in
>    which GAE manages HTTP sessions, so should be the choice for people using
>    Shiro on GAE.
>    - Prepending _ahs to the value of JSESSIONID cookie gives the ID of
>    the _ah_SESSION entity in the GAE datastore (should this data be of use to
>    anybody else in the future).
>    - Setting session-timeout in web.xml works on GAE also (I'd had some
>    doubts regarding this).
>    - The JSESSIONID cookie resulting from the Shiro login process has no
>    expires value, therefore is valid for the current session only.
>
> Here is what I want to achieve:
>
>    1. I want to set an expires value on the JSESSIONID cookie so that it
>    isn't lost when the user closes the browser.
>       1. I can achieve this by setting the maxAge of the cookie
>       explicitly in my login handler (after successful login). However this still
>       leaves behind one issue...
>       2. Just like the _expires value of the _ah_SESSION entity gets
>    updated every time a logged-in user uses the site (so that session remains
>    valid for X time from last activity), I want the expires value of the
>    JSESSIONID cookie to also get updated.
>
> How do I achieve this 2nd part? Shiro doesn't seem to handle this
> automatically: is there some setting I have missed? Remember, I have to use
> ServletContainerSessionManager and it doesn't have the
> sessionIdCookie.maxAge property (plus I don't think the expires value gets
> auto-updated every time anyway).
>
> Is my only viable option to create my own Filter?
>
> Or does an auto-refreshing cookie leave a security hole and is therefore
> inadvisable?
>
> Regards,
> Harshdeep S Jawanda
>
> On 29 March 2017 at 06:42, Harshdeep S Jawanda <hs...@gmail.com>
> wrote:
>
>> But where does DefaultWebSessionManager keep the session? In RAM? Then
>> how and when  does it decide to end a session?
>>
>> Because of App Engine's peculiar nature (instances may be stopped and
>> started at any time based on load, and consecutive calls from the same user
>> may end up going to different instances), sessions have to be stored in
>> their built-in Datastore.
>>
>> I had always thought that Shiro on GAE interacts with these sessions and
>> uses them to correspond its own idea/implementation of sessions. You're
>> saying that's not the case?
>>
>>
>> Regards,
>> Harshdeep S Jawanda
>>
>> On 29 March 2017 at 02:36, Brian Demers <br...@gmail.com> wrote:
>>
>>> I cannot speak to anything specific to GAE, but the
>>> DefaultWebSessionManager "owns" the creation of the sessionId.  If you want
>>> the container to control it, then you would use the
>>> ServletContainerSessionManager:
>>>
>>> https://github.com/apache/shiro/blob/master/web/src/main/jav
>>> a/org/apache/shiro/web/session/mgt/ServletContainerSessionManager.java
>>>
>>> On Mon, Mar 27, 2017 at 7:53 AM, Harshdeep S Jawanda <
>>> hsjawanda@gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I am trying to get a better understanding of how Shiro does session
>>>> management on Google App Engine (a few things seem to be behaving
>>>> counter-intuitively), so I'll start by asking some questions:
>>>>
>>>>    1. Does Shiro use the _ah_SESSION entities to manage session
>>>>    persistence on GAE?
>>>>    2. If so, what is the relationship between the key (name/ID) of the
>>>>    _ah_SESSION entity and the value stored in the JSESSIONID cookie?
>>>>    3. To put it differently, how does DefaultWebSessionManager know
>>>>    that if the JSESSIONID value is X, I have to lookup entity Y in the GAE
>>>>    datastore?
>>>>
>>>> I have set the session-timeout to 1440 (24 hours) in web.xml, but
>>>> logins seem to expire before then (cookie life is set to 5 days): if I
>>>> login now, do nothing after that, and refresh the page in, say, 13 hours, I
>>>> am shown as logged out (depending entirely on Shiro for logins, not doing
>>>> any other hanky-panky).
>>>>
>>>> It does seem like the value of the _expires field in the _ah_SESSION
>>>> entities is being set to 24 hours from now.
>>>>
>>>> Regards,
>>>> Harshdeep S Jawanda
>>>>
>>>
>>>
>>
>

Re: Session management on GAE

Posted by Harshdeep S Jawanda <hs...@gmail.com>.

I have verified the following:

   - ServletContainerSessionManager integrates with the underlying way in
   which GAE manages HTTP sessions, so should be the choice for people using
   Shiro on GAE.
   - Prepending _ahs to the value of JSESSIONID cookie gives the ID of the
   _ah_SESSION entity in the GAE datastore (should this data be of use to
   anybody else in the future).
   - Setting session-timeout in web.xml works on GAE also (I'd had some
   doubts regarding this).
   - The JSESSIONID cookie resulting from the Shiro login process has no
   expires value, therefore is valid for the current session only.

Here is what I want to achieve:

   1. I want to set an expires value on the JSESSIONID cookie so that it
   isn't lost when the user closes the browser.
      1. I can achieve this by setting the maxAge of the cookie explicitly
      in my login handler (after successful login). However this still leaves
      behind one issue...
      2. Just like the _expires value of the _ah_SESSION entity gets
   updated every time a logged-in user uses the site (so that session remains
   valid for X time from last activity), I want the expires value of the
   JSESSIONID cookie to also get updated.

How do I achieve this 2nd part? Shiro doesn't seem to handle this
automatically: is there some setting I have missed? Remember, I have to use
ServletContainerSessionManager and it doesn't have the
sessionIdCookie.maxAge property (plus I don't think the expires value gets
auto-updated every time anyway).

Is my only viable option to create my own Filter?

Or does an auto-refreshing cookie leave a security hole and is therefore
inadvisable?

Regards,
Harshdeep S Jawanda

On 29 March 2017 at 06:42, Harshdeep S Jawanda <hs...@gmail.com> wrote:

> But where does DefaultWebSessionManager keep the session? In RAM? Then how
> and when  does it decide to end a session?
>
> Because of App Engine's peculiar nature (instances may be stopped and
> started at any time based on load, and consecutive calls from the same user
> may end up going to different instances), sessions have to be stored in
> their built-in Datastore.
>
> I had always thought that Shiro on GAE interacts with these sessions and
> uses them to correspond its own idea/implementation of sessions. You're
> saying that's not the case?
>
>
> Regards,
> Harshdeep S Jawanda
>
> On 29 March 2017 at 02:36, Brian Demers <br...@gmail.com> wrote:
>
>> I cannot speak to anything specific to GAE, but the
>> DefaultWebSessionManager "owns" the creation of the sessionId.  If you want
>> the container to control it, then you would use the
>> ServletContainerSessionManager:
>>
>> https://github.com/apache/shiro/blob/master/web/src/main/
>> java/org/apache/shiro/web/session/mgt/ServletContainerSessionManager.java
>>
>> On Mon, Mar 27, 2017 at 7:53 AM, Harshdeep S Jawanda <hsjawanda@gmail.com
>> > wrote:
>>
>>> Hi all,
>>>
>>> I am trying to get a better understanding of how Shiro does session
>>> management on Google App Engine (a few things seem to be behaving
>>> counter-intuitively), so I'll start by asking some questions:
>>>
>>>    1. Does Shiro use the _ah_SESSION entities to manage session
>>>    persistence on GAE?
>>>    2. If so, what is the relationship between the key (name/ID) of the
>>>    _ah_SESSION entity and the value stored in the JSESSIONID cookie?
>>>    3. To put it differently, how does DefaultWebSessionManager know
>>>    that if the JSESSIONID value is X, I have to lookup entity Y in the GAE
>>>    datastore?
>>>
>>> I have set the session-timeout to 1440 (24 hours) in web.xml, but logins
>>> seem to expire before then (cookie life is set to 5 days): if I login now,
>>> do nothing after that, and refresh the page in, say, 13 hours, I am shown
>>> as logged out (depending entirely on Shiro for logins, not doing any other
>>> hanky-panky).
>>>
>>> It does seem like the value of the _expires field in the _ah_SESSION
>>> entities is being set to 24 hours from now.
>>>
>>> Regards,
>>> Harshdeep S Jawanda
>>>
>>
>>
>

Re: CDI Injection inside AuthorizingRealm

Posted by Lenny Primak <lp...@hope.nyc.ny.us>.

Since realms aren’t managed by CDI, @Inject will not work.
However, you can achieve the same functionality by using CDI SPI:
CDI.current().XXX()


> On Dec 10, 2017, at 9:35 AM, Rob Young <bo...@gmail.com> wrote:
> 
> Hi Simeo,
> 
> I (finally!) took a look at this, sorry for the delay.  I've never got injection working in an authorizing realm.  In our JSF/Shiro/JPA web application, I had to write an authorizing realm for shiro.  What we ended up doing was using JNDI to retrieve a basic JDBC connection from the container, and do a basic query on user attributes with it.
> 
> I could be mistaken, but I don't think that shiro core knows anything about CDI, and isn't managed by WELD.  (If I am incorrect, I would love to be corrected!)  :)
> 
> We had some fun getting the JNDI connection set up correctly in glassfish - it's all wrapped up in a docker container.
> 
> Here's a gist with some pseudo-java for what I'm talking about.
> https://gist.github.com/bobbotron/c1d2282069a57b2b5b58541b6540de33 <https://gist.github.com/bobbotron/c1d2282069a57b2b5b58541b6540de33>
> 
> 
> On Fri, Dec 1, 2017 at 11:42 AM, Simeó Reig <simeo.reig@grupoincofisa.com <ma...@grupoincofisa.com>> wrote:
> Hi Brian,
> 
>   The real application should collect users from JPA, but I made this version without JPA and I simply inject a CDI that has info hardcoded on it, to do as simple as possible:
> 
> 
> public class JpaRealm extends AuthorizingRealm {
> 
>     @Inject
>     private BeanLogin myBeanLogin;
> 
>     ..
> 
> }
> 
> public class BeanLogin implements Serializable {
> 
>     public User returnUserInfo(String userName) {
> 
>         User user; Role  roleAdmin;
> 
>         roleAdmin = new Role("Role_Admin");
>         roleAdmin.addPermission("all");
> 
>         user = new User(1, userName, "foobar", "Foo company");
>         user.addRol(roleAdmin);
> 
>         return user;
>                 
>     }
> 
> }
> 
> 
> 
> I don't have a mock version of non CDI system but I could do it in a few hours.
> 
> 
> 
> Thanks again
> 
> 
> 
> A 01-12-2017 15:04, Brian Demers escrigué:
> 
>> I just took a quick look, so I very well might have missed something. but where are you dealing with the user's password?
>>  
>> You mentioned you have a non-CDI version that works? can you point us to that too?
>> 
>> On Fri, Dec 1, 2017 at 8:21 AM, Simeó Reig <simeo.reig@grupoincofisa.com <ma...@grupoincofisa.com>> wrote:
>> Hi all,
>> 
>>   has anybody been able to take a look on it? It's a minimal maven JSF2 project to use CDI on authentification under shiro but I wasn't be able to make it work. CDI is working fine but  SimpleAuthenticationInfo it's always raising up IncorrectCredentialsException despite credentials are Ok
>> 
>> https://github.com/simeoreig/shiro-JPA <https://github.com/simeoreig/shiro-JPA>
>> Thanks again
>> 
>> Simeó Reig
>> 
>> 
>> 
>> A 29-11-2017 10:52, Simeó Reig escrigué:
>> 
>> Thanks a lot!
>> 
>> A 29-11-2017 05:01, Rob Young escrigué:
>> 
>> Hi Simeo,
>> 
>>  
>> I'm swamped with work but could take a look in a few days, sounds like you're close!
>> 
>> On Tuesday, November 28, 2017, Simeó Reig <simeo.reig@grupoincofisa.com <ma...@grupoincofisa.com>> wrote:
>> Hi
>> 
>>   If someone can review it, I've just uploaded a minimal maven JSF 2 project on https://github.com/simeoreig/shiro-JPA <https://github.com/simeoreig/shiro-JPA>
>>   CDI Injection is working but now SimpleAuthenticationInfo it's always raising up IncorrectCredentialsException despite credentials are Ok (without JPA is working well)
>> 
>> Just test with user john, pass foobar
>> 
>> 
>> 
>>   Thanks a lot
>> 
>> Simeó Reig
>> 
>> 
>> 
>> A 28-11-2017 22:00, Simeó Reig escrigué:
>> 
>> Thanks Brian I'm going to recheck it
>> 
>> A 28-11-2017 20:31, Brian Demers escrigué:
>> 
>> Are you sure you are injecting all of your components correctly?  Sounds like that might be the issue
>> 
>> On Tue, Nov 28, 2017 at 1:37 PM, Simeó Reig <simeo.reig@grupoincofisa.com <>> wrote:
>> Dear alls,
>> 
>>   Is it possible to use a Inject  a DAO reference inside a class extending AuthorizingRealm ?
>> 
>> I've followed https://stackoverflow.com/questions/15605038/unable-to-inject-my-dao-in-a-custom-apache-shiro-authorizingrealm <https://stackoverflow.com/questions/15605038/unable-to-inject-my-dao-in-a-custom-apache-shiro-authorizingrealm> without success. JPA injection works but SimpleAuthenticationInfo in doGetAuthenticationInfo method always return ' token [org.apache.shiro.authc.UsernamePasswordToken - john,rememberMe=false] did not match the expected credentials"
>> 
>> Shiro 1.3.2 in a JSF application, shiro works without JPA as expected
>> 
>> Thanks
>> 
>> Simeó Reig
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Rob Young
>> robertjohnyoung@gmail.com <ma...@gmail.com>
>>  
>> 
>> 
>> 
>> 
> 
> 
> 
> 
> -- 
> Rob Young
> robertjohnyoung@gmail.com <ma...@gmail.com>
>