Opened 15 years ago

Closed 9 years ago

#9791 closed Uncategorized (duplicate)

URLField's validation does not support in-URL basic AUTH

Reported by: django-nolan@… Owned by: nobody
Component: Forms Version: 1.0
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

URLs of the form:
http://user:password@host/path
are not supported.

It appears that this is a urllib2 limitation.

Change History (8)

comment:1 by Jacob, 15 years ago

Resolution: wontfix
Status: newclosed

I'm reluctant to allow this simply on the principle that storing other people's passwords in plaintext is bad juju. Indeed, it's trivial to use RegexField with a custom pattern and/or custom validation logic of this is something you need. So unless someone can give a great reason why this ought to be in core, I don't see much use in fixing this.

comment:2 by django-nolan@…, 15 years ago

Well, I have users entering URLs of this form, and so I needed to not choke on them.

That said, I've already turned off validation and hard coded my own inline, so I no longer especially care about this. If this is deemed a rare enough need that it should be reimplemented each time, I see no problem with that.

in reply to:  2 comment:3 by James Bennett, 15 years ago

Replying to django-nolan@sigbus.net:

If this is deemed a rare enough need that it should be reimplemented each time, I see no problem with that.

(this is the part where I point out that we're all programmers here, and if you find yourself needing this often the thing to do is not "reimplement each time", but rather whip up a quick little library, put this in it, reuse it over and over as needed, and then maybe even offering that library to others in case they need it too)

comment:4 by anonymous, 15 years ago

Unfortunately, I suspect my quick hack is insufficiently general to be a library function, but here it is in case someone else finds this bug report:

        u = urlsplit(in_url)

        if u.scheme.lower() != "http":
            raise forms.ValidationError("Only http is supported")

        passman = urllib2.HTTPPasswordMgrWithDefaultRealm()
        if u.netloc.find('@') >= 0:
            user = u.username
            passwd = u.password
            u = list(u)
            u[1] = u[1].split('@')[1]
            url = urlunsplit(u)
            passman.add_password(None, url.split["//"][1], user, passwd)
        else:
            url = in_url
        authhandler = urllib2.HTTPBasicAuthHandler(passman)
        opener = urllib2.build_opener(authhandler)
        urllib2.install_opener(opener)

        #XXX Add timeout param when we can use python 2.6...
        try:
            req = urllib2.Request(url)
            f = urllib2.urlopen(req)
        except urllib2.HTTPError, e:
            raise forms.ValidationError("Couldn't get URL %s: %s" %
                                        (in_url, e))
        except urllib2.URLError, e:
            raise forms.ValidationError("Couldn't connect to %s: %s" %
                                        (u[1], e.reason))

        if f.code != 200 and:
            raise forms.ValidationError("URL did not return 200 OK")

in reply to:  1 comment:5 by anonymous, 12 years ago

Easy pickings: unset
Severity: Normal
Type: Uncategorized
UI/UX: unset

Replying to jacob:

I'm reluctant to allow this simply on the principle that storing other people's passwords in plaintext is bad juju. Indeed, it's trivial to use RegexField with a custom pattern and/or custom validation logic of this is something you need. So unless someone can give a great reason why this ought to be in core, I don't see much use in fixing this.

There's no way to determine what use case this may be or what level of "juju" it implies.
I use it frequently for wget, cadaver and some xmlrpc cli utilities.
It's certainly not worse than FTP or login forms over HTTP, both are quite commonplace in the real world.

Let's just follow the standards and let the users worry about their specific use cases and/or security issues.

comment:6 by Aymeric Augustin, 12 years ago

anonymous, you must be aware that the "standards" regexp provided in the RFC for parsing URLs matches absolutely anything, so it's useless for validation. Just "following the standards" doesn't mean much here. Also it isn't Django's policy to let users worry about security issues.

comment:7 by Federico Capoano, 9 years ago

Resolution: wontfix
Status: closednew

Suppose this case: ssh://git@git.repo.com/my-fantastic-privately-hosted-project.git. Isn't this a URL? With the current URLField it is not possible to have this URL pass the validation without some additional work.

If the field is called a URLField it should do what it says, at least according to the principle of least astonishment.

In my opinion, making us work more to achieve such simple things is against the goals of Django.

Therefore I reopen this ticket.

comment:8 by Tim Graham, 9 years ago

Resolution: duplicate
Status: newclosed

Duplicate of #20003 which is accepted.

Note: See TracTickets for help on using tickets.
Back to Top