Per RFC1738 you can supply a username and password for basic auth as part of the URL in the format: http(s)://username:password@example.com 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.
Allows HTTP Basic Auth URLs being passed, parsed and handled correctly to authorise against a server expecting that.
This is a simplification, completely ignoring if the server supports or asks for HTTP Basic Auth. We simply format and set the header if the URL indicates so.
This also fixes parsing URLs containing a colon (':') /not/ indicating a custom port (but e.g. the seperation between user and password as part of the HTTP Basic Auth credentials).
Previously, the lib died ungracefully when parsing an URL containing HTTP Basic Auth credentials, as it was always expecting at most only one colon (':') and also the part coming afterwards being neccesarily a number (port).
Thanks for the contribution.
This package is actually quite outdated now. It still works but there's a much newer python-ecosys/aiohttp package which has a lot more features than this one (although not basic auth yet...).
Do you have a particular reason to use uaiohttpclient?
If we continue to maintain this package then it should offer something different to python-ecosys/aiohttp. For example this one should be much more light weight.
I just picked the first async HTTP client lib I found, verified it working, embedding it into my project - and found out (way too late), it lacks HTTP auth. And instead of searching around and trying out other libs with each havingtheir own quirks and uasynciohttpclient basically working for me. I just hacked it in and created this PR.
OK, thanks for the explanation.
I'm happy to accept the changes in this PR, but will make some more specific comments about them.
Probably it isn't implemented because
Just for curiosity: are there running servers using https://user:pass@... ?
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.
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.
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?
Yes; DynDNS (Part of Oracle) use this for updating Dynamic DNS records see their help article here