@see hunt.shiro.session.Session#getAttribute(Object key)
@see hunt.shiro.session.Session#getAttributeKeys
@see hunt.shiro.session.Session#getId()
@see hunt.shiro.session.Session#getLastAccessTime()
@see hunt.shiro.session.Session#getStartTimestamp()
@see Session#removeAttribute(Object key)
@see Session#setAttribute(Object key, Object value)
@see hunt.shiro.session.Session#stop()
@see hunt.shiro.session.Session#touch()
Returns the unique identifier assigned by the system upon session creation. <p/> All return values from this method are expected to have proper {@code toString()}, {@code equals()}, and {@code hashCode()} implementations. Good candidates for such an identifier are {@link java.util.UUID UUID}s, {@link java.lang.Integer Integer}s, and {@link java.lang.string string}s.
Returns the time the session was started; that is, the time the system created the instance.
Returns the last time the application received a request or method invocation from the user associated with this session. Application calls to this method do not affect this access time.
Returns the time in milliseconds that the session session may remain idle before expiring. <ul> <li>A negative return value means the session will never expire.</li> <li>A non-negative return value (0 or greater) means the session expiration will occur if idle for that length of time.</li> </ul> <b>*Note:</b> if you are used to the {@code HttpSession}'s {@code getMaxInactiveInterval()} method, the scale on this method is different: Shiro Sessions use millisecond values for timeout whereas {@code HttpSession.getMaxInactiveInterval} uses seconds. Always use millisecond values with Shiro sessions.
Sets the time in milliseconds that the session may remain idle before expiring. <ul> <li>A negative value means the session will never expire.</li> <li>A non-negative value (0 or greater) means the session expiration will occur if idle for that length of time.</li> </ul> <p/> <b>*Note:</b> if you are used to the {@code HttpSession}'s {@code getMaxInactiveInterval()} method, the scale on this method is different: Shiro Sessions use millisecond values for timeout whereas {@code HttpSession.getMaxInactiveInterval} uses seconds. Always use millisecond values with Shiro sessions.
Returns the host name or IP string of the host that originated this session, or {@code null} if the host is unknown.
Explicitly updates the {@link #getLastAccessTime() lastAccessTime} of this session to the current time when this method is invoked. This method can be used to ensure a session does not time out. <p/> Most programmers won't use this method directly and will instead rely on the last access time to be updated automatically as a result of an incoming web request or remote procedure call/method invocation. <p/> However, this method is particularly useful when supporting rich-client applications such as Java Web Start app, Java or Flash applets, etc. Although rare, it is possible in a rich-client environment that a user continuously interacts with the client-side application without a server-side method call ever being invoked. If this happens over a long enough period of time, the user's server-side session could time-out. Again, such cases are rare since most rich-clients frequently require server-side method invocations. <p/> In this example though, the user's session might still be considered valid because the user is actively "using" the application, just not communicating with the server. But because no server-side method calls are invoked, there is no way for the server to know if the user is sitting idle or not, so it must assume so to maintain session integrity. This {@code touch()} method could be invoked by the rich-client application code during those times to ensure that the next time a server-side method is invoked, the invocation will not throw an {@link ExpiredSessionException ExpiredSessionException}. In short terms, it could be used periodically to ensure a session does not time out. <p/> How often this rich-client "maintenance" might occur is entirely dependent upon the application and would be based on variables such as session timeout configuration, usage characteristics of the client application, network utilization and application server performance.
Explicitly stops (invalidates) this session and releases all associated resources. <p/> If this session has already been authenticated (i.e. the {@code Subject} that owns this session has logged-in), calling this method explicitly might have undesired side effects: <p/> It is common for a {@code Subject} implementation to retain authentication state in the {@code Session}. If the session is explicitly stopped by application code by calling this method directly, it could clear out any authentication state that might exist, thereby effectively "unauthenticating" the {@code Subject}. <p/> As such, you might consider {@link hunt.shiro.subject.Subject#logout logging-out} the 'owning' {@code Subject} instead of manually calling this method, as a log out is expected to stop the corresponding session automatically, and also allows framework code to execute additional cleanup logic.
Returns the keys of all the attributes stored under this session. If there are no attributes, this returns an empty collection.
Returns the object bound to this session identified by the specified key. If there is no object bound under the key, {@code null} is returned.
Binds the specified {@code value} to this session, uniquely identified by the specified {@code key} name. If there is already an object bound under the {@code key} name, that existing object will be replaced by the new {@code value}. <p/> If the {@code value} parameter is null, it has the same effect as if {@link #removeAttribute(Object) removeAttribute} was called.
Removes (unbinds) the object bound to this session under the specified {@code key} name.
A DelegatingSession is a client-tier representation of a server side {@link hunt.shiro.session.Session Session}. This implementation is basically a proxy to a server-side {@link NativeSessionManager NativeSessionManager}, which will return the proper results for each method call. <p/> <p>A <tt>DelegatingSession</tt> will cache data when appropriate to avoid a remote method invocation, only communicating with the server when necessary. <p/> <p>Of course, if used in-process with a NativeSessionManager business POJO, as might be the case in a web-based application where the web classes and server-side business pojos exist in the same JVM, a remote method call will not be incurred.