Serialization of a DTO with user.role in request.

[lone garnet]

The DTO I have looks like this:

export class UpdateUserDto {
  @IsOptional()
  @IsString({ message: MESSAGES.IS_INVALID })
  @Length(3, 20, { message: MESSAGES.LENGTH })
  username?: string;

  @IsOptional()
  @IsEnum(Role, { message: MESSAGES.IS_INVALID })
  role?: Role;

  @IsOptional()
  @IsString({ message: MESSAGES.IS_INVALID })
  @Length(3, 20, { message: MESSAGES.LENGTH })
  firstName?: string;

  @IsOptional()
  @IsString({ message: MESSAGES.IS_INVALID })
  @Length(4, 40, { message: MESSAGES.LENGTH })
  lastName?: string;
}

My goal is to serialize the DTO based on the role of the user.
For example:
The user logged in as an admin, can send the role parameter in the request body, otherwise he cannot.
I tried @Expose, but it didn't work. (I don't have access to the user.role in the request)
How can I do this?

[left cargo]

why do you not have access to request?
to start with

[lone garnet]

how can i access to request in @Expose decorator?

[left cargo]

that's the neat part, you dont
in fact when i was looking at the class-transformer docs it doesn't seem to be conditionally at all
you expose a key to the dto or not

but decorators are just functions you can just write your own

you can just return the Expose() in this custom decorator

something i didn't know either
they are actually pretty simple
a custom class validator is actuelly more pain to write
then a class-decorator one

does that anser your question? or need some help?

[lethal jay]

I would recommend creating a custom validator and inject the request object like so:

class CustomValidator implements ValidatorConstraintInterface {
  constructor(@Req() private req: Request) {}

  validate(value: string): boolean {
// if role is not admin and a value is passed for role
// then return false, otherwise true
    if (this.req['user'].role !== 'ADMIN' && value) {
      return false;
    }
    return true;
  }

  defaultMessage?(validationArguments?: ValidationArguments): string {
    return 'Invalid request';
  }
}

Then use that custom validator in your dto on top of the role property:

@IsOptional()
@IsEnum(Role, { message: MESSAGES.IS_INVALID })
@Validate(CustomValidator)
role?: Role;

As we can utilize dependency injection in the custom validator, you have access to the request object

I've never done that myself to be honest but if it doesn't work, just let us know

[left cargo]

there are more ways to skin a cat

• you can write a custom class-validator decorator
• a custom class-transformer
  or even something else then a decorator
  like a guard could work

[left cargo]

it is a option but i would't be this detailed with response message
for somebody who is trying to mess with the system
just throw a forbidden is better here

[lethal jay]

Of course it's just preference. I just wanted to show another way that allows him to utilize request object in dto

Also returning false inside validate method will return 400. It might be better to throw forbidden exception

[left cargo]

it isn't prefrence
api responses should be kept vuage for security reason
you dont want to arm a attacker with new info

you're now just telling them they need admin for the access
so they are prob going to fish a admin account or something

[lethal jay]

I dont think throwing 400 or 403 with a simple error message is that bad of a security issue but okay. I wanted to make a point that this is an available option

They wont be able to guess admin accounts just with 403 because it'll be thrown when there's no token with role propery attached to the request object. API response just tells the user they are not able to proceed just because they are not an admin user. That gives you no indication as to who might be an admin user

[lethal jay]

And even if they forge the token to get a correct admin user in token body, token validation will still fail as the attacker wont know the secret key to sign the token. There's simply no way to get any confidential information in this scenario in my understanding

And just telling user they need admin access is also not a security issue. Attackers will always try to target admin accounts. Whether you return 403 or not. Just returning 403 without disclosing confidential information is a practice I see in a lot of projects at my work

[left cargo]

it is standard to not give them such info
forging is indeed not really possible
but they will prob search for a admin and do some phishing to gain access
if they get the mail and password they're in
or steal they cookie or something

