The session API is located in the editor module, it enables authentication to translate5 via API.
Provides actions about the authenticated user
User sessions can be created / deleted by this API. Also some status information to the authenticated user can be retrieved.
The POST requests needs the following two parameters either as data object or plain form parameters:
The user to be authenticated.
The passwd of the user to be authenticated.
|taskGuid||string||Optional: The taskGuid of the task which should be opened for the user.|
POST resulting resource layout
Returns HTTP 200 when login was successful, 400 when parameters are missing, 403 when credentials were wrong.
When using the optional parameter taskGuid, 404 can happen when the task to the given taskGuid can not be found. When the user is no PM user and it is not associated to the task, also a 403 is triggered.
A successful result looks like:
the sessionId of the newly created session, can be used directly for further API communication.
The given sessionId is essential for further usage of other requests to the API, see below in the section API Usage.
A one time usable token which can be passed to the users browser for overtaking the created session.
For example: Users are administered by your software, translate5 is just embedded.
GET resulting resource layout
For GET the sessionId must be part of the URL, like the usual ID parameter: /editor/session/SESSION_ID
Returns HTTP 200 when user is authenticated, 404 otherwise.
contains "authenticated" or "not authenticated"
contains the authenticated user or null. The users structure is as described in the user API.
For DELETE the sessionId must be part of the URL, like the usual ID parameter: /editor/session/SESSION_ID
Returns HTTP 200 when session was destroyed, 404 otherwise.
Instead of the session ID also the internalSessionUniqId can be provided. Thats possible for DELETE only, and the calling user must be an API user.
Using the received sessionId in other API calls
Translate5 does not use a traditional RESTful authentication, but uses sessions for this purpose.
To use the API as an authenticated user, first a session must be generated by the above mentioned session POST call.
The received sessionId must be given on each other request to the API as cookie HTTP header.