Frontend: New auth system 0.77.1 does not play nicely with password managers
@apateluk commented on Aug 31, 2018, 8:44 AM UTC:
Version : 0.77.1
Have been using 1password with the Home-Assistant front end for log-in up until moving to the new auth system.
With the new auth system, autofill doesn't work on either the username or password fields on the web page. Can be worked around by copy and pasting from the password manager, but is not the most convenient.
Thanks
Anand
This issue was moved by awarecan from home-assistant/home-assistant#16317.
move[bot]
All 29 comments
@Boosik commented on Aug 31, 2018, 11:06 AM UTC:
Can confirm.
I'm using Google passwords and I can neither "generate strong password" on the password filed neither does Google ask me to save the password.
This is a huge downer for me.
move[bot]
on 31 Aug 2018
it appears that page controls are being created in the shadow DOM (as is common with Polymer apps - and a gross ovesimplifacation i know) but this doesn't allow password managers to see the input fields. Can confirm this is an issue with both LastPass and BitWarden.
I should not need to expose my passwords by using the clipboard. Please present a standard form on the login page so that password managers can see it.
fouram
on 3 Sep 2018
Tossing in my +1 on this. In a desktop browser, the work around isn't too bad. On a mobile device however, it is a hassle.
randellhodges
on 3 Sep 2018
Password managers will need to update their extensions to work with ShadowDOM. For users of 1password, a beta version that supports ShadowDOM and works with Home Assistant is available here: https://agilebits.com/onepassword/extensions?beta=true (more info here)
balloob
on 4 Sep 2018
Can confirm the beta 1Password extension for Chome does indeed work with HA. AgileBits have withheld the Safari beta, so not currently working, but hopefully should soon.
Folks using other Password managers should probably file a bug report with the respective providers.
apateluk
on 4 Sep 2018
I still think we should render a more usable markup for at least the auth bits. This is because the mobile platforms have less flexibility. For instance, iOS is making it's password management integration much more powerful this year, but it doesn't appear to recognize Shadow Dom. That means it's likely going to be another year before it will be simple for users on that platform can login to hass with complex passwords in the simple way they can with most other apps.
blackgold9
on 10 Sep 2018
A PR is welcome to rebuild our authorize flow in Preact…
balloob
on 10 Sep 2018
The future will be preact?
awarecan
on 10 Sep 2018
The future of our auth system? Probably yes, since web components don't work with password managers 🤷♂️
balloob
on 10 Sep 2018
Issue known since at least Aug 31, 2018 - and nothing been done? Only response is us complaining to the passwordmanager department instead?
I learned about this issue on reddit.. Its STILL a problem on at least lastpass, bitwarden, enpass...
So there is no fix planned?
GitJamz
on 21 Jan 2020
PRs welcome
iantrich
on 21 Jan 2020
With #4327, is the proposed fix for this issue still to use Preact?
kejadlen
on 21 Jan 2020
I'm not sure what the status of password apps is, 1password had a beta with support for shadowDom, is that dropped or will that still ship at some point?
bramkragten
on 21 Jan 2020
It looks like it is supported now in 1password stable at least.
bramkragten
on 21 Jan 2020
If 1password can do it, so can other password managers. I suggest people open bug reports that Shadow DOM is not supported. We are not going to rewrite our auth flow. We're aiming for 100% Lit.
balloob
on 22 Jan 2020
1Password is not working for me on either the PC or iOS. Apple have changed the password management framework in the past year, so this probably has broken things.
apateluk
on 22 Jan 2020
@balloob
If 1Password can do it, so can other password managers.
1Password only released limited support for this. There are a few 1Password formats:
- Mobile: 1Password for iOS / Android
- CLI: 1Password CLI for Windows/macOS/Linux/*BSD
- Desktop: 1Password for macOS / Linux / Windows
_If you want to use any of the desktop apps to fill in passwords on a website, you need to also install the companion extension. It's a really clunky experience._ - Browser Companion: 1Password extension (desktop app required), a.k.a. "Companion Extension" for Chrome / Firefox / Edge / Brave
- Browser: 1Password X for Chrome / Firefox / Edge / Brave
Shadow DOM is only supported by the companion extension.
My guess is that the companion extension is using some sort of OS-level function to target shadow DOM elements. Accessing the shadow DOM through a pure browser extension is a non-trivial lift.
1Password X (standalone browser addin) and 1Password mobile are the flagship apps. They're pretty, seamless, and sync nicely between computers. These are the apps that 1Password steers users towards downloading.
The point is that shadow DOM is only implemented in 1Password's stepchild app. There's no indication that they're going to roll out support in their flagship apps.
We are not going to rewrite our auth flow. We're aiming for 100% Lit.
I totally get wanting to maintain consistency, but consistency on the login page means that users can't use password managers with HA. This creates a frustrating login experience and nudges users toward using weak passwords outside of their password managers.
With this in mind, would you reconsider changing how the authentication page is rendered? Would an acceptable solution be creating a shadow-DOM-free version of the auth page that can be enabled through HA's config file?
elahd
on 25 Mar 2020
It just feels ridiculous.. I still have not seen a single problem anywhere else but the homeassistant login page. And I have so many apps, logins, forums, passwords you cant even believe..
But these developers defending this horrible decision to implement this here, and not budge... Its a disaster decision to stick by.
GitJamz
on 25 Mar 2020
I think we found ourselves a volunteer to fix it 😆
balloob
on 25 Mar 2020
If I could I would..
Im glad you agree it needs fixing though.. Better then
"I suggest people open bug reports that Shadow DOM is not supported. We are not going to rewrite...."
The person that took the notsogood decision in the first place could maybe volunteer to fix this now instead..
GitJamz
on 25 Mar 2020
🤦♂️
This may be beyond my coding abilities. What's the format, anyway, for building pages outside of the LitElement framework? Has this been done anywhere else inside HA?
elahd
on 26 Mar 2020
Not using the shadow root in a LitElement is simple: https://lit-element.polymer-project.org/guide/templates#renderroot. But the rest of the implementation isn't probably.
bramkragten
on 26 Mar 2020
@bramkragten I'm having trouble implementing that even as a basic test. This looks tough. The shadow DOM elements on the login screen are nested deeply and I'm not sure of how I can modify render behavior on just one page. Can you offer any guidance?
Separately, this new post from 1Password says that they have no plans to support shadow DOM in their mainstream products.
elahd
on 7 Apr 2020
As a developer I understand that code maintainability is (very) important but, as a user, not being able to use a password manager comes with a cost.
By the way, something that was working _before_ and does not _after_ is a bug by definition. You can blame the rest of the world for not being up-to-date but the situation is actually quite clear. It's a real pity that this consequence was not caught when the new approach has been adopted but that is just normal, could not be different.
The major pain point for me is that the only service I run on my own, in my house, is the most uncomfortable to access. I find it _absurd_ that I need to choose between my preferred home automation tool and my preferred password manager. Or keep the small continuous pain.
Oh boys, this is an interoperability issue. HA is interoperable with thousands of different things but no, users with legacy password managers (ie. all of them) are out of the list.
This is your problem, no user can fix it.
cavokz
on 10 Aug 2020
Reading about this in slack and how others have done this, it seems that the most common way is adding the hidden inputs to the Body and on changes to either input (on body or in element) it updates the other.
Something like this. right now its one way but this may be the easiest way. A lot of tweaks needed, adding those fields in a form. Cleaning up the code, updating both ways, actual testing.
@balloob @bramkragten thoughts on an approach like this?
zsarnett
on 10 Aug 2020
Bitwarden on Android is able to paste in the login no problem, but Bitwarden on desktop is completely unable to paste anything.
lightmaster
on 20 Aug 2020
I just tried Dashlane and 1Password and both aren't able to autofill either.
hukoeth
on 20 Aug 2020
The build-in password manager for Firefox does not work either.
tribut
on 21 Aug 2020
Conversation on this should be continued at https://github.com/home-assistant/frontend/issues/3133
zsarnett
on 1 Sep 2020
Related issues
andriej
·
3Comments
casperklein
·
4Comments
aaron9060
·
3Comments
martinhoess
·
3Comments
wangyt123ng
·
3Comments
Most helpful comment
I still think we should render a more usable markup for at least the auth bits. This is because the mobile platforms have less flexibility. For instance, iOS is making it's password management integration much more powerful this year, but it doesn't appear to recognize Shadow Dom. That means it's likely going to be another year before it will be simple for users on that platform can login to hass with complex passwords in the simple way they can with most other apps.