Sessions represent an Authenticated context in the ShareFile API. Before clients can call any authenticated API, they must first acquire a Session cookie using their authentication credentials. The Session ID must then be provided to the API using a Cookie header named SFAPI_AuthID. ShareFile API clients must supports multiple domains - represented by the Entity URL parameter. For example, one directory in sf-api.com may contain directories in another domain if ShareFile Connectors are used. Clients may be prompted for additional authentication on these Connected domains if they attempt to perform operations on their objects. Clients must, therefore, keep authentication contexts for each Connected domain, and only issue the Session cookie to the originating domain - i.e., behave like a web browser regarding authentication and cookies.
GET https://account.sf-api.com/sf/v3/Sessions
Retrieve the current authentication session object. If the client is not authenticated, this operation will challenge for ShareFile authentication using a 401 response. This method will not trigger the SAML authentication flow - use /Sessions/Login instead.
Returns: The current authentication Context, based on the request SFAPI_AuthID Cookie
DELETE https://account.sf-api.com/sf/v3/Sessions
Logout the current session - invalidate the current Session ID
GET https://account.sf-api.com/sf/v3/Sessions/Login
API clients can provide ShareFile Authentication directly to any API operation using OAuth (Bearer). However, the client must know that the provided authentication type is supported on the API endpoint; and that SAML is not configured.
This API provides a generic authentication routine for clients. It will challenge for ShareFile credentials passing all supported authentication methods; redirect to the SAML IDP if configured to do so; and handle certain HTTP headers, like device registration.
If the client is already authenticated, the Session object is returned. If the client is not authenticated, and the account is not configured for SAML, then the API will challenge for a local authentication. If the account is configured for SAML, then the client will be redirected to the SAML IDP using the SAML passive flow - authentication will be performed at the IDP domain instead. The IDP callback will be on the API Acs, which will return a Session object if authentication is accepted.
The following HTTP Headers are also processed in this request, and stored with the Session object: X-SFAPI-Tool: Tool string (user-agent equivalent for ShareFile)X-SFAPI-ToolVersion: Tool Version stringX-SFAPI-UserInitiated: true or false, indicates whether this is an interactive login, or re-authentication initiated by the ToolX-SFAPI-DeviceId: Device Identifier. If set to 'register', a new DeviceID will be generated. This will either create or associate an existing DeviceID to this session - indicates user is logging in using this DeviceX-SFAPI-DeviceName: Device Name. Only required/used when a registration process occurs.
| authmethod | String | |
| authcomparison | String |
Returns: A Session object, if authentication is successful
GET https://account.sf-api.com/sf/v3/Sessions/Acs
Returns: