-
-
Notifications
You must be signed in to change notification settings - Fork 12
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
Context based validation or modification #46
Comments
The current design idea here is as following: You either want something simple that just works, or you want to do something custom. The first option is implemented via For the general story: Corresponding traits are available for update and delete mutations. For queries the story is a bit more complex. One the one hand there is That all writing I think it could be a useful addition to have something like |
Thanks for all of the information, I didn't realize I could just implement As for a more general solution, I'm not sure that I have any particular ideas at the moment. I do agree though that it'd be nice to have a generic way to implement this logic across mutation types. |
So the documentation on this topic certainly needs to be improved. If you have any suggestions where this could be mentioned feel free to share them here. |
I wouldn't mind contributing to the example project or adding an authorization example to the readme when/if I get this working. I've been playing around with
Since Thanks! |
I do not have an example for that available in public somewhere, but the basic idea is to do that by providing specialiced impls based on the generic paramater |
That's very similar to what I was trying before, but I end up with a trait error:
Simplified example:
I'm guessing something is going wrong with resolving the implementation due to the explicitly defined context type? Thanks! |
As you are using a concrete connection type there you should also use a concrete type for the diesel backend in place of Something like this should work: impl QueryModifier<models::Post, diesel::pg::Pg> for Context<diesel::PgConnection>
{
fn modify_query<'a>(
&self,
_select: &LookAheadSelection<'_, WundergraphScalarValue>,
query: BoxedQuery<'a, models::Post, diesel::pg::Pg, Self>,
) -> wundergraph::error::Result<BoxedQuery<'a, models::Post, diesel::pg::Pg, Self>> {
Ok(query)
}
} |
Oh yep, should have specified that. I've got it working now, thanks! Let me play around with this a bit and I'd be happy to provide some updated documentation for this sort of stuff if you'd like. |
I've been playing around with wundergraph for a bit and I'm really liking it, but I'm a bit stuck on devising a method of operation authorization. I'd ideally like to be able to inspect instantiated models prior to inserting or updating and either allow the update, or, reject the update in consideration of the context.
I've been poking around in the source and it doesn't seem like there's any straight forward way to do this at the moment. I think(?) the easiest way of doing something like this might be to allow the implementation of a trait like:
In the case of inserting, it seems like this could probably be checked in the
handle_insert
call prior to actually asking Diesel to insert.I'd also like something for reading/deleting, but I think the easiest cases to start with are probably insert/update. If this seems like something that you'd be interested in having Wundergraph support, I'd be happy to take a crack at implementing this. If I can already do this somehow and I'm missing it, I'd love to hear.
Thanks!
The text was updated successfully, but these errors were encountered: