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 <[email protected] > 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 <[email protected]> > 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 > > <[email protected]> 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! > > >
