Since most applications need some authentication support it doesn’t make sense to make users find their own path how to handle it and I find myself repeating the same code for handling client side authN,
If you are not against this then the highlights I was thinking about are:
- Provide some authN token based support by managing the authN flow but with some freedom (See below)
- Expect a promise of the login action to the server, implemented by the user.
- Raise authenticationRequired event when error code (default to 403) occur but let the user choose other codes (such as 401) to suite custom needs, this is a generic but easy way to redirect to the login form or any other route that needs to take care of authentication.
- Store credentials in localStorage but let user overrides this easily for custom needs(cookie based maybe)
- Support even credentialsHasChanged in case user re-authenticate
If there’s a good reason to totally not support anything related to authN then feel free to close the issue, if you are up to it then comments are welcome to understand whether this is possible to generalize enough to support any user needs but still provide some value out of the box.