I. Description
Session is used in permissions, which is generally used to store usernames and passwords. The following describes the storage of usernames and passwords in two situations.
II. Session under the same application
Since the key can be saved in the Session, if the report project and your own project are under the same application in the authority, the session is the same. At this time, the username and password are stored in the Session, and the username and password entered from the outside are stored on the browser side. Save to the Session, the designer can obtain the username and password, go to the corresponding address to match, the match is successful, the permission level is passed, the match fails, and the login page is redirected.
III. Session under the different application
In the same application environment, the Session cannot be directly obtained. To achieve the effect of single sign-on, pass the username and password to the designer in the project login interface to verify through the fs_load&cmd=sso method. If verify successfully, the username, password and role are added. It is saved on the designer in Session mode. At this time, the application session and the report session are not the same session, they are relatively independent and do not affect each other.
Both cross-domain projects and cross-language projects belong to projects under different applications. At this time, Sessions cannot be shared, not the same Session, so when logging off the user, trigger the report method: /webroot/decision?op=fs_load&cmd=ssout, then The effect of synchronizing user sessions.
Refer to the document Cross-domain single sign-on for the definition and logout of Session in the permissions.
