@palbase/backend 38.0.2 → 38.0.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/docs/auth.md +12 -0
- package/docs/llms-full.txt +12 -0
- package/package.json +1 -1
package/docs/auth.md
CHANGED
|
@@ -56,6 +56,18 @@ mid-session keeps reporting `false` until their next token. `roles` is the
|
|
|
56
56
|
exception, and deliberately so — it is read from the table on every request, so
|
|
57
57
|
a grant or a revocation lands immediately.
|
|
58
58
|
|
|
59
|
+
**"Their next token" is a refresh away — not a sign-in.** `POST
|
|
60
|
+
/auth/token/refresh` re-reads the row when it mints, so the rotated token
|
|
61
|
+
carries the verification that just happened. Signing out and back in is never
|
|
62
|
+
the remedy.
|
|
63
|
+
|
|
64
|
+
The mobile SDKs spend that refresh for you — iOS from Palbe 0.57.0, Android
|
|
65
|
+
from 2.1.0. Both rotate when `refreshUser()` sees the flag flip, and both give
|
|
66
|
+
a `403 email_not_verified` one renew-and-replay, the way a 401 already gets
|
|
67
|
+
one. On any other caller — a web client, a script, a server-to-server
|
|
68
|
+
integration — do it yourself: call `POST /auth/token/refresh` with the refresh
|
|
69
|
+
token and use the pair that comes back.
|
|
70
|
+
|
|
59
71
|
## Roles and permissions
|
|
60
72
|
|
|
61
73
|
Roles are **yours**. There is no built-in "admin": you declare the roles your
|
package/docs/llms-full.txt
CHANGED
|
@@ -832,6 +832,18 @@ mid-session keeps reporting `false` until their next token. `roles` is the
|
|
|
832
832
|
exception, and deliberately so — it is read from the table on every request, so
|
|
833
833
|
a grant or a revocation lands immediately.
|
|
834
834
|
|
|
835
|
+
**"Their next token" is a refresh away — not a sign-in.** `POST
|
|
836
|
+
/auth/token/refresh` re-reads the row when it mints, so the rotated token
|
|
837
|
+
carries the verification that just happened. Signing out and back in is never
|
|
838
|
+
the remedy.
|
|
839
|
+
|
|
840
|
+
The mobile SDKs spend that refresh for you — iOS from Palbe 0.57.0, Android
|
|
841
|
+
from 2.1.0. Both rotate when `refreshUser()` sees the flag flip, and both give
|
|
842
|
+
a `403 email_not_verified` one renew-and-replay, the way a 401 already gets
|
|
843
|
+
one. On any other caller — a web client, a script, a server-to-server
|
|
844
|
+
integration — do it yourself: call `POST /auth/token/refresh` with the refresh
|
|
845
|
+
token and use the pair that comes back.
|
|
846
|
+
|
|
835
847
|
## Roles and permissions
|
|
836
848
|
|
|
837
849
|
Roles are **yours**. There is no built-in "admin": you declare the roles your
|
package/package.json
CHANGED