Comments (8)
Added 'USER_VERIFICATION_ID_FIELD'
setting key to customize verification.
This feature will be released in next version (0.4.5
).
from django-rest-registration.
Why do you want to use username instead of user_id in the signer? Currently Django REST Registration does not allow to customize the signing process in that way.
from django-rest-registration.
Beacuse i don't want to disclose user's id. Using username in verification mail is a better security concern instead of user-id. Also username should not be used in reset password link instead of this use email address to send reset password link.
from django-rest-registration.
Beacuse i don't want to disclose user's id
OK, but could you provide your use case? I'm still not getting how revealing the user id could cause a problem.
It is assumed that the user can access it's user ID anyway from the profile endpoint (but ok, you can replace the profile serializer).
There is a possibility that someone else than the user may have access to the verification link and therefore to the user ID (This should not happen; but in case we have REGISTER_VERIFICATION_ONE_TIME_USE
to at least to protect the the verification url for being reused)
Using username in verification mail is a better security concern instead of user-id
Could you explain what you mean by that? I understand that in some cases the username may be more exposed to the user (in the UI), but I don't see how identifying the user by username and identifying the user by user id is different in regards to security concerns. Actually, there may be cases where you allow the user to change the username - in this case I imagine identifying by username can pose potential security threat.
Also username should not be used in reset password link instead of this use email address to send reset password link
There is a similar problem like the one I described above: you can change the e-mail for a given user, but you can't change the user ID. So theoretically using a e-mail in reset password link could cause a possibility to reset a password for a different user (but it will probably not happen with RESET_PASSWORD_VERIFICATION_ONE_TIME_USE
enabled).
from django-rest-registration.
The main reason to not use user_id is this shows the primary key of user database. And i don't like to show my user how many users i have.
So theoretically using a e-mail in reset password link could cause a possibility to reset a password for a different user
I can't understand this. But what i can tell you in daily life people are used to remember email address but remembering username is bit hard.
What if someone forget their username (which is uses as login in sending reset password link) . Does django-rest-registration has any solution for this.
It is assumed that the user can access it's user ID anyway from the profile endpoint
How i can assume? whenever user signup for first time they will have the user id on their email. So basically user knows that what is their user id.
from django-rest-registration.
... And i don't like to show my user how many users i have.
OK, that's fair point. One way to solve this would be to use UUID as your primary key, but I know some people may prefer to use integer IDs as internal primary keys and UUIDs (or whatever random key) as a external ID (with unique constraint in the DB).
I would still not use e-mail as user id (and this applies to username as well if it can be changed), reasons below.
I guess you convinced me. The problem I see is that the best solution I have in mind (which will not make DRR code messy and hard to read) includes changing user_id
field in the signed data payload (this includes the verification link) to more general user
to avoid confusion. This would make the code
I guess the initial solution could be leaving the name user_id
but allow the user identification field to be changed, and then make the change user_id
-> user
in next major version (0.5.0
?, 1.0.0
?). Probably user_id
should be deprecated first, and then removed altogether.
So theoretically using a e-mail in reset password link could cause a possibility to reset a password for a different user
I can't understand this.
Example (in case of username used for user identification):
- User with user_id=1 has username
alice
- User with user_id=2 has username
bob
alice
requests password reset (but does not click the link)alice
changes username toaliceinwonderland
bob
changes username toalice
- now
aliceinwonderland
(originallyalice
, user_id=1) can changealice
(originallybob
, user_id=2) pasword using the reset password link
This is somewhat improbable scenario, but as you can see it's not impossible. In case of using e-mail as user identification this scenario alice
would need to delete her e-mail account, and bob
would need to create the e-mail account with the same address, which makes this case less probable, but still not impossible.
So again, I would argue that if you don't want to expose your user primary keys you should NOT use any field which may change for given user (e-mail, username if changeable). You should rather have another field which would be some random sequence (UUID or string of chars) which would never change.
from django-rest-registration.
I would argue that if you don't want to expose your user primary keys you should NOT use any field which may change for given user
Well you are absolutely right. I have a simple solution for this in my mind. Why don't we ask for password when confirming email. DRR simply integrate username in verification hash and when someone confirm their email it will decode verification hash for username then it will verify with decoded username and password.
from django-rest-registration.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
from django-rest-registration.
Related Issues (20)
- Custom mail templates source HOT 1
- Add ‘REGISTER_RETRIEVE_TOKEN’ HOT 3
- Error messages being stripped out of their codes. HOT 3
- To be able to return a custom response on successful password reset using data from request. HOT 2
- Support for Django 4.x HOT 2
- Please add ability to add user fields to successful login response HOT 4
- Setting to disable new user registration (the `/register` endpoint) HOT 4
- Page not found (404) HOT 6
- Why is there a check for a specific backend? HOT 6
- Remove check for LOGIN_FIELDS being unique HOT 1
- Dependency conflict in development requirements. HOT 2
- Fix type ignore issues
- Swagger generation through generateschema failing with VerifyRegistrationView HOT 2
- 'VerifyRegistrationView' should either include a `serializer_class` attribute, or override the `get_serializer_class()` method HOT 4
- user_activated not invoked HOT 2
- Cannot use a custom registration serializer that has a nested serializer HOT 5
- error while run `make install_dev`, Building wheel for backports-zoneinfo (pyproject.toml) did not run successfully. HOT 5
- Minor suggestion: correct typo in reset password view name HOT 1
- Customized registration process HOT 11
- Django signal user_logged_in is not always fired when login via login endpoint is performed successfully
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from django-rest-registration.