[
https://issues.apache.org/jira/browse/SHIRO-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Les Hazlewood updated SHIRO-170:
--------------------------------
Affects Version/s: 1.2.0
1.1.0
Fix Version/s: (was: 1.2.0)
1.3.0
Moving to 1.3 as this hasn't been implemented yet, and even if we implemented
it this week, there wouldn't be enough testing to make the 1.2 release
hopefully later this week.
In the meantime, here is a temporary workaround to achieve the same effect
until this issue is implemented:
{code}
Session session = subject.getSession();
//retain Session attributes to put in the new session after login:
Map attributes = new LinkedHashMap();
Collection<Object> keys = session.getAttributeKeys();
for( Object key : keys) {
Object value = session.getAttribute(key);
if (value != null) {
attributes.put(key, value);
}
}
session.stop();
//this will create a new session by default in applications that allow session
state:
subject.login(authenticationToken);
//restore the attributes:
session = subject.getSession();
for( Object key : attributes.keySet() ) {
session.setAttribute(key, attributes.get(key));
}
{code}
This will stop the existing session, and login will create a new session by
default. When you restore the attributes, the new session will effectively
have the same relevant state as the pre-login session.
Of course this isn't as nice or as efficient as simply using the existing
session and assigning it a new ID, but it should work for those that need this
functionality right now until a more integrated solution is implemented.
> Force New Session ID on Authentication
> --------------------------------------
>
> Key: SHIRO-170
> URL: https://issues.apache.org/jira/browse/SHIRO-170
> Project: Shiro
> Issue Type: New Feature
> Components: Authentication (log-in), Configuration
> Affects Versions: 1.0.0, 1.1.0, 1.2.0
> Reporter: Jakob Külzer
> Priority: Minor
> Fix For: 1.3.0
>
>
> I am working on an application that has very high security standards. One of
> the issues raised after a full audit of the app is that it might be
> vulnerable for session fixation attacks. Shiro does not reset the Session ID
> after successful authentication, which would prevent this type of attack.
> IMHO this would add another level of security to Shiro beneficial for all
> kinds of applications.
> OWASP has a good page on session fixation attacks:
> http://www.owasp.org/index.php/Session_fixation
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
