Re: Custom user model password is not hashed

[Tejas Agrawal]

Hey Benjamin, can you please share your github repo for the same code. I'm 
also getting the same error in one of my project, can't figure out how to 
solve it.

On Friday, November 13, 2015 at 6:11:09 PM UTC+5:30 benjamin...@gmail.com 
wrote:

> The problem was, when creating a custom user, one has to define a custom 
> model form and model admin that handles the password properly. After that 
> it was solved.
>
> Thank you.
>
> On Thu, Nov 12, 2015 at 9:25 PM, Andreas Kuhne  
> wrote:
>
>> Try to debug and check what your password value is after the 
>> set_password() statement.  Also have you checked the database after trying 
>> to create a user with the new method? It should be hashed in the database. 
>> This is stuff that should "just work" in django (it's regulated by the 
>> AbstractBaseUser and is the same that I am using in a project).
>>
>> You did restart the django shell after changing the code?
>>
>> 2015-11-12 16:44 GMT+01:00 Benjamin Smith :
>>
>>> I have changed user.set_password(self.cleaned_data["password"]) to 
>>> user.set_password(password). 
>>> But I am getting the same result.
>>>
>>> On Thu, Nov 12, 2015 at 8:57 PM, Andreas Kuhne  
>>> wrote:
>>>
 As aRkadeFR says, you seam to have mixed code there

 The row:
 user.set_password(self.cleaned_data["password"])

 is taken from a form somewhere and won't work. It should instead be : 
 user.set_password(password)

 I suppose the password is going through to the create method via the 
 kwargs argument at the end of you create method. But if you change like I 
 said, everything should work.


 Med vänliga hälsningar,

 Andréas Kühne
 Software Development Manager
 Suitopia Scandinavia AB

 2015-11-12 16:20 GMT+01:00 aRkadeFR :

> Hello,
>
> I don't quite get the code in your method: '
> MyUserManager.create_user':
> user.set_password(self.cleaned_data["password"])
>
> You're in your Manager method but call self.cleaned_data ?
>
> You can set a breakpoint inside your method with pdb to see
> what's going on with your fields?
>
>
> On 11/12/2015 04:11 PM, Benjamin Smith wrote:
>
> I have my own custom User model, and its own Manger too.
>
> Models:
>
> class MyUser(AbstractBaseUser, PermissionsMixin):
> email = models.EmailField(max_length=255, unique=True)
> first_name = models.CharField(max_length=35)
> last_name = models.CharField(max_length=35)
> username = models.CharField(max_length=70, unique=True)
> date_of_birth = models.DateField()
> is_active = models.BooleanField(default=True)
> is_admin = models.BooleanField(default=False)
>
> @property
> def is_staff(self):
> return self.is_admin
>
> def get_full_name(self):
> return ('%s %s') % (self.first_name, self.last_name)
>
> def get_short_name(self):
> return self.username
>
> objects = MyUserManager()
> USERNAME_FIELD = 'email'
> REQUIRED_FIELDS = ['first_name', 'last_name', 'username', 
> 'date_of_birth']
>
>
> Manager:
>
> class MyUserManager(BaseUserManager):
> def create_user(self, email, first_name, last_name, username, 
> date_of_birth, password=None, **kwargs):
> if not email:
> raise ValueError('User must have an email address')
>
> user = self.model(
> email=self.normalize_email(email),
> first_name=first_name,
> last_name=last_name,
> username=username,
> date_of_birth=date_of_birth,
> **kwargs
> )
> user.set_password(self.cleaned_data["password"])
> user.save(using=self._db)
> return user
>
> def create_superuser(self, email, first_name, last_name, username, 
> date_of_birth, password, **kwargs):
> user = self.create_user(
> email,
> first_name=first_name,
> last_name=last_name,
> username=username,
> date_of_birth=date_of_birth,
> password=password,
> is_superuser=True,
> **kwargs
> )
> user.is_admin = True
> user.save(using=self._db)
> return user
>
>
> Everything works when creating a new user without any errors. But when 
> I try to login I can't. So I checked the user's email and password to 
> confirm. Then I noticed that the password is displayed as plain text (eg. 
> *strongpassword)*, and when changed the admin form to get the hashed 
> password using *ReadOnlyPasswordHashField()* I get an error inside 
> the password field, even though I used *set_password()* for the 
> Manger 

Images

[Aliya Janmohamed]

Hello, 

I cannot load my images, this is what shows:


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/2dc9f275-adcf-4a03-b8ed-db4aad8dfbc6n%40googlegroups.com.

Re: Django 3.0 -> 3.1 performance degradation

[Jason]

also would be helpful if you could give some examples.  All that is stated 
is "there's a significant slowdown", but nothing where or if there's been 
any tracing in place.  

Is this happening with db queries?  
serializing? 
rendering? 
are you using old packages which might have open/closed issues about 
performance?

On Friday, May 6, 2022 at 5:03:33 PM UTC-4 Jonatan Heyman wrote:

> Hi! And thanks for the reply!
>
> I've read the release notes but couldn't see anything that popped out as 
> the possible cause. But I'm going to give them another read. Currently, the 
> app is running fine on 3.0, and I haven't started debugging what might be 
> the cause. I started with a message to this list, hoping that this would 
> sound familiar to someone else :).
>
> Bisecting between 3.0 and 3.1 is a possibility, though it's time-consuming 
> since I have to rebuild the Docker image, deploy it to the staging server 
> and run the load test for a little while between each test.
>
> I'll post an update when I make any progress!
>
> Best,
> Jonatan
>
> On Thursday, May 5, 2022 at 2:37:06 PM UTC+2 Antonis Christofides wrote:
>
>> Hi! This is a very interesting problem, and I'm afraid I'm not qualified 
>> to answer it. What I'd like to point out is that, if I had done all the 
>> work that you seem to have done, I would be tempted to start bisecting in 
>> between versions 3 and 3.1 in order to find the exact commit that causes 
>> the problem.
>>
>> (However, in order to avoid that, I might also take a second look at the 
>> release notes, in case there was some information in there. And I might 
>> also ask in the developers mailing list—many of those who might know the 
>> answer don't read django-users.)
>>
>> It's possible it's a Django issue, but it's also possible it isn't. For 
>> example, it could be some error in your caches or templates or other 
>> configuration that happens to only manifest itself in Django>=3.1.
>>
>> In any case, I'm eager to learn how this plays out.
>>
>> Regards,
>>
>> Antonis
>>
>> On 04/05/2022 12.12, Jonatan Heyman wrote:
>>
>> Hi!
>>
>> I've recently upgraded an old Django app from Django 1.11 all the way up 
>> to Django 4.0. Even though the app is pretty large, the migration went 
>> smooth (or so I thought). However, when all tests passed and I deployed the 
>> app to production, I saw that the response time of the app took a 
>> significant hit (the response time for the 95th percentile went from about 
>> 300 ms to 900 ms, and the median from about 100 ms to 250 ms). I also saw 
>> that the server CPU load had increased significantly.
>>
>> I wrote some load tests and started downgrading Django. Now I've narrowed 
>> down the problem to appear when I upgrade from Django 3.0.x to Django 
>> 3.1.x, with no other significant changes to my app code.
>>
>> Is this something someone else has experienced, or does anyone know what 
>> might be going on?
>>
>> Are there any known changes that might increase CPU usage? In that case, 
>> I could throw more hardware at the problem.
>>
>> Any ideas, pointers or insights would be greatly appreciated!
>>
>> Best,
>> Jonatan
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/5f05c06c-bd22-417b-9688-20aca9632bcbn%40googlegroups.com
>>  
>> 
>> .
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/c0712c2b-a796-4bbb-a20a-df31efa5ae8fn%40googlegroups.com.