Forum Discussion

adfhogan's avatar
adfhogan
Frequent Contributor
1 month ago

1Password no longer offering to fill in locally hosted http service

On my local LAN, I have an instance of a news feed reader program, tt-rss, running. It's recently moved to new management after its original author dropped the open source project.

As it's not externally accessible, I can't easily give it something like an LE SSL certificate, so it runs over plain HTTP.

I run Ubuntu, and at the moment use the 1Password Beta 8.11.22.25 plugin in Firefox 145.0.2-canonical-002-1.0 snap, so due to the ongoing sandboxing issues, 1Password browser plugin cannot communicate with the local 1Password instance, and phones home to 1Password servers instead.

The URL of the internal-only service is something like:

http://ttrss.internal.external.tld.country/

... and it resolves to something in RFC1918 range. When I tell the plugin to "Collect Page Structure", the JSON it returns is:

{
	"unparsedUrl": "http://ttrss.internal.external.tld.country/",
	"title": "Tiny Tiny RSS : Login",
	"frames": []
}

... so it seems like 1Password browser plugin is not even giving me the option to ignore the HTTP warning (like it does on my Android device), rather it's fully blocking auto-fill from the page (why isn't it parsing the URL?)?

At the moment, my workaround is to click on 1Password icon in browser, and them manually copy username and password.

Is this a deliberate removal of support for autofill of HTTP support in latest versions? Could this perhaps still be supported for RFC1918 IPs?

2 Replies

  • adfhogan's avatar
    adfhogan
    Frequent Contributor

    Yeah.. tld is a little contradictory.. in this case I mean stuff like ".com" ".net" ".org" etc. as opposed to a cctld. There's probably another acronym for that bit :)

    My domain predates 2020. I'd rather not have to go renaming all my systems.

    It does sound like the post from the other person.

  • AJCxZ0's avatar
    AJCxZ0
    Silver Expert

    Not so long ago, ICANN approved `.internal` top-level domain for private (in the RFC 1918 etc. sense). It would be a nit-pick to note that "tld.country" is a contradiction, but taken together, the domain name for your private service would be most appropriately end with `.internal` with that name being resolved locally.

    That doesn't address your problem, which may be a reported problem handling insecure - http:// - URLs.