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 2013/09/13 20:34:41 UTC

Re: How to force a remembered user to be forgotten?

Hi Chris,

Richard's suggestions are your best bet at the moment.  However, I'd love
to hear how you'd wish this to work - it could be a proper feature request
that we can put in Jira.

Thoughts?

--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282


On Thu, Aug 29, 2013 at 12:36 PM, Christopher Holt <ch...@hcs.us.com>wrote:

> Thanks for the followup.  I understand that remembered != authenticated,
> but for most places in my application, I treat them the same.  Except for
> certain actions which require real authentication. (i.e. pw change, etc).
>  That being said, I also need the ability to force a re-authentication
> administratively, and I'm a little surprised it's not a more common
> requirement.
>
> The solution you outline and the one in the thread you link is where I was
> headed.  I just wanted to make sure there wasn't already some functionality
> within shiro that I was overlooking.
>
> Thanks for the help,
> -Chris
>
>
> On Thu, Aug 29, 2013 at 10:23 AM, richard@localmed.com <
> richard@localmed.com> wrote:
>
>> Hi.
>>
>> I think I understand your question better now, but I think you may have
>> some
>> confusion over how RememberMe works.  By default in Shiro, a remembered
>> user
>> is not authenticated, and no auto-login is supported.  So, unless you have
>> written code to override that behavior, you probably do not need to worry
>> about revoking all outstanding remember me cookies.  The user still has to
>> re-authenticate even if they are remembered.  A good discussion of the
>> default behavior is in this question:
>>
>> http://shiro-user.582556.n2.nabble.com/Rememberme-vs-authentication-td3084550.html
>> <
>> http://shiro-user.582556.n2.nabble.com/Rememberme-vs-authentication-td3084550.html
>> >
>>
>> That said, Shiro has no way I know of to revoke all outstanding remember
>> me
>> cookies for a given user, if you still think you need to do that.  If you
>> think about it, this is essentially impossible, since the cookie resides
>> in
>> the user's browser, not the server; so unless the user interacts with the
>> server via the browser, the server cannot unset a cookie.
>>
>> I think you could extend the CookieRememberMeManager class so that it
>> stored
>> a key/value pair of a random UUID/username in a database, and set just the
>> UUID in the cookie; then you could delete that pair from the database when
>> you wanted to invalidate all RememberMe tokens; whenever a new session is
>> created, you could then verify that any existing RememberMe token is
>> validated by the information in the database.  That level of complexity is
>> beyond what most people need.
>>
>> I hope that is clearer.
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://shiro-user.582556.n2.nabble.com/How-to-force-a-remembered-user-to-be-forgotten-tp7579089p7579094.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
>>
>
>
>
> --
> Chris Holt
> Director of Development
> Healthcare Control Systems
> (877)877-8795 ext 115
>

Re: How to force a remembered user to be forgotten?

Posted by Les Hazlewood <lh...@apache.org>.
Hi Janne,

Yep, you're correct - the default behavior is to use Java serialization.
 Shiro can't know which of your principals are needed to re-construct a
Subject at a later date, so it must serialize them all to be safe.  Your
solution is exactly why the Serializer interface was created: to allow
custom plugins for more targeted behavior.

Thanks for sharing!

--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282


On Sat, Sep 14, 2013 at 4:00 AM, Janne Jalkanen <Ja...@ecyrd.com>wrote:

>
> BTW, I found that a simpler way to do this is to install your own
> Serializer<PrincipalCollection> to the RememberMeManager. It has the added
> benefit that you can control the serialisation more deeply, as the default
> rememberme -cookie can be pretty big.  We had to do this with Shiro 1.1, as
> sometimes the SetCookie-header grew too large for our load balancer… Don't
> know what the state of Shiro 1.2 is, but I'd assume that it still blindly
> uses Java serialization to the entire PrincipalCollection.
>
> /Janne
>
> On Sep 13, 2013, at 21:41 , Christopher Holt <ch...@hcs.us.com>
> wrote:
>
> Les,
>
> I ended up doing basically what was suggested, but I just used a serial
> number instead of a UUID associated with each user.  When their account is
> locked or password changed, then the serial number is bumped.  I
> extended CookieRememberMeManager and had it add and check the serial number
> in the remember-me cookie.  If it didn't match on deserialize, I just
> returned a null PrincipalCollection.
>
> -Chris
>
>
> On Fri, Sep 13, 2013 at 1:34 PM, Les Hazlewood <lh...@apache.org>wrote:
>
>> Hi Chris,
>>
>> Richard's suggestions are your best bet at the moment.  However, I'd love
>> to hear how you'd wish this to work - it could be a proper feature request
>> that we can put in Jira.
>>
>> Thoughts?
>>
>> --
>> Les Hazlewood | @lhazlewood
>> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
>>
>>
>> On Thu, Aug 29, 2013 at 12:36 PM, Christopher Holt <chris.holt@hcs.us.com
>> > wrote:
>>
>>> Thanks for the followup.  I understand that remembered != authenticated,
>>> but for most places in my application, I treat them the same.  Except for
>>> certain actions which require real authentication. (i.e. pw change, etc).
>>>  That being said, I also need the ability to force a re-authentication
>>> administratively, and I'm a little surprised it's not a more common
>>> requirement.
>>>
>>> The solution you outline and the one in the thread you link is where I
>>> was headed.  I just wanted to make sure there wasn't already some
>>> functionality within shiro that I was overlooking.
>>>
>>> Thanks for the help,
>>> -Chris
>>>
>>>
>>> On Thu, Aug 29, 2013 at 10:23 AM, richard@localmed.com <
>>> richard@localmed.com> wrote:
>>>
>>>> Hi.
>>>>
>>>> I think I understand your question better now, but I think you may have
>>>> some
>>>> confusion over how RememberMe works.  By default in Shiro, a remembered
>>>> user
>>>> is not authenticated, and no auto-login is supported.  So, unless you
>>>> have
>>>> written code to override that behavior, you probably do not need to
>>>> worry
>>>> about revoking all outstanding remember me cookies.  The user still has
>>>> to
>>>> re-authenticate even if they are remembered.  A good discussion of the
>>>> default behavior is in this question:
>>>>
>>>> http://shiro-user.582556.n2.nabble.com/Rememberme-vs-authentication-td3084550.html
>>>> <
>>>> http://shiro-user.582556.n2.nabble.com/Rememberme-vs-authentication-td3084550.html
>>>> >
>>>>
>>>> That said, Shiro has no way I know of to revoke all outstanding
>>>> remember me
>>>> cookies for a given user, if you still think you need to do that.  If
>>>> you
>>>> think about it, this is essentially impossible, since the cookie
>>>> resides in
>>>> the user's browser, not the server; so unless the user interacts with
>>>> the
>>>> server via the browser, the server cannot unset a cookie.
>>>>
>>>> I think you could extend the CookieRememberMeManager class so that it
>>>> stored
>>>> a key/value pair of a random UUID/username in a database, and set just
>>>> the
>>>> UUID in the cookie; then you could delete that pair from the database
>>>> when
>>>> you wanted to invalidate all RememberMe tokens; whenever a new session
>>>> is
>>>> created, you could then verify that any existing RememberMe token is
>>>> validated by the information in the database.  That level of complexity
>>>> is
>>>> beyond what most people need.
>>>>
>>>> I hope that is clearer.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://shiro-user.582556.n2.nabble.com/How-to-force-a-remembered-user-to-be-forgotten-tp7579089p7579094.html
>>>> Sent from the Shiro User mailing list archive at Nabble.com.
>>>>
>>>
>>>
>>>
>>> --
>>> Chris Holt
>>> Director of Development
>>> Healthcare Control Systems
>>> (877)877-8795 ext 115
>>>
>>
>>
>
>
> --
> Chris Holt
> Director of Development
> Healthcare Control Systems
> (877)877-8795 ext 115
>
>
>

