first draft for multiple user models feature #297
Conversation
| module.exports = function enableAuthentication(server) { | ||
| server.enableAuth(); | ||
| }; | ||
| ``` |
There was a problem hiding this comment.
This is usually not enough, one has to attach all authentication models (ACL, Role, etc.) to a datasource. In our project templates, this is done by listing these models in server/model-config.json. For users adding authentication to an empty-server project, I would recommend to let enableAuth to auto-attach any required models, so that server/model-config.json changes are not required.
server.enableAuth({ dataSource: 'db' });There was a problem hiding this comment.
@bajtos : i updated the doc to let the users know about this feature anyhow
|
|
||
| {% include note.html content=" | ||
| Usually you don't need any extra configuration regarding built-in models `Role`, `RoleMapping`, and `ACL` which you can use without any customization. Just make sure they are declared in the `model-config.json` configuration file. | ||
| " %} |
There was a problem hiding this comment.
Ah, I guess this invalidates my previous https://github.com/strongloop/loopback.io/pull/297/files#r103671404
There was a problem hiding this comment.
took care of merging
|
|
||
| #### Access Control with a single user model | ||
|
|
||
| In the case your application leverages only one type of user extending the built-in `User` model (which should the case in a majority of configurations), you barely have no further configuration to do. |
There was a problem hiding this comment.
which should be the case (add be)
|
|
||
| In order to allow the Loopback access control system to work with several models extending the built-in `User` model. The relations between the `users` models and the `AccessToken` should be modified to allow a single `AccessToken` model to host access tokens for multiple types of users while at the same time allowing each `user` models instances to be linked to their related access tokens in a non ambiguous way. | ||
|
|
||
| This is achieved by changing the **hasMany** relation from `User` to `AccessToken` and the **belongsTo** relation from `AccessToken` to `User` by their [polymorphic](Polymorphic-relations) equivalents, in which the `principalType` property is used as a **_discriminator_** to resolve which of the potential `user` model instance an 'accessToken' instance belongs to. |
There was a problem hiding this comment.
[polymorphic](Polymorphic-relations)
I think this link won't work, I think the URL should include .html extension.
There was a problem hiding this comment.
Oddly enough, links do work either with or without the .html ext.
There was a problem hiding this comment.
yes it works locally
| ... | ||
| app.use(loopback.token({ | ||
| model: app.models.customAccessToken | ||
| })); |
There was a problem hiding this comment.
The idiomatic way is to configure middleware in server/middleware.json.
{
"auth": {
"loopback#token": {
"params": {
"model": "customAccessToken"
}
}
}
}(I typed the example from my head, may not work out of the box.)
There was a problem hiding this comment.
@bajtos I updated as per your snippet. I'd appreciate if you can link me to the exact reference, or assert this one is good
There was a problem hiding this comment.
I think this doc page is the most relevant: https://docs.strongloop.com/display/public/LB/Defining+middleware
There was a problem hiding this comment.
The new content showing loopback#token configuration looks good to me.
| You must create your own custom model (named something other than \"User,\" for example \"Customer\" or \"Client\") that [extends the built-in User model](Extending-built-in-models.html) rather than use the built-in User model directly. The built-in User model provides a great deal of commonly-used functionality that you can use via your custom model. | ||
|
|
||
| LoopBack does not support multiple models based on the User model in a single application. That is, you cannot have more than one model derived from the built-in User model in a single app. | ||
| Since version 3, Loopback supports multiple models based on the User model in a single application. See [this section](...) on how to configure the application accordingly. |
There was a problem hiding this comment.
[this section](...)
Looks like a forgotten to-do :)
|
Looks good! I will give this a test later this week to see if I can get it up and running. |
|
Thanks @ebarault I'd like a number of formatting/style/wording changes. Shall I just go ahead and make changes of this nature directly in the branch, rather than comment and ask you to edit? |
|
@crandmck : yes sure go ahead, this will be way more efficient this way. Let me know when you need a review. |
|
OK, I made a pass. There is a lot here. Well done, @ebarault ! Please review my edits. I think it's mostly wording and formatting. There's enough information of a fairly specialized nature that this might ultimately deserve its own article, apart form the main "Authentication, authorization, and permissions." But that can always come later. @bajtos I still think it needs a bit of work, but if you want to land it, I'm fine with just iterating on the published version. One thing I noticed--really orthogonal to the rest of the PR, but still--"Authentication, authorization, and permissions" uses |
Oh, of course, please use disableRemoteMethodByName. I was typing the comments from memory and I am not used to the new API yet. |
|
@bajtos : it's from the original text, not from your comments |
| You must create your own custom model (named something other than \"User,\" for example \"Customer\" or \"Client\") that [extends the built-in User model](Extending-built-in-models.html) rather than use the built-in User model directly. The built-in User model provides a great deal of commonly-used functionality that you can use via your custom model. | ||
|
|
||
| LoopBack does not support multiple models based on the User model in a single application. That is, you cannot have more than one model derived from the built-in User model in a single app. | ||
| Since version 3, Loopback supports multiple models based on the User model in a single application. See [this section](Authentication-authorization-and-permissions.html#access-control-with-multiple-user-models) on how to configure the application accordingly. |
There was a problem hiding this comment.
Should we spell out the specific LoopBack version where this feature was added?
- Since version 3, Loopback ...
+ Since version 3.3.0, Loopback ...Also I think the correct spelling is LoopBack, not Loopback?
|
Let's keep |
bajtos
left a comment
bajtos
left a comment
There was a problem hiding this comment.
The changes LGTM. I left one minor comment, it can be ignored or applied in a follow-up pull request.
|
I'll fix |
|
I made the last small changes @bajtos suggested. I'll merge this, and we can continue to improve it. As noted previously, at some point I may open another PR to move this into a separate article. |
|
Thanks again @ebarault! This is a great contribution. |
|
Great work @ebarault - I just implemented this in an example project and it works as expected: https://github.com/beeman/loopback-example-multiple-user-models I might add some ACL's and a simple UI to demo the functionality a bit more. Edit: that was a bit too fast. It seems that adding this line (https://github.com/beeman/loopback-example-multiple-user-models/blob/master/server/middleware.json#L37) that's noted in the docs causes an error message:
Is there something wrong in the way I implemented it? |
|
👏 thank you all! 👏 |
|
@beeman: thanks for providing this example 👍 . cc: @bajtos |
This is the PR for the documentation related to the feature introduced in strongloop/loopback#2971.
@crandmck, @beeman, @bajtos could you please take a look at this first draft?
I also performed a quick review of the Authentication, Authorization and Permissions section, with a few modifications. I will come back to this section later on in another PR, there are consistency issues to me, for example i don't quite figure out why this sub-section is included in the reviewed section.