Keepassxc-browser: Http-basic won't autofill

[hamsterrrr]

Expected Behavior

I want those fields fiiled out as well as everything else

Current Behavior

I choose an appropriate name in a pop-up KeepassXC, but nothing happens. In Settings of KeePassXC-browser I have checked the option "http-basic-auth"

Possible Solution

Steps to Reproduce

https://youtu.be/ndU16ih9bbo

Debug Info

KeePassXC - 2.5.3
KeePassXC-Browser Version: 1.5.4

Operating system: Ubuntu 18.04

[varjolintu]

Can you reproduce this with URL https://httpbin.org/basic-auth/user/passwd? (the credentials for that are: user / passwd).

[hamsterrrr]

Hmm. This link seems to be working as it's supposed to do.
Looks like in my case it was not http basic auth, was it? How do I check it?

[varjolintu]

For example: curl -u name:passwd http://machine.domain/full/path/to/file

[hamsterrrr]

curl -v -s -u admin:pass 'https://192.168.100.1:443' -k 1> /dev/null

* Rebuilt URL to: https://192.168.100.1:443/
*   Trying 192.168.100.1...
* TCP_NODELAY set
* Connected to 192.168.100.1 (192.168.100.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [81 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [1169 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [526 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [134 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / DHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=mi.home
*  start date: Jan  1 00:23:35 2015 GMT
*  expire date: Jan  1 00:23:35 2016 GMT
*  issuer: CN=HTTPS CA
*  SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway.
* Server auth using Basic with user 'admin'
} [5 bytes data]
> GET / HTTP/1.1
> Host: 192.168.100.1
> Authorization: Basic YWRjkhjklZmttLGZuaGpjYnlm
> User-Agent: curl/7.58.0
> Accept: */*
> 
{ [5 bytes data]
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: httpd
< Date: Fri, 13 Mar 2020 19:41:07 GMT
< X-UA-Compatible: IE=edge
< Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
< Expires: -1
< Content-Type: text/html
< Connection: close
< 
{ [920 bytes data]
* TLSv1.2 (IN), TLS alert, Client hello (1):
{ [2 bytes data]
* Closing connection 0
} [5 bytes data]
* TLSv1.2 (OUT), TLS alert, Client hello (1):
} [2 bytes data]

as far as I can see it says Authorization: Basic

[agsteele]

I have a similar issue with http-basic-auth...

In my case I open the URL https://www.icti.org.uk/mta_admin/

The standard login panel opens but with no credentials inserted.

If I then click Cancel the standard Unauthorised warning is displayed.

Then I refresh the the screen and everything works just fine.

If I visit https://httpbin.org/basic-auth/user/passwd this appears to work OK and reports:

authenticated: true
user:  "user"

KeePassXC - 2.6.0
KeePassXC-Browser - 1.6.4
Operating system: Win32
Browser: Mozilla Firefox 78.0

The debug info says Win32 but I have Win64 on a Windows 10 pc with a 64-bit version of Firefox.

[varjolintu]

I would need HTTP Basic Auth credentials for some site that has this bug. Otherwise it could be very hard to reproduce.

[agsteele]

I can see the challenge. Unfortunately, I cannot share the login in public since the data contains personal information subject to GDPR. I'll see if I can find an option to run a duplicate site without the personal data accessible.

[varjolintu]

Another option is to debug the extension by yourself. Inspecting the background script background/httpauth.js is the key here.

[agsteele]

Some active testing has led to this discovery.

If I manually type the URL in the browser address bar then theHTTP Basic Auth process worked.

If I access from a shortcut which points to https://www.icti.org.uk/mta_admin/ the problem returns.

A bit more testing and I think that editing the shortcut to: http://www.icti.org.uk/mta_admin - not HTTPS and dropping the trailing '/' and it seems to work OK. I'll have to test this over a few days to be satisfied and then revert back to full URL and see if the problem returns.

Perhaps this issue can be left open for a short while so that I can update what I can discover.

[agsteele]

Sadly, the 'solution' I thought I had located has not worked most of the time so it must just be coincidental.

I couldn't locate the background script in the Firefox debugger.

[varjolintu]

@agsteele about:debugging -> _This Firefox_ page from the left. Scroll to KeePassXC-Browser and select _Inspect_. You can find the background scripts under _Debugger_ tab.

[agsteele]

Thanks for the pointer. I was going via the Web Developer menu and the httpauth.js script wasn't shown there ;)

This has just about exceeded my areas of expertise but I was not able to find anything in the logging, warnings or errors that related to httpauth.js

Since I can't pass on the user credentials I'm not sure if there is any way to assist further.

All I can say is that it seems that the HTTP Basic Auth login box is appearing despite the credentials having been passed and recognised.

I enter the URL. The login box is presented. I click cancel and get the standard Unauthorised message. Then I refresh and am logged in.

It is untidy but, perhaps, the best I can hope for.

Thanks for the help.

[ThinkChaos]

I had the same issue and found that the extension was requesting credentials for https://example.com/, but in my DB it was saved without the trailing /, so the app returned 0 credentials.
I found two ways to get it to return the credentials:

• add a trailing / in my db
• unchecking the "return only best-matching" in KeepassXC. This looks like a bug!

I think this issue can be closed in favor of opening an issue for the app.

[droidmonkey]

That problem is fixed for 2.6.2.