-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
refactor(auth): provider -> strategy,
setup method, multiple tokens
BREAKING CHANGE:
## 1. refactor(auth): rename auth provider to strategy
- term auth `provider` renamed to auth `strategy` to eliminate intersection with Angular providers
- `NbDummyAuthProvider` renamed to `NbDummyAuthStrategy`
- `NbEmailPassAuthProvider` renamed to `NbDefaultAuthStrategy`
- `NbAbstractAuthProvider` renamed to `NbAuthStrategy`
- `NbAuthModule.forRoot({ forms.login.provider })` changed to `NbAuthModule.forRoot({ forms.login.strategy })`
```
`NbAuthModule.forRoot({
forms: {
login: {
strategy: 'email', // provider -> strategy
},
},
})`
```
## 2. refactor(auth): rename config to options (to conform with the rest of the app)
`NbDummyAuthStrategyOptions` & `NbDefaultAuthStrategyOptions` are now classes with default values.
- NbAuthModule.forRoot now takes `options` instead of `config` for a strategies
```
NbAuthModule.forRoot({
strategies: {
email: {
service: NbEmailPassAuthStrategy,
options: { // was `config` previously
...
},
},
},
}),
```
## 3. refactor(auth): pass strategies through special `setup` method
Refactor strategies object to array and pass strategy options through `setup` method.
Strategy name moved inside of options object.
- Auth module options' `strategies` list changed from a key=>value object to an array.
So now instead of
```
strategies: {
email: {
service: NbEmailPassAuthProvider,
config: { ... }
}
}
```
we do this:
```
strategies: [
NbPasswordAuthStrategy.setup({ name: 'email', ... }),
]
```
This way we can type-check the configuration object for each strategy specified.
## 4. refactor(tokens): add ability to use multiple tokens
this allows having multiple tokens registered in the app. For instance,
`NbJWTAuthToken` for `NbPasswordAuthStrategy` and `NbOAuth2AuthToken` for
`NbOAuth2AuthStrategy`, allowing to work with multiple strategies.
- `NB_AUTH_TOKEN_CLASS` token is removed. Instead, we specify token class
within strategy configuration:
```
@NgModule({
imports: [
// ...
NbAuthModule.forRoot({
strategies: [
NbPasswordAuthStrategy.setup({
name: 'email',
token: {
class: NbAuthJWTToken, // <----
}
}),
],
}),
],
});
```
- token class must have a `NAME` static field specified
- tokens are now stored as JSON string `{ name: 'token-name', value: 'token-value' }`
- now Strategy returns `NbAuthToken` instance instead of raw value
- setRaw method of `NbTokenStorage` and `NbTokenService` is removed
- token must have a payload- Loading branch information
Showing
43 changed files
with
1,401 additions
and
1,100 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,143 @@ | ||
| ## A Strategy | ||
|
|
||
| In Nebular terms `Auth Strategy` is a class containing authentication logic specific for some authentication flow (email/password, OAuth2, etc). | ||
| It accepts user input (login/email/password/token/etc), communicates the input to the backend API and finally provides the resulting output back to the Auth UI layer. | ||
| Currently, there are two Auth Strategies available out of the box: | ||
|
|
||
| - `NbDummyAuthStrategy` - simple strategy for testing purposes, could be used to simulate backend responses while API is in the development; | ||
| - `NbPasswordAuthStrategy` - the most common email/password authentication strategy. | ||
|
|
||
| Each Strategy has a list of configurations available with the default values set. But you can adjust the settings based on your requirements. | ||
| <hr class="section-end"> | ||
|
|
||
| ## Configuration | ||
|
|
||
| As an example, let's configure API endpoints for the `NbPasswordAuthStrategy`. The strategy is configured by default, please take a look at the [default configuration values](#/docs/auth/NbPasswordAuthStrategy) if you need any custom behaviour. | ||
| We assume you already have the Auth module installed inside of your `*.module.ts`: | ||
|
|
||
|
|
||
| ```typescript | ||
|
|
||
| @NgModule({ | ||
| imports: [ | ||
| // ... | ||
|
|
||
| NbAuthModule.forRoot({ | ||
| strategies: [ | ||
| NbPasswordAuthStrategy.setup({ | ||
| name: 'email', | ||
| }), | ||
| ], | ||
| forms: {}, | ||
| }), | ||
| ], | ||
| }); | ||
|
|
||
| ``` | ||
| `email` here is an alias we assign to the strategy, so that we can mention it later on dynamically. This also allows us to configure multiple strategies with various configurations in one app. | ||
|
|
||
| Now, let's add API endpoints. According to the [NbPasswordAuthStrategy documentation](#/docs/auth/NbPasswordAuthStrategy), we have `baseEndpoint` setting, and also an `endpoint` setting for each function (login/register/etc): | ||
|
|
||
| ```typescript | ||
|
|
||
| @NgModule({ | ||
| imports: [ | ||
| // ... | ||
|
|
||
| NbAuthModule.forRoot({ | ||
| strategies: [ | ||
| NbPasswordAuthStrategy.setup({ | ||
| name: 'email', | ||
|
|
||
| baseEndpoint: '', | ||
| login: { | ||
| // ... | ||
| endpoint: '/api/auth/login', | ||
| }, | ||
| register: { | ||
| // ... | ||
| endpoint: '/api/auth/register', | ||
| }, | ||
| }), | ||
| ], | ||
| forms: {}, | ||
| }), | ||
| ], | ||
| }); | ||
| ``` | ||
|
|
||
| Let's assume that our API is localed on a separate server `http://example.com/app-api/v1` and change the `baseEndpoint` accordingly: | ||
|
|
||
| ```typescript | ||
| { | ||
| // ... | ||
| baseEndpoint: 'http://example.com/app-api/v1', | ||
| // ... | ||
| } | ||
| ``` | ||
|
|
||
| And configure the endpoints, considering that the final endpoint will consist of `baseEndpoint + method.endpoint`: | ||
|
|
||
| ```typescript | ||
| { | ||
| baseEndpoint: 'http://example.com/app-api/v1', | ||
| login: { | ||
| endpoint: '/auth/sign-in', | ||
| }, | ||
| register: { | ||
| endpoint: '/auth/sign-up', | ||
| }, | ||
| logout: { | ||
| endpoint: '/auth/sign-out', | ||
| }, | ||
| requestPass: { | ||
| endpoint: '/auth/request-pass', | ||
| }, | ||
| resetPass: { | ||
| endpoint: '/auth/reset-pass', | ||
| }, | ||
| } | ||
| ``` | ||
|
|
||
| Finally, let's presume that unlike in the default strategy settings, our API accepts only `HTTP POST`, so let's fix that too: | ||
|
|
||
| ```typescript | ||
| { | ||
| baseEndpoint: 'http://example.com/app-api/v1', | ||
| login: { | ||
| endpoint: '/auth/sign-in', | ||
| method: 'post', | ||
| }, | ||
| register: { | ||
| endpoint: '/auth/sign-up', | ||
| method: 'post', | ||
| }, | ||
| logout: { | ||
| endpoint: '/auth/sign-out', | ||
| method: 'post', | ||
| }, | ||
| requestPass: { | ||
| endpoint: '/auth/request-pass', | ||
| method: 'post', | ||
| }, | ||
| resetPass: { | ||
| endpoint: '/auth/reset-pass', | ||
| method: 'post', | ||
| }, | ||
| } | ||
| ``` | ||
|
|
||
| <div class="note note-info"> | ||
| <div class="note-title">Note</div> | ||
| <div class="note-body"> | ||
| No need to list all available configurations there. Your settings will be merged with default strategy settings accordingly. | ||
| </div> | ||
| </div> | ||
|
|
||
| Great! With these simple steps, you should have the authentication layer correctly configured against your API back-end. | ||
| <hr class="section-end"> | ||
|
|
||
| ## Where to next | ||
|
|
||
| - Adjusting [Auth Components UI](#/docs/auth/configuring-ui) | ||
| - Receiving [user token after authentication](#/docs/auth/getting-user-token) |
Oops, something went wrong.