Skip to content

urequests doesn't handle basic auth formatted URLs correctly #668

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
0xVeles opened this issue May 24, 2023 · 5 comments
Open

urequests doesn't handle basic auth formatted URLs correctly #668

0xVeles opened this issue May 24, 2023 · 5 comments

Comments

@0xVeles
Copy link

0xVeles commented May 24, 2023

Per RFC1738 you can supply a username and password for basic auth as part of the URL in the format: http(s)://username:[email protected] however urequests interprets any colon following the protocol to be delimiting a host and port, as seen here.

Obviously it's simple to provide basic auth as a header instead, but it's probably best to be RFC compliant when possible.

@massimosala
Copy link

Probably it isn't implemented because

  • passing clear text credentials in the URL is a bad idea
  • there are modern authentication options available, this is becoming obsolete.

Just for curiosity: are there running servers using https://user:pass@... ?

@massimosala
Copy link

massimosala commented Jun 28, 2023

Hi

I have rewritten the library, with some improvements and basic auth.

Do you want to test it ?

After your feedback, I will open source it and propose the new version to the Micropython mantainers.

@jonnor
Copy link

jonnor commented Aug 25, 2024

I think that parsing username:password out of URLs can be a separate function, which extracts the relevant information and a cleaned URL. And those that the few that need it can copy-paste it into their project.

@smithps
Copy link

smithps commented Nov 18, 2024

I just found this bug report as I am trying to implement DDNS on a PicoW - the URL specified by dyndns is as follows;

https://{user}:{updater client key}@members.dyndns.org/v3/update?hostname={hostname}&myip={IP Address}

Which although not using a password as such, is still passing a plaintext "key".

Out of curiosity and in order to be able to handle such formatted URLs (even if they aren't recommended - it's obvious that they are still in use)....would it be sensible to search backwards from the first '/' looking for a port number and/or if the value found after the ':' is not numeric to ignore it?

@smithps
Copy link

smithps commented Nov 18, 2024

Probably it isn't implemented because

  • passing clear text credentials in the URL is a bad idea
  • there are modern authentication options available, this is becoming obsolete.

Just for curiosity: are there running servers using https://user:pass@... ?

Yes; DynDNS (Part of Oracle) use this for updating Dynamic DNS records see their help article here

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

No branches or pull requests

4 participants