I saw a few problems with how we handle settings in Djoser. And decided to try solve some of them.

• settings.get("SEND_ACTIVATION_EMAIL") is cumbersome interface and it is used a lot across the code. We should look for more clear and simpler way. Thats why I decided to use config.SEND_ACTIVATION_EMAIL somewhat resembling how Django does.
• merge_settings_dicts was invoked every time an setting value is looked up. This is not optimal. Additionaly djoser settings aren't so complex so why to use this recursive function? I removed it and replaced with simple approach: instantiate default djoser settings and override anything that user customized in django settings.

There is some work to do but i want to show this idea for consideration.

As a DRF newbie, using djoser, but also wanting to use session auth, as my application is only browser based, I wonder why session auth is not supported by djoser, as seen here: https://djoser.readthedocs.io/en/latest/getting_started.html#supported-authentication-backends

Then according to #320, I found the CREATE_SESSION_ON_LOGIN setting, that seems undocumented? I would gently help to improve docs, but I am wondering what exactly the current state with session auth is?

This PR essentialy rename View.action into View._action because View.action is a reserved attribute of DRF.

https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/request.py#L56

This change is potentially backward incompatible, as such, a changelog entry should explain the steps and/or published with a major version bump (at the appreciation of the maintainers).

fixes #171

This provides the option of using email instead of username for auth. It works nicely with auth packages such as django-allauth, which provides an email authentication backend.

Error while calling /users/me/ endpoint with no/wrong auth.

Code in question: https://github.com/sunscrapers/djoser/blob/35e5a5e75127d7270ab8f7bb13c4f7d0c0ec5a7b/djoser/views.py#L52 Code that calls it (from django-rest-framework): https://github.com/encode/django-rest-framework/blob/be87eb43b348f1f079de81329218b79814b97173/rest_framework/views.py#L333 Change that added the code parameter: https://github.com/encode/django-rest-framework/pull/7306

The only other issue I found about this was self closed: #538

Full trace:

Internal Server Error: /auth/users/me/
Traceback (most recent call last):
  File "C:\Users\Bor\AppData\Local\Programs\Python\Python38\lib\site-packages\django\core\handlers\exception.py", line 47, in inner
    response = get_response(request)
  File "C:\Users\Bor\AppData\Local\Programs\Python\Python38\lib\site-packages\django\core\handlers\base.py", line 179, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "C:\Users\Bor\AppData\Local\Programs\Python\Python38\lib\site-packages\django\views\decorators\csrf.py", line 54, in wrapped_view
    return view_func(*args, **kwargs)
  File "C:\Users\Bor\AppData\Local\Programs\Python\Python38\lib\site-packages\rest_framework\viewsets.py", line 125, in view
    return self.dispatch(request, *args, **kwargs)
  File "C:\Users\Bor\AppData\Local\Programs\Python\Python38\lib\site-packages\rest_framework\views.py", line 509, in dispatch
    response = self.handle_exception(exc)
  File "C:\Users\Bor\AppData\Local\Programs\Python\Python38\lib\site-packages\rest_framework\views.py", line 469, in handle_exception
    self.raise_uncaught_exception(exc)
  File "C:\Users\Bor\AppData\Local\Programs\Python\Python38\lib\site-packages\rest_framework\views.py", line 480, in raise_uncaught_exception
    raise exc
  File "C:\Users\Bor\AppData\Local\Programs\Python\Python38\lib\site-packages\rest_framework\views.py", line 497, in dispatch
    self.initial(request, *args, **kwargs)
  File "C:\Users\Bor\AppData\Local\Programs\Python\Python38\lib\site-packages\rest_framework\views.py", line 415, in initial
    self.check_permissions(request)
  File "C:\Users\Bor\AppData\Local\Programs\Python\Python38\lib\site-packages\rest_framework\views.py", line 333, in check_permissions
    self.permission_denied(
TypeError: permission_denied() got an unexpected keyword argument 'code'

Hi, in this kinda RFC issue I'd like to propose a respository name change. There are quite few reasons to do so:

1. People have a hard time searching and finding our project, because the name is kinda out of this world (https://en.wikipedia.org/wiki/Djoser)
2. The name is short, however it might not be the easiest one to remember.
3. SEO is almost non-existent and it would take a great effort to improve it.
4. For some time it was not being actively maintained and it might have brought a bad reputation.

At the moment I do not have a proposition for a new name. First thing I'd like to do is to find out what everyone is thinking about the idea.

AttributeError at /auth/register
'UserRegistrationSerializer' object has no attribute 'init_data'

I was trying to create a new user by issuing a POST request to /auth/register. Exception location is at djoser/djoser/serializers.py in save, line 34

Here are my package versions -

Django==1.7.1
djangorestframework==3.0.0
djoser==0.1.0

Can you tell me why this is happenning?

I install Djoser with JWT. I am able to activate the user with the Postman. When I send a POST request to this url: /auth/jwt/create/ I get this message from postman: "detail": "No active account found with the given credentials".

I was running into a similar (or same) issue as described here https://github.com/sunscrapers/djoser/issues/546. I had SEND_ACTIVATION_EMAIL=True and was updating a user's information that wasn't the email (i.e. first_name, last_name, etc). This resulted in sending an activation email, which doesn't really make sense since the email isn't being updated.

• Update user only sends email confirmation if email field was updated
  • Updating fields other than the email result in NOT sending an activation email
• Keeps functionality of SEND_ACTIVATION_EMAIL
• All tests passed

Didn't work out sanitization for dictionary, because LoginSerializer doesn't provide dictionary. Could go around, but decided to create sanitization for string argument. Included sanitization in 3 classes: UserRegistrationSerializer, LoginSerializer and SetUsernameSerializer. Created 3 tests for each use case - similar to primary tests. Created list of 2 test sanitizers: uppercase and trim3, to check if works for list of sanitizers.

Hi. Thanks for the djoser. I like it as it makes life easier unlike other packages.

There is one thing I have come across. I'd suggest to change a feedback message for a non-active user who tries to obtain jwt, because now it returns the following:

{
    "non_field_errors": [
        "Unable to log in with provided credentials."
    ]
}

How can I detect if user tried wrong credentials or user has not just activated his account yet?

Who needs this change would need to overwrite some structure like view or serialize? Or can we add through some parameter?

REF: https://stackoverflow.com/questions/71628282/add-expire-time-for-validation-and-verification-in-djoser

CurrentUserOrAdminOrReadOnly class was inherited from permissions.IsAuthenticated and didn't provide access to the list for unauthentificated user. Method "has permission" particularly restricts this request from unauthentificated user. ( I would like to suggest to inherite CurrentUserOrAdminOrReadOnly from IsAuthenticatedOrReadOnly) BR Maxim

It was written 'rest_framework.permissions.CurrentUserOrAdmin'. I suppose it is 'djoser.permissions.CurrentUserOrAdmin', because it is a special permission and there is no such one in rest_framework. BR Maxim

Bumps certifi from 2021.10.8 to 2022.12.7.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

When setting "CREATE_SESSION_ON_LOGIN" is on, the signal "user_logged_in" is being sent duplicate, because function login (called in the line 19) already send this signal (/django/contrib/auth/init.py line 125).

We have the same situation for logout, function logout (called in the line 29) already send the user_logged_out signal.