Repository navigation
Troubleshooting
A login crosses the application, browser and provider. Follow each boundary when diagnosing a failure.
SessionNotStartedException means no request-scoped storage was supplied. Use a framework adapter with a store or supply a container explicitly. Never use a shared visitor container for all requests.
Ensure the callback route runs the authentication setup with its actual path and query. Check that the same session cookie arrives and the shared store contains the original login token. Secure cookies require HTTPS; disable that setting only for local HTTP. Responses without exchange state are cleaned without authenticating.
Construct the client before response output. Let redirect signals propagate to the adapter. Return response bodies through the buffered integration so it can save the session first.
Check the deployment key, provider host and stored token from the same login exchange. A changed key, lost session or second concurrent login can invalidate an old response. The secret is 32 raw bytes. DecryptionFailureException reports cipher failures. Log failures without including secrets or encrypted URLs, then offer a fresh login.
Configure the return URI before login. Otherwise the current URI is requested. Use root-relative paths or absolute URLs on the configured client origin. Invalid destinations fall back to the provider's configured return URI. The destination must execute authentication setup. See Provider configuration and return URIs.
Restoring a session does not invoke the callback. Its marker is saved before invocation, so callback failure does not cause replay to retry it. Keep callbacks synchronous and arrange application retries separately.
Explicit logout destinations override configured return URIs; the provider default applies when both are absent. Query-only destinations use the current path. Do not invoke logout repeatedly from the signed-out route.
Next, see API reference.
Authwave’s Python client connects your application to an Authwave provider.