sandrino-di-mattia

Principal Architect

Sandrino Di Mattia



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>Forrester Consulting analysis determines that using Auth0 can yield a 548% ROI and $3.7M in identity-related savings. Read the full report: <a href="https://resources.auth0.com/forrester-tei-research-case-study/">Total Economic Impact of Auth0</a>.</strong>
</div>

---
## Background

Authentication has always been the core of Auth0. But once you know who your users are, you’ll probably also need to know what they can do. Therefore, after authenticating users, you’ll need to authorize them. There are so many different ways to do this, from complex products to home-grown solutions. Using our rules engine, you could also consume this information during the login process.

## Concepts

The Authorization Extension which you can now install using the Extensions tab in the dashboard, tries to provide customers with a generic approach to managing authorization using three top-level concepts:

 - Groups
 - Roles
 - Permissions

### Groups

Groups are collections of users. They are a common way to organize users in enterprise directories like Active Directory. A company might create a group for every department, such as HR, Finance, Accounting, and IT.

Users can be added to one or more groups. But groups can also be nested, with members of one group automatically added as members of another group.

![An example of the "Finance Group"](https://images.ctfassets.net/23aumh6u8s0i/4aLHeBTDYJPNw1d4N0NZp9/2006be77627c5145502aa4e03a190fb8/group)

The main reason for having groups is that it allows us to group people who have the same profile within the company. It is easier to assign roles and permissions to groups than it is to individual people, who can can get sick, go on vacation or leave the company.

### Permissions and Roles

While groups are bound to an organization and not an application, the same is not true for roles and permissions.

If you look at an application that you are building, you’ll notice that users can do many things within your application. Everything your users can do are actions, including opening a record, updating one, deleting one, reporting, and changing settings. A permission determines whether you are allowed to execute an action or not, such as:

- `read:users`
- `run:reports`
- `update:settings`

![Permissions are granual actions that you can execute within an application](https://images.ctfassets.net/23aumh6u8s0i/5AwgqESXywzDYhMjTIE1qc/d86f2afabe3bbf22beaad7b7ed4da0c3/permissions)

These permissions only make sense within the application. A `generate:invoice` permission might make a lot of sense in your accounting application but no sense at all in your planning tool. Therefore, permissions represent actions that you can execute as a user within an application, and roles are there to group these permissions into logical collections.

A timesheet application can have a **Timesheet User** role and a **Timesheet Manager** role. A user will have certain permissions, such as `read:timesheets` `update:timesheets`, and `create:timesheets`, while a manager will have additional permissions, such as `approve:timesheet` and `reject:timesheet`.

![Roles are used to organize your permissions](https://images.ctfassets.net/23aumh6u8s0i/19bQ09h64GAFTBMd118b2Y/ce19dbfb9141a2919632edfbafdd323f/role)

These roles can be assigned to specific users or to groups; if roles are assigned to a group, every user of that group will receive those roles (and permissions).

## Consuming this information in your applications

After setting up everything in the extension, your applications will need to consume this information. The extension offers three ways to do this:

 - Adding information to the **id_token**
 - Adding information to the user’s **app_metadata**
 - Getting the information from a **policy decision point** (PDP)

In the configuration section, you can configure the behavior of the extension. Any change you make here will deploy a rule to your Auth0 account, which will add the information to the token, the app_metadata, or both.

If you’re implementing RBAC, for example, you could just check the box to store the roles in the token. But if you need to understand which permissions a user has in a specific application later, you could make the following call to get the user’s authorization data in the context of an application:

```
POST https://sandrino-dev.us.webtask.io/api/users/ad|john@fabrikam.com/policy/9CDFQBunB9ZvYRCpFWJlzpH9tUwclGIO
```

This will return the groups, roles, and permissions for a user in the context of the current application:

```json
{
  "groups": [
    "Distribution",
    "Accounting"
  ],
  "permissions": [
    "read:own-receipts",
    "update:own-receipts",
    "update:delete-receipts",
    "read:own-reports",
    "update:own-reports",
    "delete:own-reports",
    "submit:own-reports",
    "read:receipts",
    "read:reports",
    "approve:reports",
    "reject:reports"
  ],
  "roles": [
    "Expense User",
    "Expense Manager"
  ]
}
```

## Feedback?

This extension was built using React, Redux, Hapi, and Webtask. When you install it, the entire application will run in the Webtask container of your Auth0 account.

The full source code is available at https://github.com/auth0/auth0-authorization-extension. Feel free to open a GitHub issue if you have any feedback. 

## What lies ahead

Our API authorization feature has been in public preview for some time now, and it will be interesting to use the authorization extension in that context. Depending on your use case, your permissions can be represented as **scopes** in your access token.

Here are some additional resources to get you started:

- [Official documentation](https://auth0.com/docs/extensions/authorization-extension)
- [Automatically provisioning groups, roles, and permissions](https://github.com/auth0-extensions/authz-extension-automation-sample)


Announcing the Auth0 Authorization v2 Extension!


---

**TL;DR**: You can check out the sample application in [this Github repository](https://github.com/auth0/react-flux-debug-actions-sample)

---

Troubleshooting applications running in production is not always easy. You might get bug reports like "Nothing works!" In addition, some errors might only occur based on the data that the user is working with, and reproducing the issue could be challenging because of specific dependencies (e.g., user, API) … the list goes on and on!

There are plenty of tools available out there that can catch any errors with a stack trace and very detailed information, but even then the error might be hard to reproduce.

In this blog post, we'll show how you can leverage your existing React and Flux infrastructure in order to have a better logging and debugging experience.

## Example: Customer Service Application

The example in this blog post is a customer service application that allows you to manage open tickets. You can view the open tickets and close tickets that have been resolved.

<img src="https://images.ctfassets.net/23aumh6u8s0i/7MFsGErVECNOx4uCcnpFDx/e63340e0f1f9962375e3c48f863db7c6/react-flux-debugging-tickets" class="expand" />

John, an end user, is solving the open tickets and closing them one by one. But suddenly... a crash! So John goes ahead and opens a bug: "Nothing works!"

<img src="https://images.ctfassets.net/23aumh6u8s0i/6cXn7s2HJazm45a8Q4ikaO/6e5b6f4d28648b7919f27641c3f36ba5/react-flux-debugging-end-user" class="expand" />

Jane, a developer, is now assigned to work on the "Nothing works!" bug. Great. Luckily, their application is recording all Flux actions executed by users. These actions are linked to a user's session, so she can just go ahead and look for John's session. After that, she can replay John's session and try to figure out the problem.

<img src="https://images.ctfassets.net/23aumh6u8s0i/34RKZ1DgEy7MwjKIgsX5a9/4f9abbd929a3362f0091c66f7421a3b7/react-flux-debugging-developer" class="expand" />

Aha! While replaying John's session, an error pops up in the developer console. It looks like there might be a bug in the `Error.jsx` component.

## How does this work?

Implementing this in your own Flux applications is really easy. In our blog post about [ReactJS authentication](https://auth0.com/blog/2015/04/09/adding-authentication-to-your-react-flux-app/) using Flux, we explain what a typical Flux application looks like. Actions are dispatched to stores, and stores will notify components to update themselves. So if we want to keep track of all actions, we'll need to start with the dispatcher:

```javascript
import Dispatcher from './dispatcher';
import LogActions from './actions/LogActions';

// Export the dispatch method.
export default function dispatch(action) {
  Dispatcher.dispatch(action);
  LogActions.log(action);
}
```

<include src="TweetQuote" quoteText="Actions are dispatched to stores, and stores will notify components to update themselves."/>

The `dispatch` method we're exposing here will forward the action to the dispatcher, but after that, it will forward the data to `LogActions.log`. This method will then send the action to our back-end:

```javascript
import httpClient from '../httpClient';
import LoginStore from '../stores/LoginStore'

export default {
  log: (action) => {
    console.log('Action:', action);

    if (LoginStore.sessionId && !action.debug) {
      httpClient.post(null, { url: `/sessions/${LoginStore.sessionId}/logs`, data: action }).catch(err => {
        console.log('Error sending log:', err);
      });
    }
  }
};
```

The message will first be logged to the console. This could be something you want to activate for your non-production builds. Then, if the user is logged in and it's not a "debug action", the data is posted to the back-end.

When we replay actions in a troubleshooting session, we'll mark these as "debug actions" to make sure that these actions are not sent to the server again.

And that's basically it. Our backend will store all actions in a "session" in chronological order. Then a developer might choose to replay a session:

```javascript
debugSession: (session, untilAction) => {
  console.log('Debugging session:', session);

  dispatch({ debug: true, actionType: RESET });
  dispatch({ debug: true, actionType: START_DEBUG });

  // Replay all actions with a delay.
  for (var i = 0; i < session.actions.length; i++) {
    let action = session.actions[i];

    setTimeout(() => {
      console.log(' > Dispatching debug action:', action);
      dispatch({
        ...action,
        debug: true
      });
    }, i * 250);

    if (untilAction && untilAction === action) {
      break;
    }
  }

  dispatch({ debug: true, actionType: STOP_DEBUG });
}
```

When replaying a session, we'll first dispatch the `RESET` and the `START_DEBUG` actions. The `RESET` action can be handled by all stores to reset their state (clear all data, clear alerts, etc.).

The `START_DEBUG` action tells the rest of the applications that we are now going to replay certain actions. This is very important because one thing we'll want to avoid is our application making calls to the API. So our HttpClient will not be making calls during this time (in the next section, we'll explain how this works and how we're leveraging Flux to record every request and every response so we can replay everything later without requiring interaction with the API).

Then we go over each action and dispatch it, after which we introduce a small delay. As a result, the developer will see every action that is replayed (in fast-forward, as the delay is always 250ms). And finally, the `STOP_DEBUG` action is sent to notify that we're done replaying the actions, which re-enables the HttpClient.

## Improving our API calls

When Jane was debugging John's session, we immediately noticed a bug in one of our components, so this approach is good to catch runtime errors. But what about API calls? When replaying the actions, the HttpClient will not be making any calls to our API, so how can we effectively replay and troubleshoot API calls? Well, we'll just need to dispatch an action each time we want to make a request, each time we get a successful response, and each time the API returns an error.

Here's what this could look like when we're making the request:

```javascript
{
  actionType: 'LOAD_OPEN_TICKETS',
  user: 'sandrino',
  sort: 'date'
}
```

When the request is successfully executed, we can dispatch the result.

```javascript
{
  actionType: 'LOAD_OPEN_TICKETS_SUCCESS',
  tickets: [...]
}
```

And in the case that something goes wrong, we will also dispatch this action with the actual error message:

```javascript
{
  actionType: 'LOAD_OPEN_TICKETS_FAILED',
  err: {
   message: 'The user "sandrino" has been disabled. You cannot load tickets for this user.'
  }
}
```

Frameworks like `redux` support concepts like middleware, which make it much easier to implement this in a generic way, but we'll just create a wrapper around a library like `axios` or `superagent` that handles this for us:

```javascript
class HttpClient {

  get(action, options) {
    var request = superagent.get(`${BASE_URL}${options.url}`);
    if (options.query) {
      request = request.query(options.query);
    }

    return this._execute(action, request);
  }

  post(action, options) {
    var request = superagent.post(`${BASE_URL}${options.url}`);
    if (options.data) {
      request = request.send(options.data);
    }

    return this._execute(action, request);
  }

  _execute(action, request) {
    if (debug.isActive) {
      console.log('Debug mode active - not executing Http Request:', request);
      return;
    }

    return new Promise((resolve, reject) => {
      request.end((err, res) => {
        if (err) {
          dispatch({ actionType: action + '_FAILED', err: err });
          return reject(err);
        }

        dispatch({ actionType: action + '_SUCCESS', res: res });
        return resolve(res);
      });
    });
  }
}

export default new HttpClient();
```

This class will dispatch `YOUR_ACTION` before the call is made to the API. Then, it will dispatch `YOUR_ACTION_SUCCESS` when the request has been executed or `YOUR_ACTION_FAILED` in the event of an error. This means that every request and response is dispatched and also being logged to our back-end. Thus, we can easily replay all actions, including the data returned by possible API calls, without having to interact with the actual API. This is useful if you need to reproduce an issue that occurred a few days ago for which the data might no longer exist or might have changed.

## Trying it out

The complete source of this application is available on GitHub: [https://github.com/auth0/react-flux-debug-actions-sample](https://github.com/auth0/react-flux-debug-actions-sample). Follow the instructions here to start the front-end and the back-end.

Happy troubleshooting!


Logging &amp; Debugging in React with Flux: Replaying your user’s actions

I stream, blog, and make youtube videos about tech stuff. I love coding, I love AI, and I love building stuff!

Sandrino Di Mattia

Announcing the Auth0 Authorization v2 Extension!

Logging & Debugging in React with Flux: Replaying your user’s actions

The Ultimate Guide to Next.js Authentication with Auth0

Try for free today

Sandrino Di Mattia

Announcing the Auth0 Authorization v2 Extension!

Logging &amp; Debugging in React with Flux: Replaying your user’s actions

The Ultimate Guide to Next.js Authentication with Auth0

Try for free today

Logging & Debugging in React with Flux: Replaying your user’s actions