Mirror: The highly customizable and versatile GraphQL client with which you add on features like normalized caching as you grow.
(docs) - Expand willAuthError section with more notes on usage (#1601)
* (docs) - Expand willAuthError section with more notes on usage
* Update docs/advanced/authentication.md
authored by
Phil Pluckthun
and committed by
GitHub
1bed86d3
5bd87828
+38
-1
+38
-1
docs/advanced/authentication.md
+38
-1
docs/advanced/authentication.md
···
28
28
from persisted storage, and redirect them to the application home or login page.
29
29
30
30
**Refresh (optional)** — this is not always implemented; if your API supports it, the
31
-
user will receive both an auth token, and a refresh token.
31
+
user will receive both an auth token, and a refresh token.
32
32
The auth token is usually valid for a shorter duration of time (e.g. 1 week) than the refresh token
33
33
(e.g. 6 months), and the latter can be used to request a new
34
34
auth token if the auth token has expired. The refresh logic is triggered either when the JWT is known to be invalid (e.g. by decoding it and inspecting the expiry date),
···
283
283
return false;
284
284
}
285
285
```
286
+
287
+
This can be really useful when we know when our authentication state is invalid and want to prevent
288
+
even sending any operation that we know will fail with an authentication error. However, if we were
289
+
to use this and are logging in our users with a login _mutation_ then the above code will
290
+
unfortunately never let this login mutation through to our GraphQL API.
291
+
292
+
If we have such a mutation we may need to write a more sophisticated `willAuthError` function like
293
+
the following:
294
+
295
+
```js
296
+
const willAuthError = ({ operation, authState }) => {
297
+
if (!authState) {
298
+
// Detect our login mutation and let this operation through:
299
+
return !(
300
+
operation.kind === 'mutation' &&
301
+
// Here we find any mutation definition with the "login" field
302
+
operation.query.definitions.some(definition => {
303
+
return (
304
+
definition.kind === 'OperationDefinition' &&
305
+
definition.selectionSet.selections.some(node => {
306
+
// The field name is just an example, since signup may also be an exception
307
+
return node.kind === 'Field' && node.name.value === 'login';
308
+
})
309
+
);
310
+
})
311
+
);
312
+
} else if (false /* JWT is expired */) {
313
+
return true;
314
+
}
315
+
316
+
return false;
317
+
};
318
+
```
319
+
320
+
Alternatively, you may decide to let all operations through if `authState` isn't defined or to allow
321
+
all mutations through. In an application that allows unauthenticated users to perform various
322
+
actions, it's a good idea for us to return `false` when `!authState` applies.
286
323
287
324
[Read more about `@urql/exchange-auth`'s API in our API docs.](../api/auth-exchange.md)
288
325