# Storing role in request user

We'll now see something quite interesting: our interface in action. Going back to the <mark style="color:blue;">`RequestUser`</mark> interface, let's indicate that it should also have the user's <mark style="color:blue;">`role`</mark>.

```typescript
readonly role: Role;
```

Immediately, we can see the <mark style="color:blue;">`AuthService`</mark> showing errors. This is because the variables that implement this interface are no longer fulfilling its contract. And this is exactly what was intended to happen, in order to be sure that everything is correctly adjusted due to the type safety. So, in both places that an error appeared, let's also return the user's <mark style="color:blue;">`role`</mark>.

```typescript
const requestUser: RequestUser = { id: user.id, role: user.role };
```

However, you may have noticed that we are repeating the same step in both validation methods. So, let's encapsulate this logic in an aux method. We may even set the return type of this method to be <mark style="color:blue;">`RequestUser`</mark>, maintaining type safety while no longer needing to create that variable.

```typescript
private createRequestUser(user: User): RequestUser {
  const { id, role } = user;
  return { id, role };
}
```

And now have, as return of the two validation methods, the call to this aux method.

```typescript
return this.createRequestUser(user);
```

Excellent! We're already storing the user's <mark style="color:blue;">`role`</mark> in the <mark style="color:blue;">`user`</mark> field of the <mark style="color:blue;">`request`</mark>. We can now focus on protecting the routes according to the users' permissions.

<mark style="color:green;">**Commit**</mark> - Storing role in request user
