You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by "Nassos A. Michas" <na...@eurodyn.com> on 2010/11/16 08:01:21 UTC
How to prevent Shiro creating sessions?
Hello,
I am protecting a webapp with Shiro (not using Shiro's native sessions). The webapp is protected from "/" with a simple shiro.ini such as:
[main]
authc.loginUrl = /login/index.action
authc.successUrl = /home/index.action
[urls]
/login/** = anon
/images/** = anon
/scripts/** = anon
/css/** = anon
/** = authc
When a non-authenticated user is trying to access "/" is correctly redirected to the login page however, an http session is automatically created at this point by Shiro.
1/ Would it be possible to avoid this and only have a session being created when my own application logic requests to do so?
2/ Is this maybe a result of Shiro wanting to save the originally requested URL and if yes, would it be possible to instruct Shiro to perform some kind of URL rewriting instead of creating a session?
3/ Can I turn completely off the saveRequest functionality through shiro.ini?
thanks!
Re: How to prevent Shiro creating sessions?
Posted by Les Hazlewood <lh...@apache.org>.
Not that I'm aware of.
Les
P.S. Happy Thanksgiving! :)
On Thu, Nov 25, 2010 at 8:44 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Has a Jira issue been filed on this? I am interested in watching since I am concerned about this as well.
>
>
> Regards,
> Alan
>
> On Nov 16, 2010, at 3:22 PM, Kalle Korhonen wrote:
>
>> On Tue, Nov 16, 2010 at 12:03 PM, Erik Beeson <er...@gmail.com> wrote:
>>> I was looking into trying to implement a stateless session cookie approach
>>> and was getting a little lost with where to hook into Shiro. If someone
>>> could offer some pointers, I'd be happy to hack away at it.
>>> Maybe another option would be to put Stateless Session Filter in front of
>>> Shiro configured to use http sessions?
>>
>> Look into Shiro's native session support - you could use both of these
>> together with your own custom native sessions. However, I don't see
>> this as relevant to the session creation discussion. (JEE) sessions
>> are the best thing going for JEE environments, problems arise only
>> when you abuse the system by carelessly creating them and not keeping
>> them lightweight.
>>
>> Kalle
>>
>>
>>> On Tue, Nov 16, 2010 at 11:13 AM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>>>
>>>> For scalability, it's critical that session creation is delayed as
>>>> long as possible. Also, automatic session creation on permission
>>>> denied creates an easy attack vector for denial of service. Agree with
>>>> Les that a generic url rewriting would be difficult to achieve but an
>>>> alternative, cookie-based approach that people who care about this
>>>> could turn on at will should work just fine. Please open an issue,
>>>> I'll be happy to work on it since I need it myself at some point.
>>>>
>>>> Kalle
>>>>
>>>>
>>>> On Tue, Nov 16, 2010 at 10:35 AM, Les Hazlewood <lh...@apache.org>
>>>> wrote:
>>>>> Yes, this is because Shiro will save a request by putting it in the
>>>>> session and there is no way currently to turn off this feature.
>>>>> Creating URL-rewriting logic to ensure this works cleanly in any
>>>>> request scenario just hasn't been worth the pain. Not to mention such
>>>>> a feature is very implementation specific: if you URL re-write when
>>>>> directing to the login page, you have to ensure all of that data is
>>>>> encoded again when the login page is submitted - how this works is
>>>>> very different across UI technologies (JSF, vs JSP vs Wicket vs, etc).
>>>>>
>>>>> This could be done as a cookie as well I suppose, but it hasn't been
>>>>> worth it when most people don't care about a session being created.
>>>>> If you'd like to see this feature implemented with a cookie instead of
>>>>> the session, please open a Jira issue as a feature request.
>>>>>
>>>>> The other thing to realize is that if a user authenticates
>>>>> successfully, there will be a session created at that time to hold on
>>>>> to the user's principals and authentication state. In other words,
>>>>> you're going to have a session created _anyway_. The only time this
>>>>> wouldn't happen is if the user doesn't login after they're redirected
>>>>> to the login page, at which point the session will expire and that
>>>>> orphan will be cleaned by the session manager. Usually this is a
>>>>> negligible case and not worth the effort to circumvent it.
>>>>>
>>>>> The only way to change this is to subclass the existing authc filter
>>>>> and override the onAccessDenied method implementation. This method
>>>>> has the logic that calls the 'saveRequestAndRedirectToLogin' method.
>>>>> Assuming you've kept the 'authc' filter an instance of
>>>>> FormAuthenticatinoFilter, look at its 'onAccessDenied' method source
>>>>> code for ideas in your own implementation.
>>>>>
>>>>> HTH,
>>>>>
>>>>> Les
>>>>>
>>>>> On Mon, Nov 15, 2010 at 11:01 PM, Nassos A. Michas
>>>>> <na...@eurodyn.com> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I am protecting a webapp with Shiro (not using Shiro's native
>>>>>> sessions). The webapp is protected from "/" with a simple shiro.ini such as:
>>>>>>
>>>>>> [main]
>>>>>> authc.loginUrl = /login/index.action
>>>>>> authc.successUrl = /home/index.action
>>>>>>
>>>>>> [urls]
>>>>>> /login/** = anon
>>>>>> /images/** = anon
>>>>>> /scripts/** = anon
>>>>>> /css/** = anon
>>>>>> /** = authc
>>>>>>
>>>>>> When a non-authenticated user is trying to access "/" is correctly
>>>>>> redirected to the login page however, an http session is automatically
>>>>>> created at this point by Shiro.
>>>>>> 1/ Would it be possible to avoid this and only have a session being
>>>>>> created when my own application logic requests to do so?
>>>>>> 2/ Is this maybe a result of Shiro wanting to save the originally
>>>>>> requested URL and if yes, would it be possible to instruct Shiro to perform
>>>>>> some kind of URL rewriting instead of creating a session?
>>>>>> 3/ Can I turn completely off the saveRequest functionality through
>>>>>> shiro.ini?
>>>>>>
>>>>>>
>>>>>> thanks!
>>>>>
>>>
>>>
Re: How to prevent Shiro creating sessions?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Has a Jira issue been filed on this? I am interested in watching since I am concerned about this as well.
Regards,
Alan
On Nov 16, 2010, at 3:22 PM, Kalle Korhonen wrote:
> On Tue, Nov 16, 2010 at 12:03 PM, Erik Beeson <er...@gmail.com> wrote:
>> I was looking into trying to implement a stateless session cookie approach
>> and was getting a little lost with where to hook into Shiro. If someone
>> could offer some pointers, I'd be happy to hack away at it.
>> Maybe another option would be to put Stateless Session Filter in front of
>> Shiro configured to use http sessions?
>
> Look into Shiro's native session support - you could use both of these
> together with your own custom native sessions. However, I don't see
> this as relevant to the session creation discussion. (JEE) sessions
> are the best thing going for JEE environments, problems arise only
> when you abuse the system by carelessly creating them and not keeping
> them lightweight.
>
> Kalle
>
>
>> On Tue, Nov 16, 2010 at 11:13 AM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>>
>>> For scalability, it's critical that session creation is delayed as
>>> long as possible. Also, automatic session creation on permission
>>> denied creates an easy attack vector for denial of service. Agree with
>>> Les that a generic url rewriting would be difficult to achieve but an
>>> alternative, cookie-based approach that people who care about this
>>> could turn on at will should work just fine. Please open an issue,
>>> I'll be happy to work on it since I need it myself at some point.
>>>
>>> Kalle
>>>
>>>
>>> On Tue, Nov 16, 2010 at 10:35 AM, Les Hazlewood <lh...@apache.org>
>>> wrote:
>>>> Yes, this is because Shiro will save a request by putting it in the
>>>> session and there is no way currently to turn off this feature.
>>>> Creating URL-rewriting logic to ensure this works cleanly in any
>>>> request scenario just hasn't been worth the pain. Not to mention such
>>>> a feature is very implementation specific: if you URL re-write when
>>>> directing to the login page, you have to ensure all of that data is
>>>> encoded again when the login page is submitted - how this works is
>>>> very different across UI technologies (JSF, vs JSP vs Wicket vs, etc).
>>>>
>>>> This could be done as a cookie as well I suppose, but it hasn't been
>>>> worth it when most people don't care about a session being created.
>>>> If you'd like to see this feature implemented with a cookie instead of
>>>> the session, please open a Jira issue as a feature request.
>>>>
>>>> The other thing to realize is that if a user authenticates
>>>> successfully, there will be a session created at that time to hold on
>>>> to the user's principals and authentication state. In other words,
>>>> you're going to have a session created _anyway_. The only time this
>>>> wouldn't happen is if the user doesn't login after they're redirected
>>>> to the login page, at which point the session will expire and that
>>>> orphan will be cleaned by the session manager. Usually this is a
>>>> negligible case and not worth the effort to circumvent it.
>>>>
>>>> The only way to change this is to subclass the existing authc filter
>>>> and override the onAccessDenied method implementation. This method
>>>> has the logic that calls the 'saveRequestAndRedirectToLogin' method.
>>>> Assuming you've kept the 'authc' filter an instance of
>>>> FormAuthenticatinoFilter, look at its 'onAccessDenied' method source
>>>> code for ideas in your own implementation.
>>>>
>>>> HTH,
>>>>
>>>> Les
>>>>
>>>> On Mon, Nov 15, 2010 at 11:01 PM, Nassos A. Michas
>>>> <na...@eurodyn.com> wrote:
>>>>> Hello,
>>>>>
>>>>> I am protecting a webapp with Shiro (not using Shiro's native
>>>>> sessions). The webapp is protected from "/" with a simple shiro.ini such as:
>>>>>
>>>>> [main]
>>>>> authc.loginUrl = /login/index.action
>>>>> authc.successUrl = /home/index.action
>>>>>
>>>>> [urls]
>>>>> /login/** = anon
>>>>> /images/** = anon
>>>>> /scripts/** = anon
>>>>> /css/** = anon
>>>>> /** = authc
>>>>>
>>>>> When a non-authenticated user is trying to access "/" is correctly
>>>>> redirected to the login page however, an http session is automatically
>>>>> created at this point by Shiro.
>>>>> 1/ Would it be possible to avoid this and only have a session being
>>>>> created when my own application logic requests to do so?
>>>>> 2/ Is this maybe a result of Shiro wanting to save the originally
>>>>> requested URL and if yes, would it be possible to instruct Shiro to perform
>>>>> some kind of URL rewriting instead of creating a session?
>>>>> 3/ Can I turn completely off the saveRequest functionality through
>>>>> shiro.ini?
>>>>>
>>>>>
>>>>> thanks!
>>>>
>>
>>
Re: How to prevent Shiro creating sessions?
Posted by Kalle Korhonen <ka...@gmail.com>.
On Tue, Nov 16, 2010 at 12:03 PM, Erik Beeson <er...@gmail.com> wrote:
> I was looking into trying to implement a stateless session cookie approach
> and was getting a little lost with where to hook into Shiro. If someone
> could offer some pointers, I'd be happy to hack away at it.
> Maybe another option would be to put Stateless Session Filter in front of
> Shiro configured to use http sessions?
Look into Shiro's native session support - you could use both of these
together with your own custom native sessions. However, I don't see
this as relevant to the session creation discussion. (JEE) sessions
are the best thing going for JEE environments, problems arise only
when you abuse the system by carelessly creating them and not keeping
them lightweight.
Kalle
> On Tue, Nov 16, 2010 at 11:13 AM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>>
>> For scalability, it's critical that session creation is delayed as
>> long as possible. Also, automatic session creation on permission
>> denied creates an easy attack vector for denial of service. Agree with
>> Les that a generic url rewriting would be difficult to achieve but an
>> alternative, cookie-based approach that people who care about this
>> could turn on at will should work just fine. Please open an issue,
>> I'll be happy to work on it since I need it myself at some point.
>>
>> Kalle
>>
>>
>> On Tue, Nov 16, 2010 at 10:35 AM, Les Hazlewood <lh...@apache.org>
>> wrote:
>> > Yes, this is because Shiro will save a request by putting it in the
>> > session and there is no way currently to turn off this feature.
>> > Creating URL-rewriting logic to ensure this works cleanly in any
>> > request scenario just hasn't been worth the pain. Not to mention such
>> > a feature is very implementation specific: if you URL re-write when
>> > directing to the login page, you have to ensure all of that data is
>> > encoded again when the login page is submitted - how this works is
>> > very different across UI technologies (JSF, vs JSP vs Wicket vs, etc).
>> >
>> > This could be done as a cookie as well I suppose, but it hasn't been
>> > worth it when most people don't care about a session being created.
>> > If you'd like to see this feature implemented with a cookie instead of
>> > the session, please open a Jira issue as a feature request.
>> >
>> > The other thing to realize is that if a user authenticates
>> > successfully, there will be a session created at that time to hold on
>> > to the user's principals and authentication state. In other words,
>> > you're going to have a session created _anyway_. The only time this
>> > wouldn't happen is if the user doesn't login after they're redirected
>> > to the login page, at which point the session will expire and that
>> > orphan will be cleaned by the session manager. Usually this is a
>> > negligible case and not worth the effort to circumvent it.
>> >
>> > The only way to change this is to subclass the existing authc filter
>> > and override the onAccessDenied method implementation. This method
>> > has the logic that calls the 'saveRequestAndRedirectToLogin' method.
>> > Assuming you've kept the 'authc' filter an instance of
>> > FormAuthenticatinoFilter, look at its 'onAccessDenied' method source
>> > code for ideas in your own implementation.
>> >
>> > HTH,
>> >
>> > Les
>> >
>> > On Mon, Nov 15, 2010 at 11:01 PM, Nassos A. Michas
>> > <na...@eurodyn.com> wrote:
>> >> Hello,
>> >>
>> >> I am protecting a webapp with Shiro (not using Shiro's native
>> >> sessions). The webapp is protected from "/" with a simple shiro.ini such as:
>> >>
>> >> [main]
>> >> authc.loginUrl = /login/index.action
>> >> authc.successUrl = /home/index.action
>> >>
>> >> [urls]
>> >> /login/** = anon
>> >> /images/** = anon
>> >> /scripts/** = anon
>> >> /css/** = anon
>> >> /** = authc
>> >>
>> >> When a non-authenticated user is trying to access "/" is correctly
>> >> redirected to the login page however, an http session is automatically
>> >> created at this point by Shiro.
>> >> 1/ Would it be possible to avoid this and only have a session being
>> >> created when my own application logic requests to do so?
>> >> 2/ Is this maybe a result of Shiro wanting to save the originally
>> >> requested URL and if yes, would it be possible to instruct Shiro to perform
>> >> some kind of URL rewriting instead of creating a session?
>> >> 3/ Can I turn completely off the saveRequest functionality through
>> >> shiro.ini?
>> >>
>> >>
>> >> thanks!
>> >
>
>
Re: How to prevent Shiro creating sessions?
Posted by Erik Beeson <er...@gmail.com>.
I was looking into trying to implement a stateless session
cookie<http://www.lightbluetouchpaper.org/2008/05/16/hardened-stateless-session-cookies/>approach
and was getting a little lost with where to hook into Shiro. If
someone could offer some pointers, I'd be happy to hack away at it.
Maybe another option would be to put Stateless Session
Filter<http://statelessfilter.sourceforge.net/>in front of Shiro
configured to use http sessions?
--Erik
On Tue, Nov 16, 2010 at 11:13 AM, Kalle Korhonen <kalle.o.korhonen@gmail.com
> wrote:
> For scalability, it's critical that session creation is delayed as
> long as possible. Also, automatic session creation on permission
> denied creates an easy attack vector for denial of service. Agree with
> Les that a generic url rewriting would be difficult to achieve but an
> alternative, cookie-based approach that people who care about this
> could turn on at will should work just fine. Please open an issue,
> I'll be happy to work on it since I need it myself at some point.
>
> Kalle
>
>
> On Tue, Nov 16, 2010 at 10:35 AM, Les Hazlewood <lh...@apache.org>
> wrote:
> > Yes, this is because Shiro will save a request by putting it in the
> > session and there is no way currently to turn off this feature.
> > Creating URL-rewriting logic to ensure this works cleanly in any
> > request scenario just hasn't been worth the pain. Not to mention such
> > a feature is very implementation specific: if you URL re-write when
> > directing to the login page, you have to ensure all of that data is
> > encoded again when the login page is submitted - how this works is
> > very different across UI technologies (JSF, vs JSP vs Wicket vs, etc).
> >
> > This could be done as a cookie as well I suppose, but it hasn't been
> > worth it when most people don't care about a session being created.
> > If you'd like to see this feature implemented with a cookie instead of
> > the session, please open a Jira issue as a feature request.
> >
> > The other thing to realize is that if a user authenticates
> > successfully, there will be a session created at that time to hold on
> > to the user's principals and authentication state. In other words,
> > you're going to have a session created _anyway_. The only time this
> > wouldn't happen is if the user doesn't login after they're redirected
> > to the login page, at which point the session will expire and that
> > orphan will be cleaned by the session manager. Usually this is a
> > negligible case and not worth the effort to circumvent it.
> >
> > The only way to change this is to subclass the existing authc filter
> > and override the onAccessDenied method implementation. This method
> > has the logic that calls the 'saveRequestAndRedirectToLogin' method.
> > Assuming you've kept the 'authc' filter an instance of
> > FormAuthenticatinoFilter, look at its 'onAccessDenied' method source
> > code for ideas in your own implementation.
> >
> > HTH,
> >
> > Les
> >
> > On Mon, Nov 15, 2010 at 11:01 PM, Nassos A. Michas
> > <na...@eurodyn.com> wrote:
> >> Hello,
> >>
> >> I am protecting a webapp with Shiro (not using Shiro's native sessions).
> The webapp is protected from "/" with a simple shiro.ini such as:
> >>
> >> [main]
> >> authc.loginUrl = /login/index.action
> >> authc.successUrl = /home/index.action
> >>
> >> [urls]
> >> /login/** = anon
> >> /images/** = anon
> >> /scripts/** = anon
> >> /css/** = anon
> >> /** = authc
> >>
> >> When a non-authenticated user is trying to access "/" is correctly
> redirected to the login page however, an http session is automatically
> created at this point by Shiro.
> >> 1/ Would it be possible to avoid this and only have a session being
> created when my own application logic requests to do so?
> >> 2/ Is this maybe a result of Shiro wanting to save the originally
> requested URL and if yes, would it be possible to instruct Shiro to perform
> some kind of URL rewriting instead of creating a session?
> >> 3/ Can I turn completely off the saveRequest functionality through
> shiro.ini?
> >>
> >>
> >> thanks!
> >
>
Re: How to prevent Shiro creating sessions?
Posted by Kalle Korhonen <ka...@gmail.com>.
For scalability, it's critical that session creation is delayed as
long as possible. Also, automatic session creation on permission
denied creates an easy attack vector for denial of service. Agree with
Les that a generic url rewriting would be difficult to achieve but an
alternative, cookie-based approach that people who care about this
could turn on at will should work just fine. Please open an issue,
I'll be happy to work on it since I need it myself at some point.
Kalle
On Tue, Nov 16, 2010 at 10:35 AM, Les Hazlewood <lh...@apache.org> wrote:
> Yes, this is because Shiro will save a request by putting it in the
> session and there is no way currently to turn off this feature.
> Creating URL-rewriting logic to ensure this works cleanly in any
> request scenario just hasn't been worth the pain. Not to mention such
> a feature is very implementation specific: if you URL re-write when
> directing to the login page, you have to ensure all of that data is
> encoded again when the login page is submitted - how this works is
> very different across UI technologies (JSF, vs JSP vs Wicket vs, etc).
>
> This could be done as a cookie as well I suppose, but it hasn't been
> worth it when most people don't care about a session being created.
> If you'd like to see this feature implemented with a cookie instead of
> the session, please open a Jira issue as a feature request.
>
> The other thing to realize is that if a user authenticates
> successfully, there will be a session created at that time to hold on
> to the user's principals and authentication state. In other words,
> you're going to have a session created _anyway_. The only time this
> wouldn't happen is if the user doesn't login after they're redirected
> to the login page, at which point the session will expire and that
> orphan will be cleaned by the session manager. Usually this is a
> negligible case and not worth the effort to circumvent it.
>
> The only way to change this is to subclass the existing authc filter
> and override the onAccessDenied method implementation. This method
> has the logic that calls the 'saveRequestAndRedirectToLogin' method.
> Assuming you've kept the 'authc' filter an instance of
> FormAuthenticatinoFilter, look at its 'onAccessDenied' method source
> code for ideas in your own implementation.
>
> HTH,
>
> Les
>
> On Mon, Nov 15, 2010 at 11:01 PM, Nassos A. Michas
> <na...@eurodyn.com> wrote:
>> Hello,
>>
>> I am protecting a webapp with Shiro (not using Shiro's native sessions). The webapp is protected from "/" with a simple shiro.ini such as:
>>
>> [main]
>> authc.loginUrl = /login/index.action
>> authc.successUrl = /home/index.action
>>
>> [urls]
>> /login/** = anon
>> /images/** = anon
>> /scripts/** = anon
>> /css/** = anon
>> /** = authc
>>
>> When a non-authenticated user is trying to access "/" is correctly redirected to the login page however, an http session is automatically created at this point by Shiro.
>> 1/ Would it be possible to avoid this and only have a session being created when my own application logic requests to do so?
>> 2/ Is this maybe a result of Shiro wanting to save the originally requested URL and if yes, would it be possible to instruct Shiro to perform some kind of URL rewriting instead of creating a session?
>> 3/ Can I turn completely off the saveRequest functionality through shiro.ini?
>>
>>
>> thanks!
>
Re: How to prevent Shiro creating sessions?
Posted by Les Hazlewood <lh...@apache.org>.
Yes, this is because Shiro will save a request by putting it in the
session and there is no way currently to turn off this feature.
Creating URL-rewriting logic to ensure this works cleanly in any
request scenario just hasn't been worth the pain. Not to mention such
a feature is very implementation specific: if you URL re-write when
directing to the login page, you have to ensure all of that data is
encoded again when the login page is submitted - how this works is
very different across UI technologies (JSF, vs JSP vs Wicket vs, etc).
This could be done as a cookie as well I suppose, but it hasn't been
worth it when most people don't care about a session being created.
If you'd like to see this feature implemented with a cookie instead of
the session, please open a Jira issue as a feature request.
The other thing to realize is that if a user authenticates
successfully, there will be a session created at that time to hold on
to the user's principals and authentication state. In other words,
you're going to have a session created _anyway_. The only time this
wouldn't happen is if the user doesn't login after they're redirected
to the login page, at which point the session will expire and that
orphan will be cleaned by the session manager. Usually this is a
negligible case and not worth the effort to circumvent it.
The only way to change this is to subclass the existing authc filter
and override the onAccessDenied method implementation. This method
has the logic that calls the 'saveRequestAndRedirectToLogin' method.
Assuming you've kept the 'authc' filter an instance of
FormAuthenticatinoFilter, look at its 'onAccessDenied' method source
code for ideas in your own implementation.
HTH,
Les
On Mon, Nov 15, 2010 at 11:01 PM, Nassos A. Michas
<na...@eurodyn.com> wrote:
> Hello,
>
> I am protecting a webapp with Shiro (not using Shiro's native sessions). The webapp is protected from "/" with a simple shiro.ini such as:
>
> [main]
> authc.loginUrl = /login/index.action
> authc.successUrl = /home/index.action
>
> [urls]
> /login/** = anon
> /images/** = anon
> /scripts/** = anon
> /css/** = anon
> /** = authc
>
> When a non-authenticated user is trying to access "/" is correctly redirected to the login page however, an http session is automatically created at this point by Shiro.
> 1/ Would it be possible to avoid this and only have a session being created when my own application logic requests to do so?
> 2/ Is this maybe a result of Shiro wanting to save the originally requested URL and if yes, would it be possible to instruct Shiro to perform some kind of URL rewriting instead of creating a session?
> 3/ Can I turn completely off the saveRequest functionality through shiro.ini?
>
>
> thanks!