Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update security-acl-configuration.md #196

Merged
merged 1 commit into from
Feb 8, 2018
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 9 additions & 9 deletions docs/articles/security-acl-configuration.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
## Abstract

Permissions control is a general task when it comes to development of more of less complex web application. Your application may have various roles and resources you need to protect.
Permissions control is a general task when it comes to development of more or less complex web application. Your application may have various roles and resources you need to protect.
ACL (access control list) provides a flexible way of configuring "who can do what against what resource".

In this article we configure a common setup when the app has three roles (`guest`, `user` and `moderator`), the roles have different permissions (`view`, `create`, `remove`)
Expand All @@ -10,8 +10,8 @@ and the application contains two type of resources that needs to be protected (`

Nebular ACL has a simple way of setting it up. When registering a module you can specify the ACL rules by simply providing it as a module configuration object.

Let's assume that our guest users can only `view` `news` and `comments`, users can do everything as guest, but also can `create` `comments`, and moderators can also `create` and `remove` `news` and `comments`.
Now, let's convert this into ACL configuration object witch Nebular can understand. Open your `app.module.ts` and change the `NbSecurityModule.forRoot()` call as follows:
Let's assume that our guest users can only `view` `news` and `comments`, users can do everything as guests, but also can `create` `comments`, and moderators can also `create` and `remove` `news` and `comments`.
Now, let's convert this into ACL configuration object which Nebular can understand. Open your `app.module.ts` and change the `NbSecurityModule.forRoot()` call as follows:

```typescript

Expand Down Expand Up @@ -46,9 +46,9 @@ which means that we have a permission againts any resource (like moderators can

## Role Configuration

So far we told Nebular Security which roles-permissions-resources our application has. Now we need to specify how Nebular can determine a role of currently authenticated user.
So far we told Nebular Security what roles-permissions-resources our application has. Now we need to specify how Nebular can determine a role of currently authenticated user.
To do so we need to create a `RoleProvider` with one simple method `getRole`, which returns an `Observable<string>` of a role.
In a simplest form we can provide this service directly in the main module:
In a simpliest form we can provide this service directly in the main module:


```typescript
Expand Down Expand Up @@ -84,9 +84,9 @@ The good thing about this configuration is that it's not tightly coupled with th

But, in our example the role is "hardcoded", which in the real world app would be dynamic and depend on the current user.

Assuming that you already have `Nebular Auth` module fully configured and functioning with `JWT` we will adjust the example to retrieve a role the user token.
Assuming that you already have `Nebular Auth` module fully configured and functioning with `JWT` we will adjust the example to retrieve a role to the user token.

Let's create a separate `role.provider.ts` service to not put a lot of logic into the module itself:
Let's create a separate `role.provider.ts` service in order not to put a lot of logic into the module itself:

```typescript
import { Injectable } from '@angular/core';
Expand Down Expand Up @@ -137,7 +137,7 @@ export class RoleProvider implements NbRoleProvider {
}
```

So we subscribe to the `tokenChange` observable, which will produce a new token each time authentication change is occurred. Then we simply get a tole from a token or return default `guest` value.
So we subscribe to the `tokenChange` observable, which will produce a new token each time authentication change occurres. Then we simply get a tole from a token or return default `guest` value.

And let's provide the service in the app module:

Expand Down Expand Up @@ -167,7 +167,7 @@ import { NbSecurityModule, NbRoleProvider } from '@nebular/security';
## Usage

Finally, we can move on to the part where we start using the ACL. Let's assume that we have that `Post Comment` button, that should only be shown to authenticated users (with a role `user`).
So we need to hide the button for guests. In your `comment-form.component.ts`, import the `NbAuthorizationChecker` service. It provides you with one method `isGranted`, which returns an `Observable<boolean>` of the ACL check result:
So we need to hide the button for guests. In your `comment-form.component.ts`, import the `NbAuthorizationChecker` service. It provides you with a method `isGranted`, which returns an `Observable<boolean>` of the ACL check result:

```typescript
import { Component } from '@angular/core';
Expand Down