Skip to content
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

Authorization in repository? #51

Open
munknex opened this issue Apr 12, 2022 · 4 comments
Open

Authorization in repository? #51

munknex opened this issue Apr 12, 2022 · 4 comments

Comments

@munknex
Copy link

munknex commented Apr 12, 2022

Thanks for your work!

Why repositories do calls such as training.CanUserSeeTraining? Looks like domain logic. We need to test it in all repository implementations instead of testing once on domain (or maybe application level).

@m110
Copy link
Member

m110 commented Apr 24, 2022

Hey @munknex! This concept is explained in Robert's post: https://threedots.tech/post/repository-secure-by-design/

The code itself comes from the domain layer. However, checking permissions for each query would add an orchestration boilerplate in the application layer and would be very slow. So it's a trade-off to have the repository call it.

@iwittkau
Copy link

@m110 I don't quite understand what the overhead and slowdown would be if you put it in the application layer. It seems more logical to me to put the required permission checking for commands and queries close to their implementation, especially if you're using different repository implementations.

@m110
Copy link
Member

m110 commented Sep 18, 2023

Hey @iwittkau. I probably went too far with the "very slow" part. 😅 The point was that each query would need another SQL query (or queries) before the command is run. In retrospect, at least initially, performance is not a valid concern. Just something to keep in mind that you usually will need more queries this way.

The application layer is definitely a valid place for authorization if it's easy enough to understand who can access a resource. I described how to do it with decorators in this post: https://threedots.tech/post/increasing-cohesion-in-go-with-generic-decorators/ - this has the added benefit that the same command can be running with and without authorization, depending on where you call it from.

Keeping this logic in the repository shines for queries when checking permissions isn't as simple as comparing one user ID. For example, consider a social app where users can block each other, which should hide all posts for the blocked user. Doing such checks on the repository level means you don't need to be concerned about who uses the repository because the permissions model works everywhere.

@iwittkau
Copy link

@m110 Thanks for the quick and thorough response! Your social media example makes sense and I now understand where you were coming from.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants