Skip to content

Validate server and token with a single request - #374

Merged
iLLiCiTiT merged 4 commits into
developfrom
enhancement/validate-token-fewer-requests
Nov 3, 2026
Merged

iLLiCiTiT merged 4 commits into
developfrom
enhancement/validate-token-fewer-requests

Conversation

@BigRoy

@BigRoy BigRoy commented Oct 30, 2026 •

Copy link
Copy Markdown
Member

Changelog Description

Creating a connection with a token (ServerAPI, GlobalServerAPI, create_connection) makes 1 request on 1 connection. Before, it made 3 requests on 3 connections, or 4 on 4 with an API key.

Part of ynput/ayon-launcher#129.

Additional info

Before, a connection with a token requested, each with requests.get and therefore each on a new TCP/TLS connection:

  1. GET / (web frontend page) to check availability
  2. GET /api/info
  3. GET /api/users/me with Authorization: Bearer
  4. For an API key, the Bearer request always gets 401, then GET /api/users/me with X-Api-Key

Now:

  • Availability check and token validation share one request, GET /api/users/me. A 200 or 401 response means the server is available. Any other response falls back to GET /api/info, which replaces GET / as the availability check.

  • The token's length decides which auth header is tried first. AYON creates session tokens of 64 characters, and API keys of service users are 32 characters. A 64-character token tries Authorization: Bearer first, then X-Api-Key. Any other token tries X-Api-Key first, then Bearer, so a valid token needs one request either way. The fallback keeps custom session tokens of other lengths working (Session.create in ayon-backend accepts a custom token). Such a token pays for the failed first try, because an invalid API key costs a 0.2 s server-side delay plus a brute-force counter hit. An invalid token still makes two requests, as before.

  • Validation requests use a session, which then becomes the authorized session, so the first API request reuses the same connection.

  • create_session doesn't validate an already validated token again.

  • validate_token no longer requests /api/info first. It does so only when users/me returns an unexpected status, so a URL that isn't an AYON server still raises.

  • get_user_info_by_token has an optional session argument.

Behavior changes:

  • create_session() no longer re-validates a token that was already validated. A token that became invalid since is still caught: the first request gets 401 and marks it invalid, as before.
  • The availability check without a token requests /api/info instead of the web frontend page.
  • A URL of a server that isn't AYON raises ServerNotReached. Before, the error depended on whether that server answered / with 200.

Measured in AYON launcher startup, together with ynput/ayon-launcher#346, against a local server with 50 ms latency added per request and per new connection:

Scenario Before After
User token 13 requests, 8 connections, 1.93 s 4 requests, 1 connection, 1.31 s
Service API key 15 requests, 10 connections, 2.08 s 4 requests, 1 connection, 1.16 s

Not changed here: get_user_by_token returns user_info.data, but UserInfo has no data field, so it raises AttributeError whenever the token is valid.

Testing notes:

  1. pytest tests/test_token_validation.py (no server needed).
  2. Create a connection with a user token and with a service API key. Check that each makes one request (e.g. in server logs or with a proxy).
  3. Create a connection to an unreachable URL (raises a connection error), and to a URL that isn't an AYON server (raises ServerNotReached).

- Availability check uses the token validation request when a token
  is set, a 200 or 401 response means the server is available.
- Tokens which are not 64 characters long are sent only as
  'X-Api-Key', server accepts only 64 characters long tokens as Bearer.
- Validation requests use a session which becomes the authorized
  session, so the connection is reused.
- 'create_session' does not validate an already validated token again.
Comment thread ayon_api/utils.py Resolved
Comment thread ayon_api/utils.py Resolved
Tokens of 64 characters are tried as 'Authorization' first, any other
token as 'X-Api-Key' first. Valid tokens still need a single request,
custom session tokens of other length still work.
@iLLiCiTiT
iLLiCiTiT marked this pull request as ready for review November 3, 2026 09:24
@iLLiCiTiT
iLLiCiTiT merged commit f2ca13d into develop Nov 3, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

type: enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants