-
Notifications
You must be signed in to change notification settings - Fork 491
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
Comments
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. |
@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. |
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. |
@m110 Thanks for the quick and thorough response! Your social media example makes sense and I now understand where you were coming from. |
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).The text was updated successfully, but these errors were encountered: