Opened 9 years ago
Last modified 9 years ago
#25593 closed Uncategorized
Remove scheme validation from URLValidator or provide all IANA acceptable schemes as defaults — at Version 1
Reported by: | Marcin Nowak | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.8 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
The problem
There are defined only four schemes as default: http,https,ftp,ftps.
But URL can have many many more valid schemes.
HTTP and FTP as good defaults are invalid - they are too limited.
There is no simple way to extend these schemes nor disable scheme validation.
We must extend URLField and redeclare default_validators
class property, which is too complex for that simple case.
Possible solutions
- disable scheme validation and enable it only when user defines
allowed_schemes
directly in URLField (backward incompatible) - provide
allowed_schemes
as an optional argument for URLFieldinit()
- provide all valid schemes as default set (based on https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml)
Prefered solution
Provide all (IANA) valid schemes as default together with possibility to change them by URLField init()
.
I think we can rule out any backwards incompatible solutions such as removing the validation or changing the default to all valid schemes. I don't see a sufficient justification for breaking all sites relying on the current behavior. You'll need to argue your rationale on the DevelopersMailingList and get a consensus if you want that.
It seems to me that there are too many customization points on validators to add a new model field argument for all of them (such as
allowed_schemes
as you proposed). For example, there have also been requests to customize the validator's regular expressions. It doesn't seem clean to add a model field argument for each one of those validator attributes.I'd like to try for a more general solution to allow customizing the
default_validators
as I described in #25594. I believe that would meet the use case of this ticket.