-
-
Notifications
You must be signed in to change notification settings - Fork 285
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
feat: authentication should be reflected into children controller #2525
Comments
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 |
Alright, didn't found an request for that 🤔
That's right, but imo defining the Auth to the parent controller would be wrong anyways then
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 |
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! |
Ok after investigation I found the reason why it's not possible. The problem is here: Actually to apply auth middleware on inherited method, I have to use 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). 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 @Controller("/users")
@UseAuth(MyAuthMiddleware, {scope: 'read write'})
class UsersController extends CrudController {
@Get('/:id')
@AuthOptions({scope: 'admin'})
getRoles() {}
@Get('/:id/other')
other() {}
} In this case:
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 ;) |
Note: UseAuth is a kind of UseBeforeEach |
Good morning @Romakita , thanks for the explanation. In my case i don't extend controller classes, i use the I understand that extending the controller brings problems with it, in your example above the But do we have the same problem with the |
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). |
Here is an example of how to forward a decorator to each nested controller: Isn't recursive but it could be possible to implement that by consuming the metadata. |
@EinfachHans it should solve your issue :) |
@Romakita can't open the links, is the repo private maybe? |
@EinfachHans Fixed ^^ |
Is your feature request related to a problem? Please describe.
When i declare a controller like
i would expect the Authentication to be reflected to the children controller as well 🤔
Describe the solution you'd like
No response
Describe alternatives you've considered
No response
Additional context
No response
Acceptance criteria
No response
The text was updated successfully, but these errors were encountered: