You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Lovely gem you have here - thanks for the work and support!
We're wondering if there's a means to hook into every association/include configuration across the app; we poked through the issues and PRs, and a bit through the code, and didn't see anything like that.
Some more context:
We're using the serializers for a variety of ActiveNode models, and we're in-process on adding an authorization layer. We do that by scoping requests for the models with an accessible_to(current_user) filter, e.g.,
classSomeModelscope:accessible_to,lambda{ |current_user|
# ... whatever logic needed scope the query to what the user can see ...}end
For direct access to these models, the serializers are just fine - we scope it before we call Serializer.serialize. However, this doesn't work when handling included associations, but we still need to restrict the queries.
We know we can use context to pass in the current_user from our controllers, and a serializer like the below in order scope the request to authorized models...
But, naturally, this is something that we'd like to scope for everyhas_many or has_one. Like suggested in #105, we could add a helper method that we reference for all of our has_many/one configurations, like
classSomeModelSerializer# updated to streamlineincludeJSONAPI::Serializerhas_many:other_models, &:scope_to_current_userend
But even that requires calling it out over and over again in the serializers with every association... we'd like to avoid that: we want the "default" for serializers to be the secure approach of limited access by user.
We're wondering if it would make sense to add global hooks we could use for includes with cross-cutting concerns like this. Something like an on_include hook that would fire whenever an include is used, passing in the object being serialized, the association name, context, etc...
We're happy to do a PR for this if it makes sense to do so, but we wanted to vet the idea first. Does this make sense / would it be valuable? Are there already-existing mechanisms for something like this that we overlooked?
Thanks!
The text was updated successfully, but these errors were encountered:
Lovely gem you have here - thanks for the work and support!
We're wondering if there's a means to hook into every association/
include
configuration across the app; we poked through the issues and PRs, and a bit through the code, and didn't see anything like that.Some more context:
We're using the serializers for a variety of ActiveNode models, and we're in-process on adding an authorization layer. We do that by scoping requests for the models with an
accessible_to(current_user)
filter, e.g.,For direct access to these models, the serializers are just fine - we scope it before we call
Serializer.serialize
. However, this doesn't work when handlingincluded
associations, but we still need to restrict the queries.We know we can use
context
to pass in thecurrent_user
from our controllers, and a serializer like the below in order scope the request to authorized models...But, naturally, this is something that we'd like to scope for every
has_many
orhas_one
. Like suggested in #105, we could add a helper method that we reference for all of ourhas_many/one
configurations, likeBut even that requires calling it out over and over again in the serializers with every association... we'd like to avoid that: we want the "default" for serializers to be the secure approach of limited access by user.
We're wondering if it would make sense to add global hooks we could use for includes with cross-cutting concerns like this. Something like an
on_include
hook that would fire whenever an include is used, passing in theobject
being serialized, the association name,context
, etc...We're happy to do a PR for this if it makes sense to do so, but we wanted to vet the idea first. Does this make sense / would it be valuable? Are there already-existing mechanisms for something like this that we overlooked?
Thanks!
The text was updated successfully, but these errors were encountered: