Intralinks Developer Portal


If you see the following error, what is the appropriate action?
"error":{
"code":403,
"message":"Your session has been logged out as the same user is logged in elsewhere.",
"subcode":"018",
"errorid":""
}

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

If you see the following error, what is the appropriate action?
"error":{
"code":403,
"message":"Your session has been logged out as the same user is logged in elsewhere.",
"subcode":"018",
"errorid":""
}

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

The callback url is a URL your application handles that we send the user back to once they have authenticated. The basic flow is:

1 - Your app sends the user’s browser to the Intralinks login page using the oauth/authorize API.

2 - User logs in

3 - Intralinks redirects the user back to your application using the redirect URL you specify in your application properties.

For more detail please see our "Authentication" document in the Getting Started section of the developer's portal.

Most App requests for the test environment will be approved within 1 to 2 business days. If you made a request that has not been approved feel free to contact apiteam@intralinks.com for details.

When requesting access to production, it will generally take 5-10 business to get a production API key provisioned. 

Have a look at our glossary of common terms for the answers to these and other common words you will see referenced in Intralinks products.

Once you have your application ready to work with the Intralinks production environment, please contact us at apiteam@intralinks.com and we will work with you to create a new set of keys to use with your application with the production environment.

We have some great information on our homepage of course at intralinks.com. You can also learn more about some of our capabilities on our slide share site.

You can get an API key by registering for an account on this site and then going over to the "My Apps" section of your account profile page and clicking "Add and App". Detailed step by step instructions are in our handy 'Getting Started Guide'.