feat: authentication should be reflected into children controller about tsed

[EinfachHans]

Alright, didn't found an request for that 🤔

because you don’t want auth a specific sub endpoint it won’t be possible to do that

That's right, but imo defining the Auth to the parent controller would be wrong anyways then

This feature become a nightmare for me compared to just adding the decorator at the right place for dev

Okay, i understand this, maybe just let this feature request open and label it with "help wanted" if someone wants to tackle this in the future?

In general i would say it would be the expected behaviour

[Romakita]

Maybe the problem is just related to the useBefore behavior on class. I have to re read the code because isn’t maybe clear for me ^^. I’ll keep this issue open, because your not the firt dev that ask me for that!

[Romakita]

Hello @EinfachHans

I already answered this question. I’m not favorable of this feature. It’s preferable to define over each method (or controller) the authentication strategy. because you don’t want auth a specific sub endpoint it won’t be possible to do that. Adding also the complexity to apply correctly the middleware for each controler and children controler, and this feature become a nightmare for me compared to just adding the decorator at the right place for dev.

See you

[Romakita]

Ok after investigation I found the reason why it's not possible.

The problem is here:
https://github.com/tsedio/tsed/blob/production/packages/platform/platform-middlewares/src/decorators/useAuth.ts#L49

Actually to apply auth middleware on inherited method, I have to use decorateMethodsOf utils. This function create a proxy method with the appropriate metadata instead of adding it over base class, for example:

class CrudController {
   @Get('/:id')
    get() {}

    @Get('/')
    getList() {}
   // etc...
}

@Controller("/users")
@UseAuth(MyAuthMiddleware)
class UsersController extends CrudController {
     @Get('/:id')
     getRoles() {}
}

@Controller("/public-data")
class PublicDataController extends CrudController {
     @Get('/:id')
     getOwners()
}

In this example, we want to apply AuthMiddleware only on UsersController. Without decorateMethodsOf, typescript add metadata on all methods including over CrudController methods. By side effect, the inherited PublicDataController methods (get/getList) has also impacted by the AuthMiddleware. (see #1535).
decorateMethodsOf solve this problem by monkey patching the child class (it add get and getList method).

The solution could be to use the Use decorator on class instead UseBefore. BUT isn't possible because for some usecase, we need to override the Auth options on some method using the @AuthOptions decorator.

@Controller("/users")
@UseAuth(MyAuthMiddleware, {scope: 'read write'})
class UsersController extends CrudController {
     @Get('/:id')
     @AuthOptions({scope: 'admin'})
     getRoles() {}

     @Get('/:id/other')
     other() {}
}

In this case:

• proxy method get has read write scopes
• proxy method getList has read write scopes
• method getRoles has admin scope
• method other has read write scopes

Now you have the overview of the actual implementation and you must see why the subject is complex ^^

I think the problem is currently with the decorator implementation. he has too much responsibility. we would just have to store the information from the auth middleware and apply it correctly when constructing the routes.

Here is the schema of the middleware call sequence:

See you ;)

[Romakita]

Note: UseAuth is a kind of UseBeforeEach

[EinfachHans]

Good morning @Romakita ,

thanks for the explanation. In my case i don't extend controller classes, i use the children option of the @Controller decorator.

I understand that extending the controller brings problems with it, in your example above the CrudController methods should be protected within the UsersController, but not in the PublicDataController - i see the problem with this.

But do we have the same problem with the children option? 🤔

[Romakita]

But do we have the same problem with the children option? 🤔

Yes the same mechanism should be propagated to children because it will be one of the first things asked by the devs (class inheritance support).