1 /* 2 * Licensed to the Apache Software Foundation (ASF) under one 3 * or more contributor license agreements. See the NOTICE file 4 * distributed with this work for additional information 5 * regarding copyright ownership. The ASF licenses this file 6 * to you under the Apache License, Version 2.0 (the 7 * "License"); you may not use this file except in compliance 8 * with the License. You may obtain a copy of the License at 9 * 10 * http://www.apache.org/licenses/LICENSE-2.0 11 * 12 * Unless required by applicable law or agreed to in writing, 13 * software distributed under the License is distributed on an 14 * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY 15 * KIND, either express or implied. See the License for the 16 * specific language governing permissions and limitations 17 * under the License. 18 */ 19 module hunt.shiro.session.mgt.ValidatingSessionManager; 20 21 import hunt.shiro.session.mgt.SessionManager; 22 23 /** 24 * A ValidatingSessionManager is a SessionManager that can proactively validate any or all sessions 25 * that may be expired. 26 * 27 */ 28 interface ValidatingSessionManager : SessionManager { 29 30 /** 31 * Performs session validation for all open/active sessions in the system (those that 32 * have not been stopped or expired), and validates each one. If a session is 33 * found to be invalid (e.g. it has expired), it is updated and saved to the EIS. 34 * <p/> 35 * This method is necessary in order to handle orphaned sessions and is expected to be run at 36 * a regular interval, such as once an hour, once a day or once a week, etc. 37 * The "best" frequency to run this method is entirely dependent upon the application 38 * and would be based on factors such as performance, average number of active users, hours of 39 * least activity, and other things. 40 * <p/> 41 * Most enterprise applications use a request/response programming model. 42 * This is obvious in the case of web applications due to the HTTP protocol, but it is 43 * equally true of remote client applications making remote method invocations. The server 44 * essentially sits idle and only "works" when responding to client requests and/or 45 * method invocations. This type of model is particularly efficient since it means the 46 * security system only has to validate a session during those cases. Such 47 * "lazy" behavior enables the system to lie stateless and/or idle and only incur 48 * overhead for session validation when necessary. 49 * <p/> 50 * However, if a client forgets to log-out, or in the event of a server failure, it is 51 * possible for sessions to be orphaned since no further requests would utilize that session. 52 * Because of these lower-probability cases, it might be required to regularly clean-up the sessions 53 * maintained by the system, especially if sessions are backed by a persistent data store. 54 * <p/> 55 * Even in applications that aren't primarily based on a request/response model, 56 * such as those that use enterprise asynchronous messaging (where data is pushed to 57 * a client without first receiving a client request), it is almost always acceptable to 58 * utilize this lazy approach and run this method at defined interval. 59 * <p/> 60 * Systems that want to proactively validate individual sessions may simply call the 61 * {@link #getSession(SessionKey) getSession(SessionKey)} method on any 62 * {@code ValidatingSessionManager} instance as that method is expected to 63 * validate the session before retrieving it. Note that even with proactive calls to {@code getSession}, 64 * this {@code validateSessions()} method should be invoked regularly anyway to <em>guarantee</em> no 65 * orphans exist. 66 * <p/> 67 * <b>Note:</b> Shiro supports automatic execution of this method at a regular interval 68 * by using {@link SessionValidationScheduler}s. The Shiro default SecurityManager implementations 69 * needing session validation will create and use one by default if one is not provided by the 70 * application configuration. 71 */ 72 void validateSessions(); 73 }