This implementation functions as follows:
<ul>
<li>If the specified Subject already has an existing {@code Session} (typically because an application developer
has called {@code subject.getSession()} already), Shiro will use that existing session to store subject state.</li>
<li>If a Subject does not yet have a Session, this implementation checks the
{@link #isSessionStorageEnabled() sessionStorageEnabled} property:
<ul>
<li>If {@code sessionStorageEnabled} is true (the default setting), a new session may be created to persist
Subject state if necessary.</li>
<li>If {@code sessionStorageEnabled} is {@code false}, a new session will <em>not</em> be created to persist
session state.</li>
</ul></li>
</ul>
Most applications use Sessions and are OK with the default {@code true} setting for {@code sessionStorageEnabled}.
<p/>
However, if your application is a purely 100% stateless application that never uses sessions,
you will want to set {@code sessionStorageEnabled} to {@code false}. Realize that a {@code false} value will
ensure that any subject login only retains the authenticated identity for the duration of a request. Any other
requests, invocations or messages will not be authenticated.
@param subject the {@code Subject} for which session state persistence may be enabled
@return the value of {@link #isSessionStorageEnabled()} and ignores the {@code Subject} argument.
This implementation functions as follows: <ul> <li>If the specified Subject already has an existing {@code Session} (typically because an application developer has called {@code subject.getSession()} already), Shiro will use that existing session to store subject state.</li> <li>If a Subject does not yet have a Session, this implementation checks the {@link #isSessionStorageEnabled() sessionStorageEnabled} property: <ul> <li>If {@code sessionStorageEnabled} is true (the default setting), a new session may be created to persist Subject state if necessary.</li> <li>If {@code sessionStorageEnabled} is {@code false}, a new session will <em>not</em> be created to persist session state.</li> </ul></li> </ul> Most applications use Sessions and are OK with the default {@code true} setting for {@code sessionStorageEnabled}. <p/> However, if your application is a purely 100% stateless application that never uses sessions, you will want to set {@code sessionStorageEnabled} to {@code false}. Realize that a {@code false} value will ensure that any subject login only retains the authenticated identity for the duration of a request. Any other requests, invocations or messages will not be authenticated.
@param subject the {@code Subject} for which session state persistence may be enabled @return the value of {@link #isSessionStorageEnabled()} and ignores the {@code Subject} argument.