Should there be a default user register mutation?

[neolight1010]

I noticed there's auth mutations for login and logout, but there doesn't seem to be any to register a new user. I think there should be a register mutation that performs a django validate_password, and let the developer choose between the usual create mutation and the register one.

[la4de]

Thanks for reporting this interesting idea. This is good question.

User registration is a bit more complex operation. Registration field may have various number of fields. Registration also typically needs some kind of activation. What do you think? What would the register mutation provide and how the activation would be handled?

We should also discuss as a team that where we would like to draw the line. Which features are implemented into strawberry and which are left out. We need to find out which features we want to focus on.

Feel free to leave any comments :)

[neolight1010]

My idea is that the register mutation should create a user with its is_active field set to False as default, so activation can be handled separately by the developer. It would perform Django's validate_password function so no user with a weak password can be saved in the database (at least through the register mutation). It would be a nice shortcut and variation of the create mutation.

Regarding the multiple registration fields, I haven't come up with any other solution than letting the developer manually create a User strawberry type.

[pogorsky]

I saw some attempts to implement JSON Web Token (JWT) authentication for Django Strawberry GraphQL, for example, https://github.com/KundaPanda/strawberry-django-jwt. Any guidance or suggestions on utilising this approach?

[la4de]

My idea is that the register mutation should create a user with its is_active field set to False as default, so activation can be handled separately by the developer. It would perform Django's validate_password function so no user with a weak password can be saved in the database (at least through the register mutation). It would be a nice shortcut and variation of the create mutation.

Regarding the multiple registration fields, I haven't come up with any other solution than letting the developer manually create a User strawberry type.

Technically this would work well. I'd like to hear your and other's opinions whether should we have login, logout, registration, password reset and other auth related mutations as an example and add sample code to the documentation or implement and push them to the project.

[la4de]

I saw some attempts to implement JSON Web Token (JWT) authentication for Django Strawberry GraphQL, for example, https://github.com/KundaPanda/strawberry-django-jwt. Any guidance or suggestions on utilising this approach?

Nice to see that community is evolving. :)

I haven't tried that library. I think it would be good to have generic jwt solution which would work well with both plain strawberry and strawberry-django.

[neolight1010]

Technically this would work well. I'd like to hear your and other's opinions whether should we have login, logout, registration, password reset and other auth related mutations as an example and add sample code to the documentation or implement and push them to the project.

Making mutations for registering users and logging in and out are something I do pretty much every time I start a new project, so having them as a shortcut would be nice. I think it also makes sense having them implemented, as strawberry_django already has some of these "shortcuts", like the create mutation.

[la4de]

Making mutations for registering users and logging in and out are something I do pretty much every time I start a new project, so having them as a shortcut would be nice. I think it also makes sense having them implemented, as strawberry_django already has some of these "shortcuts", like the create mutation.

Makes sense. We can add signup/register mutation. Would you like to contribute the project? :)

[neolight1010]

Makes sense. We can add signup/register mutation. Would you like to contribute the project? :)

Of course! I would love to! <3

[kwongtn]

I think this PR can now be closed since https://github.com/strawberry-graphql/strawberry-graphql-django/pull/45 has now been merged 🤔 @bellini666

[bellini666]

I think this PR can now be closed since #45 has now been merged thinking @bellini666

As far as I can tell, you are right. Closing it!