001    /*
002     * Licensed to the Apache Software Foundation (ASF) under one
003     * or more contributor license agreements.  See the NOTICE file
004     * distributed with this work for additional information
005     * regarding copyright ownership.  The ASF licenses this file
006     * to you under the Apache License, Version 2.0 (the
007     * "License"); you may not use this file except in compliance
008     * with the License.  You may obtain a copy of the License at
009     *
010     *     http://www.apache.org/licenses/LICENSE-2.0
011     *
012     * Unless required by applicable law or agreed to in writing,
013     * software distributed under the License is distributed on an
014     * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
015     * KIND, either express or implied.  See the License for the
016     * specific language governing permissions and limitations
017     * under the License.
018     */
019    package org.apache.shiro.session.mgt;
020    
021    /**
022     * A ValidatingSessionManager is a SessionManager that can proactively validate any or all sessions
023     * that may be expired.
024     *
025     * @author Les Hazlewood
026     * @since 0.1
027     */
028    public interface ValidatingSessionManager extends SessionManager {
029    
030        /**
031         * Performs session validation for all open/active sessions in the system (those that
032         * have not been stopped or expired), and validates each one.  If a session is
033         * found to be invalid (e.g. it has expired), it is updated and saved to the EIS.
034         * <p/>
035         * This method is necessary in order to handle orphaned sessions and is expected to be run at
036         * a regular interval, such as once an hour, once a day or once a week, etc.
037         * The &quot;best&quot; frequency to run this method is entirely dependent upon the application
038         * and would be based on factors such as performance, average number of active users, hours of
039         * least activity, and other things.
040         * <p/>
041         * Most enterprise applications use a request/response programming model.
042         * This is obvious in the case of web applications due to the HTTP protocol, but it is
043         * equally true of remote client applications making remote method invocations.  The server
044         * essentially sits idle and only &quot;works&quot; when responding to client requests and/or
045         * method invocations.  This type of model is particularly efficent since it means the
046         * security system only has to validate a session during those cases.  Such
047         * &quot;lazy&quot; behavior enables the system to lie stateless and/or idle and only incur
048         * overhead for session validation when necessary.
049         * <p/>
050         * However, if a client forgets to log-out, or in the event of a server failure, it is
051         * possible for sessions to be orphaned since no further requests would utilize that session.
052         * Because of these lower-probability cases, it might be required to regularly clean-up the sessions
053         * maintained by the system, especially if sessions are backed by a persistent data store.
054         * <p/>
055         * Even in applications that aren't primarily based on a request/response model,
056         * such as those that use enterprise asynchronous messaging (where data is pushed to
057         * a client without first receiving a client request), it is almost always acceptable to
058         * utilize this lazy approach and run this method at defined interval.
059         * <p/>
060         * Systems that want to proactively validate individual sessions may simply call the
061         * {@link #getSession(SessionKey) getSession(SessionKey)} method on any
062         * {@code ValidatingSessionManager} instance as that method is expected to
063         * validate the session before retrieving it.  Note that even with proactive calls to {@code getSession},
064         * this {@code validateSessions()} method should be invoked regularly anyway to <em>guarantee</em> no
065         * orphans exist.
066         * <p/>
067         * <b>Note:</b> Shiro supports automatic execution of this method at a regular interval
068         * by using {@link SessionValidationScheduler}s.  The Shiro default SecurityManager implementations
069         * needing session validation will create and use one by default if one is not provided by the
070         * application configuration.
071         */
072        void validateSessions();
073    }