Docs updates.

This commit is contained in:
2025-12-19 20:23:49 +00:00
parent 0bfb035f76
commit d25124d30b
2 changed files with 43 additions and 1 deletions
+10 -1
View File
@@ -1,6 +1,14 @@
# Paskia API # Paskia API
Use these tables when integrating Paskia authentication into your app. ## Integrating with your app frontend
Protect API routes with forward-auth (see [Caddy](Caddy.md)). Optionally protect your app assets and not just the API.
Catch response status 401/403 in fetch calls to protected endpoints and implement authentication flow in this case. The response is JSON and contains `auth.iframe` (a URL). [Render that URL in an iframe](AuthFlow.md) and retry the request after authentication.
While the app is in (active) use, call `/auth/api/validate` occasionally to keep the session alive (session lifetime is 24h), otherwise the user will have to login every day. Max-age limits are unaffected by this and can be used on endpoints needing to reauthenticate with passkey more frequently.
Use `/auth/api/user-info` to display user/session details, or link to `/auth/` if you prefer using the built-in profile UI and not having to anything more.
### Web Interface ### Web Interface
@@ -59,5 +67,6 @@ On the auth host:
- Auth WebSockets remain at `/auth/ws/*` but take connections from other hosts to issue sessions for each of those. - Auth WebSockets remain at `/auth/ws/*` but take connections from other hosts to issue sessions for each of those.
On non-auth hosts: On non-auth hosts:
- `/auth/` shows only minimal profile and allows logging out of the current site
- `/auth/api/*` is served normally. - `/auth/api/*` is served normally.
- `/auth/api/user/*`, `/auth/api/admin/*`, and `/auth/ws/*` don't exist. - `/auth/api/user/*`, `/auth/api/admin/*`, and `/auth/ws/*` don't exist.
+33
View File
@@ -0,0 +1,33 @@
# API Authentication Flow (iframe)
This document describes the frontend flow for handling `401/403` responses from endpoints protected by Paskia forward-auth, without ever exiting your app.
```js
// Show an authentication dialog
const iframe = document.createElement('iframe')
iframe.src = auth.url // from 401/403 response JSON
iframe.style.cssText = `
position: fixed;
inset: 0;
width: 100%;
height: 100%;
border: 0;
z-index: 9999;
background: transparent;
backdrop-filter: blur(0.1rem) brightness(0.7);
`
document.body.appendChild(iframe)
// Wait until user is finished with the dialog
const handler = ev => {
if (ev.origin !== location.origin) return
iframe.remove()
removeEventListener('message', handler)
if (ev.data?.type === 'auth-success') retry_original_fetch()
}
addEventListener('message', handler)
```
When a protected request fails, the backend returns 401 (needs auth / reauth) or 403 (missing permission). For API requests, the response is JSON that includes an iframe URL. Your app should render that URL in a full-screen iframe overlay, and retry the request after the iframe reports success. If it reports `auth-cancel`, don't try again. The backdrop for the dialog is a stylistic choice, and you can style the background shown with the dialog any way you wish, and consider using CSS file with the iframe rather than inline styles as used in the example.
If this seems too heavy for your needs, you can simply refresh the page or navigate to /auth/ but this will lose your app state and in the latter case affect navigation in a way that is not optimal.