you basicly tell the attackers that they need to go after a admin or something
dont tell what they did wrong dont acknowledge that role can be send as part of the body, it's better to reject them on everything they send in the body that isn't right

treat all fields the same, if 1 unknown field is send, block them
if 1 field is send they dont have right to, block them

[lethal jay]

Actually yes we can just remove that error message

Let me modify it

Thanks for the correction

[left cargo]

security is as important
you dont have to tell a attacker what they did wrong
just that they did something wrong
i rarely put any response messages in
only when a user might mess something up

like when they typed a activation code that isn't valid
even something small as this makes a difference 😉

[lethal jay]

You're right. I think creating a constants.ts file for error messages would be also a great practice for that purpose

[lone garnet]

Would you be able to give an example?

[lone garnet]

Using the validator will send the error to the client, which I don't want.
It is just necessary to remove that value from the request body if the user is not an admin. (Should be ignored)

[lone garnet]

This custom class-transformer seems to be the best way, but I don't know how to write it?
Unfortunately, I was unable to find anything when I searched

[lethal jay]

I see what you mean

I'd do something like

delete dtoObject.role

Just delete it manually from the object inside your service or controller class. But if you want to do it from DTO using class-transformer, unfortunately I dont know any way to do that

Or you can write an interceptor

[left cargo]

yeah it isn't easy to find any references
but if you need a example

function myExpose(condition: boolean, options?: ClassTransformOptions): PropertyDecorator {
  return (target: any, key: string) => {
    if(condition) {
      Expose(options)(target, key)
    }
  }
}

class MyClass {
  @myExpose(true, { someOption: 'value' })
  myProperty: string;
}

should do it

[lethal jay]

That's a cool solution. What I had in mind was something like that (for interceptor solution):

class CustomInterceotor implements NestInterceptor {
  intercept(
    context: ExecutionContext,
    next: CallHandler<any>,
  ): Observable<any> | Promise<Observable<any>> {
    const request = context.switchToHttp().getRequest<Request>();
    if (request['user'].role !== 'ADMIN' && request.body['role']) {
      delete request.body['role'];
    }
    return next.handle();
  }
}

That way you delete the role propery from the request body in case user is not an admin and just continue on executing the controller with that request

And then use

@UseInterceptors(CustomInterceotor)
someControllerMethod()

Idk if that's a good fix @lone garnet

Let me know if that works out for you

Or even create a custom decorator

const CheckRole = () => @UseInterceptors(CustomInterceotor);

[lone garnet]

I want to handle this using DTO.
in fact that there are many routes shared between admin and user and the data is different, so this solution not good for me.

[lethal jay]

This solution will work whenever DTO contains a field called role. However, if the propery name is different for other DTOs yes it may not work

[lethal jay]

This one looks promising tho. I'd give it a try

[lone garnet]

how can access request in myExpose function?

[left cargo]

i would rather validate then transform, if you where to ask me, feels more secure
if anything fishy is going trough i just forbid it

transforming can be brute forced and then checking what got removed and what didn't
it is up to you to get the user role passed
can't chew your food for you after all 😉

[lethal jay]

Btw something else just came to my mind @lone garnet

class CustomInterceptor implements NestInterceptor {
  constructor(private dtoProperyName: string | symbol) {}

  intercept(
    context: ExecutionContext,
    next: CallHandler<any>,
  ): Observable<any> | Promise<Observable<any>> {
    const request = context.switchToHttp().getRequest<Request>();
    if (request['user'].role !== 'ADMIN' && request.body[this.dtoProperyName]) {
      delete request.body['role'];
    }
    return next.handle();
  }
}

By using the above approach, you can parameterize the propery name so it's applicable to any route handler. Like this:

@UseInterceptors(new CustomInterceptor('role'))
someRouteHandler() {...}

By replacing 'role' with another property name, you dynamically use it for any dto