EandrewJones opened a new issue, #397:
URL: https://github.com/apache/flagon-useralejs/issues/397
### Problem
The current method of adding an authentication header to UserALE is static.
The user sets the value as a string once when first configuring userale
options, e.g.
```javascript
userale.options({
...
authHeader: `Bearer ${token}`, // <---- update token here
});
```
These are then sent as part of the POST requests to whichever back-end
persistence endpoint was set. The **problem is most authentication systems have
a TTL on tokens** and they may expire as frequently as every 30 mins or sooner.
Therefore, the POST requests will fail because the token has expired.
Many auth systems will automatically refresh the token in the client's
browser. We need an agnostic and dynamic way to update userALE's authHeader
without forcing the user to reset the options _every time_ there's an
expiration.
### Solution
We can allow users to register an authHeader callback function which fetches
the current token and returns it as a properly formatted string (depending on
which authentication method they're using on their back-end). This function
would then be used in a pre-send hook, where we first fetch a non-expired token
and then update the current authHeader field with it.
By following a strategy pattern, all we need to do is "enforce" the desired
interface the callback function should follow. Then users can include whatever
business logic is needed to achieve the token fetching. Of course, it's a bit
tough to strictly enforce a function interface without Typescript, but we can
document the pattern.
For end users, it would be as simple as:
```javascript
const authCallback = (): string => {
// Business logic here
return `Bearer ${token}`
}
userale.registerAuthCallback(authCallback)
```
### Pros
This is a simple and clean pattern for handling the token refresh lifecycle
(or other challenges) without making any assumptions about which auth
approaches end users are using. All we're assuming here is:
1. they are utilizing the authHeader in some way; and
2. it needs to be dynamically updated.
### Cons
If the authCallback is async because it needs to make a network request, as
opposed to say fetching a token directly from the browser, this would add some
over-head to the rate at which we POST logs. However, it's better than an
alternative where the headers go stale, POST requests 401, and users lose data.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@flagon.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscr...@flagon.apache.org
For additional commands, e-mail: notifications-h...@flagon.apache.org
