Comments (11)
I think that might be what ends up happening. I'm thinking through what will be in the next release right now (there are a couple other things I want to get in), as well as whether it's time to start planning a major version bump at some point to try to handle yet more custom-user edge cases...
from django-registration.
Hi,
I'm experiencing the same issue on my project, any luck in resolving it?
Thanks!
from django-registration.
I've created a minimal example to demonstrate the error and maybe analyse it: https://github.com/christianwgd/django_registration_issue_238
It creates the following output:
from django-registration.
I'll try to figure this out. Unfortunately, Django's validators aren't really designed for two validators to both error with the same error message :/
from django-registration.
Hey, thanks for bothering. To me it seems like the HTML5 validator doesn't do a more accurate check on the email address than the standard django email validator. But maybe I don't fully understand, what the purpose of the HTML5 validator is.
So maybe it's possible to subclass the django email validator to add the missing HTML5 check there?
from django-registration.
My current workaround for this is to remove the django email validator from the list of validators, since it seems to have a more strict regex.
If you can give me a hint on why you introduced the HTML5 validator, I can give it a try to bring those two together.
And if the HTML5 validator is checking on some special cases, we could try to respond only to them and try to find a more suitable error message for that (so not check the whole thing again).
from django-registration.
The main point of the HTML5 validator, for this specific app, is to ensure that no "valid" email address value is ever accepted which contains more than one @
character. This makes splitting the local-part and domain very easy for applying the homograph/confusable check (see #175 for background).
I also prefer the HTML5 validator's regex because it gets uniformity across the frontend and backend -- django-registration enforces the same thing an HTML5 input type="email"
does -- and because it disallows a lot of the uselessly complex things people can "technically" do in an email address according to the RFCs, but which just make trouble for sites that try to handle them.
from django-registration.
Also I'm mildly curious to know how this is getting around the client-side validation -- since it's an input type="email"
the browser ought to be applying the HTML5 email rules and not even allowing you to submit the form for the Django backend to see it.
from django-registration.
So you think the right way to go is what I've done in my workaround and use only the HTML5 validator and remove the standard django validator? As far as I've tested this seems to be a sufficient fix.
from django-registration.
So as @christianwgd suggested, the least-breaking thing to do here is just to not apply the default Django validator. I've pushed a commit which makes that change, and it'll be included in the next release (3.4), due out Soon™.
Note that this is, amusingly, not a backwards-incompatible change because it doesn't change the set of accepted addresses.
from django-registration.
django-registration 3.4 has been released, containing this fix.
from django-registration.
Related Issues (20)
- Best way to resend activation email
- List URL names defined for one-step workflow in quickstart
- django.utils.translation.ugettext_lazy() is deprecated in favor of django.utils.translation.gettext_lazy() HOT 1
- ACCOUNT_ACTIVATION_DAYS not an int HOT 1
- Translation for "Password" does not work HOT 1
- invalid token and site not found
- Is there a function to change email address? HOT 1
- i18n translation doesn't work. HOT 2
- Support for Django 3.2 HOT 2
- Usage with a proxy model to a custom user class. HOT 2
- ``RegistrationView`` only supports ``ModelForm`` but not conventional forms HOT 1
- Missing documentation on removal of `cleanupregistration` HOT 1
- Migration from 2.x to 3.x leaves `registration` table in database HOT 5
- False ImproperlyConfigured error HOT 2
- Error importing RegistrationView when using custom user model with unique USERNAME_FIELD HOT 7
- No rendering in email template HOT 2
- Undocumented assumption about custom user models HOT 1
- Two-step `ActivationView` runs `activate()` on HTTP GET HOT 2
- Python 3.11+ support? HOT 1
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-registration.