Credential Tool: Error while checking user account. Status Code: 400
gman-wa opened this issue ยท 34 comments
Trying this plugin for first time.
Dyson account is setup.
Logged out of app and logged in with email/password/code-from-email
Using the credential app on port 48000
Enter US and my email and get
Error while checking user account. Status Code: 400
Ideas? Is Dyson blocking this plugin?
I'm seeing this as well, but receiving a 401 instead of a 400.
mine now has a 401 as well
My error is:
Country code: "DE"
"Error while checking user account. Status Code: 401"
Same here.
Runing on a Raspberry Pi with arm64.
It comes in step2 after enter the account password and secure code from email.
EDIT: I changed my password of the Dyson Account and drag the new password in the credencials tool. It works directly.
Same issue, getting "Error while checking user account. Status Code: 401"
I'm getting the same issue.
Country: AU
"Error while checking user account. Status Code: 401"
EDIT: I re-installed the plugin and started the config fresh and it worked.
This plugin just became unusable as it gives error 401 on any device, container or browser. Even after reinstall and reboot. Can we fix this?
Also seeing Error Code: 401
Got it working!
- Logged out of the iOS app and logged back in.
- Rebooted Homebridge
- Re ran the credential tool
- Dyson fan now in HomeKit!
I have the same issue 400 error on step 1 after enter email and country.
Please help
The solution is one post above yours from jflow
I had the same issue but after logging out the dyson link up on my mobile it worked
(Weird though i recognized i did not loggout dyson link on ipad)
Hi,
Not using this project but a customised version of libpurecool https://github.com/qdel/libpurecool.
But anyway, i face the same problem and would be happy to share thougts.
I encouter the 401 at this line: https://github.com/qdel/libpurecool/blob/master/libpurecool/dyson.py#L90
Which is the same as yours here: https://github.com/lukasroegner/homebridge-dyson-pure-cool/blob/master/src/credentials-generator-website.js#L126
In my version, i call this query daily. And i put in cache all queries. (as the device credentials seems not to move...)
And this is where the fun starts:
- if i open the dyson app (not logging out / logging in at all, just open it!)
This call does not meet 401 anymore but 200.
The app is, maybe, making another call or transfering data allowing the webservices to be authorized.
Also seeing Error Code: 401
Got it working!
- Logged out of the iOS app and logged back in.
- Rebooted Homebridge
- Re ran the credential tool
- Dyson fan now in HomeKit!
This did not work for me. I am now back to the 400 response instead of the 401.
Logged out of the iOS app and logged back in.
Rebooted Homebridge
Re ran the credential tool
This also worked for me!
- ogged out of the iOS app and logged back in.
- Rebooted Homebridge
- Re ran the credential tool
- Dyson fan now in HomeKit!
Worked for me also!
Also seeing Error Code: 401
Got it working!
- Logged out of the iOS app and logged back in.
- Rebooted Homebridge
- Re ran the credential tool
- Dyson fan now in HomeKit!
This did not work for me. I am now back to the 400 response instead of the 401.
I was getting the 400 response also - found that I actually had to type "US" into the country field, even though "US" appeared in it as a default value.
Also seeing Error Code: 401
Got it working!
- Logged out of the iOS app and logged back in.
- Rebooted Homebridge
- Re ran the credential tool
- Dyson fan now in HomeKit!
This doesn't work me. I am running homebridge on mac and it still shows 401
Also seeing Error Code: 401
Got it working!
- Logged out of the iOS app and logged back in.
- Rebooted Homebridge
- Re ran the credential tool
- Dyson fan now in HomeKit!
This did not work for me. I am now back to the 400 response instead of the 401.
I was getting the 400 response also - found that I actually had to type "US" into the country field, even though "US" appeared in it as a default value.
That was the issue for me too. Didn't realize you needed to manually type in the country field.
Just wanted to comment in case anyone else finds this. Originally I didn't enter the "US" code in the first line of the credential page at http://localhost:48000
. I was receiving a 401
, and then eventually I received Too many API requests
.
I kept receiving the same Too many API requests
, even the next morning. I connected my pi and phone to a VPN and it let me try a few more times but after 2-3 tries I was getting the Too many API requests
error again.
What eventually worked was:
- Logged out of iOS app
- Logged into iOS app - left it at the screen where I enter my email code and password
- Ran the credential tool on phone
- Retrieved my password (it was a little tricky since Safari on iOS was not letting me copy/paste, but I saved the page as a PDF and then was able to copy/paste (and remove the spaces)
Not sure if the VPN helped or not, but wanted to mention in case anyone else is having difficulties.
Good luck!
I've changed the placeholder to "XX" instead of "US" in version 2.3.2, so that people do not mistake it for a prefilled value.
I can't seem to get anything other than an instant Error while checking user account. Status Code: 401
. No combination of Dyson app login status or homebridge restarting has returned anything different.
Any additional guidance, like turning on logging for this plugin? I am a developer, and would be happy to submit a PR with a fix, if there is one.
Just wanted to comment in case anyone else finds this. Originally I didn't enter the "US" code in the first line of the credential page at
http://localhost:48000
. I was receiving a401
, and then eventually I receivedToo many API requests
.I kept receiving the same
Too many API requests
, even the next morning. I connected my pi and phone to a VPN and it let me try a few more times but after 2-3 tries I was getting theToo many API requests
error again.What eventually worked was:
- Logged out of iOS app
- Logged into iOS app - left it at the screen where I enter my email code and password
- Ran the credential tool on phone
- Retrieved my password (it was a little tricky since Safari on iOS was not letting me copy/paste, but I saved the page as a PDF and then was able to copy/paste (and remove the spaces)
Not sure if the VPN helped or not, but wanted to mention in case anyone else is having difficulties.
Good luck!
This worked for me!
Still no idea how long this will work.
What if Dyson shut down their server.
How long is the session key valid?
Will a new session key be required if I change my Wi-Fi password.
Is there a fix for this at all? 401 every day, all day.
Is there a fix for this at all? 401 every day, all day.
I ended up going through the code and manually making all the API calls using Postman, and then using a little of the javascript code to get the local device key.
Is there a fix for this at all? 401 every day, all day.
I ended up going through the code and manually making all the API calls using Postman, and then using a little of the javascript code to get the local device key.
It's honestly so broken I just gave up and went back to my old plugin dyson link. Works immediately.
Same issue here, I always get 401.
Solution / Workaround
git clone https://github.com/shenxn/libdyson.git
cd libdyson/
pip3 install -r requirements.txt
python3 get_devices.py
test@58a05e4a89ee:~/libdyson# python3 get_devices.py
Please choose your account region
1: Mainland China
2: Rest of the World
Region [1/2]: 2
Region code: CA
Email: youremailhere@example.com
Password:
Verification code: XXXXXX
Serial: VS5-CA-XXXXXXXX
Name: Bedroom
Device Type: 438
Credential: XXXX
Serial: VS5-CA-XXXXXXXX
Name: Office
Device Type: 438
Credential: XXXX
Then manually create the base64 encoded JSON object that this project expects.
const deviceBody = {}
deviceBody.password = 'take result from Credential and write it here'
deviceBody.Name = 'Bedroom'
deviceBody.Serial = 'VS5-CA-XXXXXXXX'
deviceBody.ProductType = '438'
deviceBody.Version = 'ECG2PF.02.06.003.0002'
console.log(btoa(JSON.stringify(deviceBody)))
I was getting HTTP 400 back from both this and the libdyson tool at the command line, until I realised copying the OTP from the email was coming with a leading space. Making sure the leading space was removed when pasting in to the OTP field made it work.
Is there a fix for this at all? 401 every day, all day.
I ended up going through the code and manually making all the API calls using Postman, and then using a little of the javascript code to get the local device key.
Hi, I've got all the results from Postman, but I have no clue to extract the local device key from the localcredentials, can you share the javascript code? Thank you
Hi, I've got all the results from Postman, but I have no clue to extract the local device key from the localcredentials, can you share the javascript code? Thank you
Solution / Workaround
git clone https://github.com/shenxn/libdyson.git
This also no longer works for me as of May 2023.
The ONLY thing I got that could get credentials was:
- Log out of iOS devices
- Use https://github.com/libdyson-wg/libdyson-neon from @dotvezz
I finally got the credentials after days of 401.
gh repo clone libdyson-wg/libdyson-neon
cd libdyson-neon/
pip3 install -r requirements.txt
python get_devices.py
Got the creds ๐๐ป
Please choose your account region
1: Mainland China
2: Rest of the World
Region [1/2]: 2
Region code: AU
Email: my@email.com
Password:
Verification code: xxxxxx
Serial: A1F-AU-xxxxxxxx
Name: Bedroom
Device Type: 527
Credential: <creds received!>
This also no longer works for me as of May 2023. The ONLY thing I got that could get credentials was:
Hmm but they are not working :(
I even debugged the libdyson-neo
python call to /v2/provisioningservice/manifest
API endpoint, got the response payload for the device and ran it through the Javascript decode from this repo https://github.com/lukasroegner/homebridge-dyson-pure-cool/blob/master/src/credentials-generator-website.js#L635-L641
{
"Serial": "A1F-AU-xxxxxxxx",
"Name": "Bedroom",
"Version": "ECG2PF.30.06.003.0002",
"LocalCredentials": "xxx",
"AutoUpdate": true,
"NewVersionAvailable": false,
"ProductType": "527",
"ConnectionType": "wss"
}
decryptedPasswordJson.apPasswordHash
provides the same credentials as the output from libdyson-wg/libdyson-neon
and Homebridge plugin still logs bad credentials.
homebridge | [5/29/2023, 3:16:35โฏPM] [DysonPureCoolPlatform] Initializing DysonPureCoolPlatform platform...
homebridge | [5/29/2023, 3:16:35โฏPM] [DysonPureCoolPlatform] Homebridge API available.
homebridge | [5/29/2023, 3:16:35โฏPM] [DysonPureCoolPlatform] Credentials generator website started.
homebridge | [5/29/2023, 3:16:35โฏPM] [DysonPureCoolPlatform] Cached accessories loaded.
homebridge | [5/29/2023, 3:16:35โฏPM] [DysonPureCoolPlatform] Invalid device credentials for device with serial number A1F-AU-xxxxxxxx. Make sure you copied them correctly
So I'm guessing the credentials object this plugin is expecting is more than just the decrytpted password.
Hi there, I'm the (new) core maintainer of https://github.com/libdyson-wg/libdyson-neon. I can try to shed some light on the core 2fa authentication issue here, although I'm not sure about the specific credentials comment that I was pinged on.
I reverse-engineered the Android app to find out how it's able to work without the logout-workaround we're all stuck with. Turns out the Dyson App API has what I'm calling an "App Provisioning Step" which has caused the core issue here. It doesn't seem to be specifically intended as a security feature, but it does impact authorization against the App API.
There's an API endpoint on a "provisioningservice" path that we need to call before calling other endpoints. The return value is not needed, and we don't need to save any cookies or session tokens. It seems like the API Server sets some internal flag allowing API Calls from a specific address based solely on this endpoint being called.
It returns a version number in a json-encoded string: "5.0.21061"
and that is likely consumed by an app. Presumably, an official Dyson mobile app could check the version against some internal expected value and, for example, prompt a user that it is outdated and direct them to the app store to download a new version in order to continue working.
The endpoint I used to fix the logout workaround in libdyson-neon is https://appapi.cp.dyson.com/v1/provisioningservice/application/Android/version
.
It's super easy to implement a solution. I'll be happy to raise a PR if that's preferred. Or if the maintainers here would like to do it themselves, feel free to take inspiration from how I solved this issue in libdyson:
Hey @dotvezz - sorry maybe I shouldn't have pinged you. Just wanted to note that out of all the flows and libs to try and get credentials, yours was the only one that worked.
However the credentials generated for this project are not the credentials returned by your library (encoded device password), but the base64 encoded /v2/provisioningservice/manifest
response body:
https://github.com/lukasroegner/homebridge-dyson-pure-cool/blob/master/src/credentials-generator-website.js#L756
The flow on this project would not work with the new Dyson email MFA no matter what I did.
So I ended up using your repo, got the bearer token and accountid and generated the same output as the above code.
Essentially printing the final credentials object needed by this project by using the API bearer token I was able to get from your project.
I just ended up using a combination of a fork of your code, and some of the code from this repo to generate the credentials object needed for this Homebridge Plugin installation.
My results ๐๐ป https://github.com/lantrix/homebridge-dyson-pure-cool-credentials-generator
There are a lot of other users of this project (which I'm just an end user of) who seem to have the 401 auth issue with this app using its built in credentials-generator-website.js. For example #279 and #301
I'm sure the project creator @lukasroegner would welcome a PR to fix issues with the new (annoying) Dyson email based 2FA.
Turns out the Dyson App API has what I'm calling an "App Provisioning Step" which has caused the core issue here. It doesn't seem to be specifically intended as a security feature, but it does impact authorization against the App API.