Re: How to force a remembered user to be forgotten?

Posted by Janne Jalkanen <Ja...@ecyrd.com>.
BTW, I found that a simpler way to do this is to install your own Serializer<PrincipalCollection> to the RememberMeManager. It has the added benefit that you can control the serialisation more deeply, as the default rememberme -cookie can be pretty big.  We had to do this with Shiro 1.1, as sometimes the SetCookie-header grew too large for our load balancer… Don't know what the state of Shiro 1.2 is, but I'd assume that it still blindly uses Java serialization to the entire PrincipalCollection.

/Janne

On Sep 13, 2013, at 21:41 , Christopher Holt <ch...@hcs.us.com> wrote:

> Les,
> 
> I ended up doing basically what was suggested, but I just used a serial number instead of a UUID associated with each user.  When their account is locked or password changed, then the serial number is bumped.  I extended CookieRememberMeManager and had it add and check the serial number in the remember-me cookie.  If it didn't match on deserialize, I just returned a null PrincipalCollection.
> 
> -Chris
> 
> 
> On Fri, Sep 13, 2013 at 1:34 PM, Les Hazlewood <lh...@apache.org> wrote:
> Hi Chris,
> 
> Richard's suggestions are your best bet at the moment.  However, I'd love to hear how you'd wish this to work - it could be a proper feature request that we can put in Jira.
> 
> Thoughts?
> 
> --
> Les Hazlewood | @lhazlewood
> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
> 
> 
> On Thu, Aug 29, 2013 at 12:36 PM, Christopher Holt <ch...@hcs.us.com> wrote:
> Thanks for the followup.  I understand that remembered != authenticated, but for most places in my application, I treat them the same.  Except for certain actions which require real authentication. (i.e. pw change, etc).  That being said, I also need the ability to force a re-authentication administratively, and I'm a little surprised it's not a more common requirement.
> 
> The solution you outline and the one in the thread you link is where I was headed.  I just wanted to make sure there wasn't already some functionality within shiro that I was overlooking.
> 
> Thanks for the help,
> -Chris
> 
> 
> On Thu, Aug 29, 2013 at 10:23 AM, richard@localmed.com <ri...@localmed.com> wrote:
> Hi.
> 
> I think I understand your question better now, but I think you may have some
> confusion over how RememberMe works.  By default in Shiro, a remembered user
> is not authenticated, and no auto-login is supported.  So, unless you have
> written code to override that behavior, you probably do not need to worry
> about revoking all outstanding remember me cookies.  The user still has to
> re-authenticate even if they are remembered.  A good discussion of the
> default behavior is in this question:
> http://shiro-user.582556.n2.nabble.com/Rememberme-vs-authentication-td3084550.html
> <http://shiro-user.582556.n2.nabble.com/Rememberme-vs-authentication-td3084550.html>
> 
> That said, Shiro has no way I know of to revoke all outstanding remember me
> cookies for a given user, if you still think you need to do that.  If you
> think about it, this is essentially impossible, since the cookie resides in
> the user's browser, not the server; so unless the user interacts with the
> server via the browser, the server cannot unset a cookie.
> 
> I think you could extend the CookieRememberMeManager class so that it stored
> a key/value pair of a random UUID/username in a database, and set just the
> UUID in the cookie; then you could delete that pair from the database when
> you wanted to invalidate all RememberMe tokens; whenever a new session is
> created, you could then verify that any existing RememberMe token is
> validated by the information in the database.  That level of complexity is
> beyond what most people need.
> 
> I hope that is clearer.
> 
> 
> 
> 
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/How-to-force-a-remembered-user-to-be-forgotten-tp7579089p7579094.html
> Sent from the Shiro User mailing list archive at Nabble.com.
> 
> 
> 
> -- 
> Chris Holt
> Director of Development
> Healthcare Control Systems
> (877)877-8795 ext 115
> 
> 
> 
> 
> -- 
> Chris Holt
> Director of Development
> Healthcare Control Systems
> (877)877-8795 ext 115


