Shiro implements authentication based on the organization plus user name and RememberMe

first, some experience of Shiro and the principle of rememberme realization

Shiro's Login (Authorization) and authentication (authentication) are verified and authorized by default based on the username username.

Login is usernamepasswordtoken user name password pair, the right to verify is the PrincipalCollection identity collection (default is the user name and realm name), There is a unified portal that is subject (denotes a person or something to log in to).

The relationship is the login subject.login (token), and then landed successfully subject in the Subject.getprincipal (), get this user's username.

Any place can be directly used tool method to get subject:subject Subject = Securityutils.getsubject ();

You can tell by subject.isauthenticated () that the current user is logged in, and you can get the information we put into the session directly through Subject.getsession ().

If Subject.isremembered () is true, after logging in, Shiro serializes the principal object to byte[], base64, and adds it to the client's cookie, with a default expiration of 1 years. The next time the user accesses the login, the RememberMe data in the cookie is taken out directly to the server side, and the Shiro can be deserialized to restore the identity information of the original user. This base64 cookie value can be viewed in the browser settings:

Second, the realization of the organization plus user name verification

Shiro default this set of mechanisms is done according to the user name. Now that there are multiple organizations in our system, different organizations can have the same user name, then how do we implement the authentication based on the organization + user name?

Two ideas to solve this problem:

The organization + user name is stitched together as username extension Usernamepasswordtoken and principal in Usernamepasswordtoken

Each of these two ideas have pros and cons, the first is relatively simple and rough, the second comparison Standard General.

Because we are doing a good job based on the implementation of username and then modify the code implementation to expand the organization, so the first way to change the smallest:

System login page form plus agency type and organization name selection, backstage to the organization type + mechanism id+username stitching into admin:1:3 form, as Usernamepasswordtoken username, Realm implementation using custom or I wrote this Servicerealm (only 3 classes), SQL changed to get the password based on the agency Id+username and then use Subject.login login to achieve the organization + user-based authentication. Login to view Subject.getprincipal is already in the form of Admin:1:3.

The second kind is analyzed later. third, as modified username format +rememberme caused by a small problem

If the browser previously used the RememberMe selection after the installation of the above method to modify the username format (such as Admin:1:3), because its cookie is valid for 1 years, each time automatically log in poetry, The serialized cookie data submitted from the client is old data, the restored principal or the old format (such as admin), resulting in inconsistent data and program execution error.

Workaround: Clear the browser's cookie, or force the client to log in directly using login once.