-
-
Notifications
You must be signed in to change notification settings - Fork 510
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
Add support for authentication #830
Comments
I can see why this make sense for the django integration. When using a minimal framework like Flask, this might feel a bit unusual since Flask has no built in auth. Shipping a first-party |
I agree with @kristofgilicze I think an authentication integration makes sense with Django because it's provided by the framework. Maybe we can build something into the Django integration @la4de ? Something like that Sanic guide would be good for the other frameworks. |
I wonder though, if we build support for django, wouldn't be "easy" to make it pluggable and support multiple frameworks. The mutations and queries would be the same everywhere, no? The implementation would change, so maybe we can provide some hooks for that? |
We have preliminary support already in Current user is also accessible through https://github.com/strawberry-graphql/strawberry-graphql-django#django-authentication-examples Feel free to give feedback and share your ideas! |
@la4de that's awesome, so maybe we can keep this in strawberry-django and then when it is mature we can think of making more generic, what do you all think? |
core implementation should be reused between integrations. The django way to configure stuff is in the |
It's definitely different than django, but it allows to have multiple GraphQL views in one project (we do that at work for example). |
If you have multiple views, then I agree the 'global' setting does not make sense. I had a closer look at how DRF handles the auth classes. ... there is also an option to set it on a per-view basis. What I described before: see: |
I think that it should remain framework specific. There are too many things to cover, too many different frameworks and too many different approaches. While within the context of a framework for a specific auth method, its really simple, you can see here. I'd suggests to make it really simple for integrations (eg strawberry-graphql-django) and for users to:
|
@joeydebreuk but what about the mutations and queries? those won't change even if you use different frameworks (the internal implementation will, but not the way the mutations are used). I feel like there might be some opportunity for reusing code somehow :) even django has pluggable auth backends :) |
@patrick91 I feel like we had a similar discussion regarding adding framework specific code to strawberry. I suppose its a matter of philosophy and defining the scope of strawberry. I'm sure you can add some abstraction on the strawberry level, but I don't see how it would add a lot of value. Just more complexity. And more docs to write.
Already possible, and quite simple to do. Some documentation would help though.
Why should strawberry be are of user types?
These mutations are very simple, I don't see the point in doing this.
Defining these inputs and returns will be most of the code one would need for a mutation in the first place
Maybe its an idea to just provide a guide for each framework?
Django has everything though 😄 In short, I would say that adding a few guides for setting up strawberry for frameworks is better than adding framework-specific code to strawberry. |
Could be! It's just that I see auth something used a lot and quite critical (auth should be implemented well and should secure), so it would be nice if we can help with that as a framework. I'll see if I can come up with some examples of what I am thinking 😊 |
Weighing in here, I'm personally not at all interested in Django integrations so this discussion seems a bit too "heavyweight" for me. I'm providing a GraphQL alternative to a FastAPI endpoint, which is conceptually similar to people discussing Flask. I'd like to be able to share some code between the two, but currently I'm most interested in Strawberry providing tools like hooks, helpers, and mixins that would make Authentication easier. Ideally I would be free to define my own mutations and permissions on queries, but with some deeper strawberry integration. For example a solution to me might be for Strawberry to simply provide tools that work like the current Permission classes. Then make it my responsibility to provide login and signup mutations.
In this scenario the I'm not suggesting this be the exact implementation nor am I married to any particular approaches here. Just making suggestions that may be simpler right now as a way to progress this ticket without thinking about Django. Edit: While I've written these at the class level, they may make more sense at the resolver level (the way permissions work). Or potentially at both, depending on whether you want global permission requirements. |
It would be great if strawberry would be able to use something like FastAPI's For example see This way is super comfortable to use! (after you go to the links above, you can click on those method names to see how they are defined in this project) Maybe this information will be helpful in implementing it (but it is about graphene): |
@karolzlot I personally like the dependency injection API that FastAPI has and I'd like to see something similar implemented in Strawberry. It's unlikely that we would be able to use FastAPI dependencies directly though because it's quite paradigm. For example in the |
I think it could be something like this: Inside project insead of
which differ by how they raise errors They could inherit from one class or inherit from one another. But I don't know Strawberry enough to be sure that this approach is good. |
Is there a way to use logical operators in strawberry permissions classes like: |
Is there any advance on this topic? I'm seeking a practical solution to validate a third-party token on FastAPI+Strawberry. |
is there any update on this topic? Some of the implementations mentioned above would be very useful |
@elefher what implementations would like to see the most? |
I've opened a discussion on this, but I think it might be worth making an issue related to authentication.
I'd say we can split this work into multiple chunks, but let's think about what we want in ideal world.
[1] JWT with cookies, JWT in header, plain cookies for sessions (basic django auth)
[2] we shouldn't force users to use our preferred way of error handling
All of the above is up for discussion by the way :) haven't really found any other library that do authentication built-in. For Graphene we have these two:
Upvote & Fund
The text was updated successfully, but these errors were encountered: