Skip to content

Conversation

maneandrea
Copy link

@maneandrea maneandrea commented Oct 16, 2024

Sometimes users are created from a template user via a copy().
This has the issue that a password is passed via the vals of the copy
and therefore never seen by the write() function.

As a result, the password_write_date field is left to the value of the
template, which is either outdated or null.

A concrete bug that resulted from this is that newly created users were
asked to renew their password on their very first login.


This commit reapplies the same logic of the write() method to the
copy() method as well.

It also changes the unit test test_03_create_user_signup to create the
user at some time in the past so that

assertNotEqual(password_write_date, created_user.password_write_date)

makes sense.

Finally it fixes the do_signup method to user the current user's
password otherwise the password_write_date will be overwritten even when
inputting invalid passwords

@maneandrea
Copy link
Author

@moylop260 or @luisg123v Can you review?

@maneandrea maneandrea force-pushed the 16.0-password_security-update_on_copy-andrea branch 4 times, most recently from aa457f9 to 15da524 Compare October 22, 2024 20:31
@@ -17,7 +17,10 @@
class PasswordSecurityHome(AuthSignupHome):
def do_signup(self, qcontext):
password = qcontext.get("password")
user = request.env.user
user = (
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the commit and the description mention the change in the copy

But this change is not mentioned

Also the title mention "...password_write_date on copy"

Could you elaborate how this search affects the purpose of this PR, please?

Copy link
Author

@maneandrea maneandrea Oct 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am open to separate this in two PRs. Conceptually they are different fixes but in practice they are both needed.

The case is when a user has 2FA activated. If that is the case, they get to this method as the public user, so the check in user._check_password(password) does not detect the use of an old password. This makes the write method run which in turn updates password_write_date. Only after then, a second call to _check_password rejects the change.

However, since password_write_date is not now updated to today, the user is able to log in with the old (expired) password and use it for a long time after that.

BTW: I updated the PR description to match the commit message.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello, could you add a comment above the search to explain what we are trying to fix? That will help the maintenance in the future as it's not obvious just by reading the code.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sebalix Sorry for the delay. I added some explanatory comment

@sebalix sebalix changed the title [FIX] password_security: update password_write_date on copy [16.0][FIX] password_security: update password_write_date on copy Jan 3, 2025
@maneandrea maneandrea force-pushed the 16.0-password_security-update_on_copy-andrea branch from 15da524 to 82e5c0a Compare January 15, 2025 19:28
Copy link
Contributor

@moylop260 moylop260 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Comment on lines 35 to 38
def copy(self, vals):
if vals.get("password"):
vals["password_write_date"] = fields.Datetime.now()
return super(ResUsers, self).copy(vals)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @maneandrea thank you for proposing a fix for this bug.
I found the same issue when signing up, the template user is copied with its initialization value of password_write_date.

I am however wondering about the way you propose to fix it, from my point of view, it would be better that this field "password_write_date" is not copied at all (adding a copy=False on field definition). If no value is provided then it will use default (= fields.Datetime.now()).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm taking over for Andrea so all issues in the PR get corrected. I just changed the field definition so that it is not copied over. Also added a unit test that verifies the fix is working. Can you review again please?

@antonag32 antonag32 force-pushed the 16.0-password_security-update_on_copy-andrea branch from 82e5c0a to c33e127 Compare March 11, 2025 00:24
Sometimes users are created from a template user via a `copy()`.
This has the issue that a password is passed via the `vals` of the copy
and therefore never seen by the `write()` function.

As a result, the `password_write_date` field is left to the value of the
template, which is either outdated or null.

A concrete bug that resulted from this is that newly created users were
asked to renew their password on their very first login.
---
To ammend this, the field is no longer copied when cloning users. A new
unnitest was added to verify this.

It also changes the unit test test_03_create_user_signup to create the
user at some time in the past so that
```python
assertNotEqual(password_write_date, created_user.password_write_date)
```
makes sense.

Finally it fixes the do_signup method to user the current user's
password otherwise the password_write_date will be overwritten even when
inputting invalid passwords
@antonag32 antonag32 force-pushed the 16.0-password_security-update_on_copy-andrea branch from c33e127 to f8c4092 Compare March 11, 2025 00:36
@OCA-git-bot
Copy link
Contributor

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

@remi-filament
Copy link

Thanks @antonag32, tested on Runboat, it works as expected !
Best Regards

@antonag32
Copy link

Great, can a maintainer merge the change?

@moylop260
Copy link
Contributor

/ocabot merge patch

@OCA-git-bot
Copy link
Contributor

This PR looks fantastic, let's merge it!
Prepared branch 16.0-ocabot-merge-pr-713-by-moylop260-bump-patch, awaiting test results.

@OCA-git-bot OCA-git-bot merged commit 8ccbc97 into OCA:16.0 Mar 13, 2025
9 checks passed
@OCA-git-bot
Copy link
Contributor

Congratulations, your PR was merged at f75d2e3. Thanks a lot for contributing to OCA. ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants