PUT /internal_api/app_session_request/<sessionRequestId>
put_internal_api_app_session_request_id
Poll it with no body. {"approved": false} while pending; once, {"approved": true, "sessionToken", "userLogin"}; then 404 forever. Forgotten, denied and unknown all read the same 404.
API
Step two of the App Session Launcher. The client polls this while a person approves the request in a
browser, and the one 200 with approved: true is the only time the session token is handed out.
Params
| part | value |
|---|---|
| path | <site>/internal_api/app_session_request/<sessionRequestId>, the id from the POST |
| auth | none |
| body | none needed. machineId sent here is ignored, right or wrong |
Sample requests
r = requests.put(f"{site}/internal_api/app_session_request/{sid}", timeout=30)
Before the person has approved:
{"approved": false}
After:
{"approved": true, "sessionToken": "<token>", "userLogin": "<login>"}
Any call after that one, and any call on an id the site does not hold:
{"message": "Not Found"}
Response codes
| status | when |
|---|---|
| 200 | pending, approved false, or approved, with sessionToken and userLogin |
| 404 | {"message": "Not Found"}. The id is unknown, the token was already handed out, or nobody approved it in time |
| 404 | GET or POST on this path. JSON:API envelope, code 103 |
Edge cases
- The token is handed out once. The
PUTafter the approved one is 404, so a client that polls from two places loses the token to whichever asked first. KeepsessionTokenfrom the one response that holds it. - The three 404 causes are one body. A client cannot tell a denied request from a forgotten one or a typo in the id, and should say so to the person rather than guess.
- On the probed site, an Autodesk Identity site,
userLoginis the person's email address. Treat it as identifying. sessionTokenis whatPOST /auth/access_tokentakes assession_token. It is a credential for the person who approved: store it where a key would be stored.