Can't login with Firefox

[ghost]

@Vedeneb commented on Oct 16, 2018, 4:34 PM UTC:

Home Assistant release with the issue:
0.80.1

Last working Home Assistant release (if known):
Don't know

Operating environment (Hass.io/Docker/Windows/etc.):

Manual installation on a Raspberry Pi 3, running as a daemon

Component/platform:
Auth/Login

Description of problem:
I just switched from Chrome to Firefox for several reasons. I opened my local home assistant instance and tried to login using the new auth system (with username and pwd). As soon as I click "next" the following message appears:
Error: Message format incorrect: required key not provided @ data['client_id']

It looks like this:

I have 2FA enabled if thats relevant. On my PC I'm running Windows 10. I also have legacy api password enabled and tried to login with my api password -> same error. So I tried it again in Chrome and there it still works. I also tried Microsoft Edge and there it is working as well, so I asume it's a Firefox related issue. I tried to restart my PC, Home Assistant and even my Pi, nothing helped. I also tried to login on a second Windows device with Firefox and even there I get the same error.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
That's my http config:

http:
  api_password: !secret hass_pw
  server_port: !secret hass_port
  base_url: !secret hass_ext_url
  use_x_forwarded_for: True
  trusted_proxies:
    - 127.0.0.1
  ip_ban_enabled: true
  login_attempts_threshold: 5

Traceback (if applicable):
That's what I get in the log file as soon as I try to login:

2018-10-16 18:07:51 ERROR (MainThread) [homeassistant.components.http.data_validator] Data does not match schema: required key not provided @ data['client_id']

Additional information:
I'm using nginx to forward my hass instance to port 80, that's the corresponding config snippet:

location / {
                proxy_pass http://localhost:8123;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $connection_upgrade;
 }

This issue was moved by awarecan from home-assistant/home-assistant#17528.

[ghost]

@awarecan commented on Oct 16, 2018, 8:01 PM UTC:

Can you check the URL in the browser? Looks like client_id is missing in the URL

[ghost]

@Vedeneb commented on Oct 17, 2018, 6:45 AM UTC:

/frontend_latest/authorize.html
that's all. Yes, the client_id is missing but why?

[ghost]

@Vedeneb commented on Oct 22, 2018, 1:13 PM UTC:

Anyone? The issue persists. Even after upgrading to 0.80.3

[ghost]

@Minerdog123 commented on Oct 23, 2018, 3:23 AM UTC:

I have the same issue as you. The problem also seems to persist further into the iOS realm where I am unable to sign into the app, safari can't find the server, and chrome can't find the server. Relavent information about my install: Hass.io V80.3 running on Ubuntu 18.04.
Error when I try to access from Firefox(also running on Ubuntu 18.04)
2018-10-22 23:19:42 ERROR (MainThread) [homeassistant.components.http.data_validator] Data does not match schema: required key not provided @ data['client_id']
When I try to load on Chrome, Safari, and the iOS app I am told that the server could not be found and nothing appears in my Hassio logs. Hope this helps the developers.

[ghost]

@mretallack commented on Jan 4, 2019, 8:41 AM UTC:

Hi, Am also getting this on 0.84.6 with Firefox, it seem to work with Chrome. It works ok with the TOTP disabled, but as soon as its enabled, it causes the same problem:

The first POST to login_flow succeeds, this is the password + username request, however the second one fails.

The POST request to login_flow fails with an error 400 Bad Request, the params is shown blow:

Looking at the code:

home-assistant/homeassistant/components/auth/login_flow.py

Line 28 in ead38f6

