[
https://issues.apache.org/jira/browse/SHIRO-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190081#comment-13190081
]
Les Hazlewood commented on SHIRO-340:
-------------------------------------
I do like the cookie approach better than the session, for sure. But I'd like
to do the following if possible:
Try the session first IFF it already exists and is available (getSession(false)
!= null) and then fall back to the cookie if it isn't available. My concern
here is backwards compatibility:
- Other things that might look for that attribute explicitly (e.g. I don't know
if the Shiro Grails plugin, Vaadin or Wicket integration might do this or not,
and I wouldn't want to break them if they did). Granted perhaps they shouldn't
be looking for that attribute, but - just in case.
- Another issue is for serialized sessions during a shiro upgrade (session is
serialized/saved -> shut down app -> upgrade to Shiro 1.2 -> start-up-app ->
saved request not available because the session isn't checked first). This
would have an impact on any production environment that serializes Shiro
sessions (I know of a few today that would be impacted by this).
This wouldn't have any effect in apps that disallow sessions, so I don't see
the harm in this approach - unless I'm missing something.
> Shiro should avoid creating sessions if one doesn't exist
> ---------------------------------------------------------
>
> Key: SHIRO-340
> URL: https://issues.apache.org/jira/browse/SHIRO-340
> Project: Shiro
> Issue Type: Improvement
> Components: Web
> Affects Versions: 1.1.0, 1.2.0
> Reporter: Kalle Korhonen
>
> WebUtils.saveRequest() forces creating a session even if doesn't exist
> before. This hinders scalability. For savedRequests, it's not clear session
> is needed at all, a cookie might be better option for storing information in
> this case. Similarly, we should go through the rest of the codebase and see
> if sessions are created unnecessarily.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