Re: How to force a remembered user to be forgotten?

Posted by Christopher Holt <ch...@hcs.us.com>.
Les,

I ended up doing basically what was suggested, but I just used a serial
number instead of a UUID associated with each user.  When their account is
locked or password changed, then the serial number is bumped.  I
extended CookieRememberMeManager and had it add and check the serial number
in the remember-me cookie.  If it didn't match on deserialize, I just
returned a null PrincipalCollection.

-Chris


On Fri, Sep 13, 2013 at 1:34 PM, Les Hazlewood <lh...@apache.org>wrote:

> Hi Chris,
>
> Richard's suggestions are your best bet at the moment.  However, I'd love
> to hear how you'd wish this to work - it could be a proper feature request
> that we can put in Jira.
>
> Thoughts?
>
> --
> Les Hazlewood | @lhazlewood
> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
>
>
> On Thu, Aug 29, 2013 at 12:36 PM, Christopher Holt <ch...@hcs.us.com>wrote:
>
>> Thanks for the followup.  I understand that remembered != authenticated,
>> but for most places in my application, I treat them the same.  Except for
>> certain actions which require real authentication. (i.e. pw change, etc).
>>  That being said, I also need the ability to force a re-authentication
>> administratively, and I'm a little surprised it's not a more common
>> requirement.
>>
>> The solution you outline and the one in the thread you link is where I
>> was headed.  I just wanted to make sure there wasn't already some
>> functionality within shiro that I was overlooking.
>>
>> Thanks for the help,
>> -Chris
>>
>>
>> On Thu, Aug 29, 2013 at 10:23 AM, richard@localmed.com <
>> richard@localmed.com> wrote:
>>
>>> Hi.
>>>
>>> I think I understand your question better now, but I think you may have
>>> some
>>> confusion over how RememberMe works.  By default in Shiro, a remembered
>>> user
>>> is not authenticated, and no auto-login is supported.  So, unless you
>>> have
>>> written code to override that behavior, you probably do not need to worry
>>> about revoking all outstanding remember me cookies.  The user still has
>>> to
>>> re-authenticate even if they are remembered.  A good discussion of the
>>> default behavior is in this question:
>>>
>>> http://shiro-user.582556.n2.nabble.com/Rememberme-vs-authentication-td3084550.html
>>> <
>>> http://shiro-user.582556.n2.nabble.com/Rememberme-vs-authentication-td3084550.html
>>> >
>>>
>>> That said, Shiro has no way I know of to revoke all outstanding remember
>>> me
>>> cookies for a given user, if you still think you need to do that.  If you
>>> think about it, this is essentially impossible, since the cookie resides
>>> in
>>> the user's browser, not the server; so unless the user interacts with the
>>> server via the browser, the server cannot unset a cookie.
>>>
>>> I think you could extend the CookieRememberMeManager class so that it
>>> stored
>>> a key/value pair of a random UUID/username in a database, and set just
>>> the
>>> UUID in the cookie; then you could delete that pair from the database
>>> when
>>> you wanted to invalidate all RememberMe tokens; whenever a new session is
>>> created, you could then verify that any existing RememberMe token is
>>> validated by the information in the database.  That level of complexity
>>> is
>>> beyond what most people need.
>>>
>>> I hope that is clearer.
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://shiro-user.582556.n2.nabble.com/How-to-force-a-remembered-user-to-be-forgotten-tp7579089p7579094.html
>>> Sent from the Shiro User mailing list archive at Nabble.com.
>>>
>>
>>
>>
>> --
>> Chris Holt
>> Director of Development
>> Healthcare Control Systems
>> (877)877-8795 ext 115
>>
>
>


-- 
Chris Holt
Director of Development
Healthcare Control Systems
(877)877-8795 ext 115