| | { |

it shows that there should be more in the POST request.

This is very strange, I can see the TOTP request being constructred via the Firefox Network view,

But it is not received, Wireshark shows the initial POST containing the Password and username, it also shows the TOTP code POST request and the OK 200, but this does not get to the browser.

I think this is somthing to do with using Apache as the frontend reverse proxy, just not sure what.

[ghost]

@mretallack commented on Jan 4, 2019, 9:57 AM UTC:

Also the Firefox console reports:

The only error at the server end is:

hass[30240]: 2019-01-04 08:48:53 ERROR (MainThread) [homeassistant.components.http.data_validator] Data does not match schema: required key not provided @ data['client_id']

[ghost]

@sblantipodi commented on Jan 13, 2019, 2:48 PM UTC:

same problem here, Google Home integration is broken now.
Always worked well before 0.85

[ghost]

@QubitInfinity commented on Jan 22, 2019, 9:14 AM UTC:

Also experiencing same problem when exposing HA as tor onion service
Pi 1 B+
Hasbian
HA 0.86.0b0

[ghost]

@tottka commented on Feb 26, 2019, 3:46 PM UTC:

My problem started with release 0.88 and on the EDGE browser.
Is there a work around?

[ghost]

@ndonegan commented on Feb 26, 2019, 11:57 PM UTC:

Seeing the same with release 0.88 and Firefox. The Web Developer Console shows that the client_id is getting passed up with the POST data.

[ghost]

@ndonegan commented on Feb 27, 2019, 1:49 AM UTC:

This seems to be specific to Firefox. In my case, I'm running it from a virtual env over HTTP. When I look at the web console I see:

TypeError: NetworkError when attempting to fetch resource.' in the web console. The resource in question is onboarding-ed29f25b.js:2189:1138 which is an attempt to POST to /api/onboarding/users and failing. I'm not seeing an attempt to connect to that URL on the Pi running Home Assistant.

With Chromium, this just works.

[ghost]

@awarecan commented on Feb 27, 2019, 5:36 AM UTC:

What version of Firefox are you using?

Please see my comment in home-assistant/home-assistant-polymer#2828 (comment). To archive better user experience, you have to use the latest version of FireFox (and manual turn on two preference), FireFox 63 is the first version officially support ShadowDOM (although you still need turn on the support by yourself). FireFox 61 maybe the lowest version you can try. Please change to use Chrome if your FireFox version is lower than 61 (include FireFox ESR 60).

dom.webcomponents.customelements.enabled
dom.webcomponents.shadowdom.enabled

EDIT: FireFox ESR 60 can work with default config after fix apply

[ghost]

@ndonegan commented on Feb 27, 2019, 7:27 AM UTC:

Confirmed using Firefox 60 ESR. Just to be clear, there's no user experience with 0.88 where it worked with 0.87 without issue, and from tottka's comment above there's similar issues in Edge. I upgraded to 0.88 a few days ago without issue, and it's only when I had to log back in again that this issue appeared.

This looks very much like a nasty bug likely to unexpected affect users after they upgrade, and which will only be seen during a fresh login attempt. Is there anyway to turn off the ShadowDOM and Custom Elements requirements causing this?

[ghost]

@kouzinopoulos commented on Feb 27, 2019, 7:30 AM UTC:

I am also having the same issue. Home Assistant 0.88.1 on a RPI 3 with virtualenv, trying to access it over the Tor network from Linux

[ghost]

@Strixx76 commented on Feb 27, 2019, 12:40 PM UTC:

Same problem here. Can not login with:
Chrome on iOS
Safari on iOS
Edge on Windows 10

Don't dare to log out from Chrome on Windows 10 to try to login again!!!

Home Assistant 0.88.1 in virtual environment on Ubuntu 16.04.5 LTS.
No 'auth_providers' in configuration.yaml

[ghost]

@awarecan commented on Feb 27, 2019, 4:36 PM UTC:

The resource in question is onboarding-ed29f25b.js:2189:1138 which is an attempt to POST to /api/onboarding/users

ndonegan please open a new issue to address this, it is different than the OP's issue. Mixed different issue together just let us hard to analysis.

[ghost]

@awarecan commented on Feb 27, 2019, 4:39 PM UTC:

Strixx76
I don't have chance to test on iOS, but I tried Edge on Windows 10 and there is no issue for me.

Please open a new issue (fill in all fields in issue template we are asking) if you have met problem on the browsers you listed. I want to limit this thread to FireFox only.

[ghost]

@ndonegan commented on Feb 27, 2019, 5:01 PM UTC:

awarecan You sure it's a different issue? Exactly the same errors appearing the logs, exactly the same error appearing in the client. I just happened to dig deeper into the web console log to see what was happening.

[ghost]

@awarecan commented on Feb 27, 2019, 5:13 PM UTC:

I am sure yours are different. mretallack 's research back to Jan 4 pointed to the root source (or at least that is the same symptom we can still observed today), and it is different than yours. And it is not new issue at all.

[ghost]

@Strixx76 commented on Feb 27, 2019, 7:41 PM UTC:

awarecan Got it working in Edge. I guessed it was the same problem since it was messing on different computers and devices with the same error message. But the Edge problem was solved by deleting all browser data.
But the problem persists on iOS. Created a new issue for that.

[awarecan]

So, the login actually worked, the issue is frontend UI got refreshed before the backend data return. The error message required key not provided @ data['client_id'] was caused by the refreshed page missing client_id.

I doubt different async event handler processing on different browser cause that problem, prevent default event behavior seems fixed issue.