If you see the following error, what is the appropriate action?
"message":"Your session has been logged out as the same user is logged in elsewhere.",
Intralinks has a setting called “disallow concurrent logins”. This setting can be on the user account itself (this is very rare) or on the individual workspaces (more common) with security for a user session following a “most restrictive” evaluation when logging in. Typically, user sessions are valid for a minimum of 60 minutes from the last activity and are stored in cookies in the users browser when the user logs in. So long as the user continues to access the system with the same session id all is good. When a user logs into Intralinks from the UI, the previous session is invalidated and a new one is created. 90% of our users only ever access Intralinks from a browser, so very few people will ever run into an issue. This setting ensures that the user would only ever have 1 session on the service has been in Intralinks for a very long time and I do not know the original purpose of it beyond possibly solving some concurrent editing scenarios.
However, when a user has this setting applied to them (either thru user level or workspace level) any other tool (basically anything other than a browser) attempting to get a new session for the user will have to force a precedence and pass ‘endOtherSessions=true’ on the authentication request. This allows the caller to assume control of the user session. Due to the fact that user sessions have a minimum timeout of 60 minutes, refreshing the token also needs to pass this variable since the session associated with the refresh token might still be active.
Keep in mind, that since the API program would be running in the background, it could assume control of a user session, while the user is busy using it. This wont cause data loss, but the user in the browser will be kicked out to the login screen where they will most likely log in again, thus taking control of the session back form the background process. The background process should be prepared to refresh the session anytime an API call receives a 403 error. Obviously this kind of thing is not the best since you are basically fighting with the user for control, so when possible, I guess schedule background processes for times when the user is not active. Not ideal, but just the nature of Intralinks