Browser access is stateless, and judging whether to log in requires a custom implementation of the server, which can be stored in the session or stored in the cache.
Each browser session has a unique sessionid to distinguish different sessions.
- cas (single sign-on)
phenomenon: multiple systems only need to log in once, no need to log in repeatedly
Principle: authorization server, authorized client
1, authorization server (one) saves a global session, and client (multiple) each Save your own session
2. When the client logs in, judge whether your session is already logged in. If not, then (tell the browser) to redirect to the authorization server (parameters bring your own address for callback)
3. The authorization server judges Whether the global session has been logged in, if not, it will be directed to the login page, prompting the user to log in. After the login is successful, the authorization server redirects to the client (the parameter takes the ticket [a credential number])
4. After the client receives the ticket , request the server to obtain user information
5. After the server agrees to the authorization of the client, the server saves the user information to the global session, and the client saves the user to the local session - oauth2 (login authorization)
phenomenon: the third-party system accesses the resources of the main system, the user does not need to inform the third party of the account in the main system, only the authorization of the main system, the third party can use the resources of the main system (for example: APP1 needs to use WeChat payment, WeChat payment will prompt the user whether to authorize, after the user authorization, APP1 can use the WeChat payment function)
Principle: main system, authorization system (for authorization of the main system, it can also be the same system as the main system), Third-party system
1. The third-party system needs to use the resources of the main system, and the third-party is redirected to the authorization system
. 2. According to different authorization methods, the authorization system prompts the user to authorize
. 3. After the user is authorized, the authorization system returns an authorization certificate (accessToken) To the third-party system [accessToken has a validity period]
4. The third party uses the accessToken to access the main system resources [after the accessToken expires, the third party needs to re-request the authorization system to obtain a new accessToken] - Single sign-
on phenomenon: In the same system, the same user can only have one session at the same time (that is, a user has only one browser in use)
Principle:
1. Put the user who has successfully logged in into the session and cache. :userID,value:sessionId
2. When a user accesses a resource, use an interceptor (or filter) to intercept the user's request, first determine whether the user is logged in (judging by the session), and if the user is not logged in, it will be directed to the login page to prompt the user to log in
3. If the user session has been logged in, retrieve the cached data according to the user's userID, and determine whether the current browser's sessionId is consistent with the cached one. If they are consistent, continue to access
. 4. If the sessionId is inconsistent, the current session data will be cleared and the user will log out. , prompting the user to be kicked - This is just a personal summary, please point out any mistakes