UniFi Protect: Unable to authenticate with UniFi OS 4

[darkpixel]

The problem

I have been unable to authenticate to UniFi Protect over the last few releases of Home Assistant.

If I use the same username and password to sign in to the console, it works fine....even from an incognito window which means this probably isn't related to their cloud / 2FA stuff.

What version of Home Assistant Core has the issue?

core-2024.5.2

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

unifiprotect

Link to integration documentation on our website

https://www.home-assistant.io/integrations/unifiprotect/

Diagnostics information

Unfortunately I removed my Protect integration and tried to re-add it as part of troubleshooting, but it fails to add--so I can't enable debug logging for the unifiprotect integration and drag and drop the file here. You'll have to settle for a snippet I copied earlier.

2024-05-08 10:27:22.167 DEBUG (MainThread) [pyunifiprotect.api] Successfully loaded session from config
2024-05-08 10:27:22.168 DEBUG (MainThread) [pyunifiprotect.api] Request url: https://192.168.42.192/proxy/protect/api/bootstrap
2024-05-08 10:27:22.193 DEBUG (MainThread) [homeassistant.components.unifiprotect.config_flow] Request failed: /proxy/protect/api/bootstrap - Status: 401 - Reason: {'code': 401, 'message': 'Unauthorized'}
2024-05-08 10:27:25.013 DEBUG (MainThread) [pyunifiprotect.api] Successfully loaded session from config
2024-05-08 10:27:25.013 DEBUG (MainThread) [pyunifiprotect.api] Request url: https://192.168.42.192/proxy/protect/api/bootstrap
2024-05-08 10:27:25.016 DEBUG (MainThread) [homeassistant.components.unifiprotect.config_flow] Request failed: /proxy/protect/api/bootstrap - Status: 401 - Reason: {'code': 401, 'message': 'Unauthorized'}

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant]

Hey there @AngellusMortis, @bdraco, mind taking a look at this issue as it has been labeled with an integration (unifiprotect) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of unifiprotect can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign unifiprotect Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

unifiprotect documentation
unifiprotect source
_{^{(message by IssueLinks)}}

[CajuCLC]

I was able to get the debug, not much:

2024-05-08 13:39:06.698 DEBUG (MainThread) [pyunifiprotect.api] Successfully loaded session from config
2024-05-08 13:39:06.699 DEBUG (MainThread) [pyunifiprotect.api] Request url: https://192.168.0.95/proxy/protect/api/bootstrap
2024-05-08 13:39:06.725 DEBUG (MainThread) [homeassistant.components.unifiprotect.config_flow] Request failed: /proxy/protect/api/bootstrap - Status: 401 - Reason: {'code': 401, 'message': 'Unauthorized'}

If I try to load https://192.168.0.95/proxy/protect/api/bootstrap on my browser, it gives me a warning for the SSL (expected). On HASS I didn't select to verify SSL, but it seems like it is trying to. And trying to load with HTTP just redirects to HTTPS:

curl -I http://192.168.0.95/proxy/protect/api/bootstrap
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Wed, 08 May 2024 18:44:35 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Location: https://192.168.0.95/proxy/protect/api/bootstrap

I have a Kubernetes cluster where I have SSL enabled for my pods and one of the services I run there is one to setup domains and redirects traffic to the service. So I have a local domain with SSL enabled and that worked for me. Debug log below (removed sensitive data).

2024-05-08 13:42:16.691 DEBUG (MainThread) [pyunifiprotect.api] No existing session for XXXXX
2024-05-08 13:42:16.691 DEBUG (MainThread) [pyunifiprotect.api] Request url: https://nvr.MYDOMAIN.local/api/auth/login
2024-05-08 13:42:17.166 DEBUG (MainThread) [pyunifiprotect.api] 200 application/json <ClientResponse(https://nvr.MYDOMAIN.local/api/auth/login) [200 OK]>
XXXXX

2024-05-08 13:42:17.167 DEBUG (MainThread) [pyunifiprotect.api] Authenticated successfully!
2024-05-08 13:42:17.167 DEBUG (MainThread) [pyunifiprotect.api] Request url: https://nvr.MYDOMAIN.local/proxy/protect/api/bootstrap
2024-05-08 13:42:17.360 DEBUG (MainThread) [homeassistant.localponents.unifiprotect] Connect to UniFi Protect
2024-05-08 13:42:17.374 DEBUG (MainThread) [pyunifiprotect.api] No existing session for XXXXX
2024-05-08 13:42:17.374 DEBUG (MainThread) [pyunifiprotect.api] Request url: https://nvr.MYDOMAIN.local/api/auth/login
2024-05-08 13:42:17.713 DEBUG (MainThread) [pyunifiprotect.api] 200 application/json <ClientResponse(https://nvr.MYDOMAIN.local/api/auth/login) [200 OK]>
XXXXX

2024-05-08 13:42:17.713 DEBUG (MainThread) [pyunifiprotect.api] Authenticated successfully!
2024-05-08 13:42:17.714 DEBUG (MainThread) [pyunifiprotect.api] Request url: https://nvr.MYDOMAIN.local/proxy/protect/api/bootstrap
2024-05-08 13:42:17.846 DEBUG (MainThread) [pyunifiprotect.data.nvr] Reading release cache file: /config/.storage/unifiprotect/release_cache.json

[randybb]

Looks like this is related to the latest update. Unifi OS was just updated from v3.2.12 to v4.0.3 and HA is not able to authenticate anymore.

[darkpixel]

LOL--ok. Just ignore it. In a week or so it'll be a production version.

[darkpixel]

Maybe someone should modify the bug template to mention that so people don't waste their time reporting bugs in the wrong place.

I'm using early access to help test not only Ubiquiti's software and provide feedback, but to also help test with things like Home Assistant integration.

[CajuCLC]

For me it is failing with OS 3.2, which is not EA. Changing to a SSL domain with a valid SSL worked fine.

[redfoxert]

Do you have a dot (.) in the username by any chance? I've ran into the same issues with my Unifi Protect integration after updating to 4.0.3 Unifi OS. It seems the integration fails when the username of the account includes a dot. After changing the username to one without a dot, it worked again.

[CajuCLC]

Do you have a dot (.) in the username by any chance? I've ran into the same issues with my Unifi Protect integration after updating to 4.0.3 Unifi OS. It seems the integration fails when the username of the account includes a dot. After changing the username to one without a dot, it worked again.

When I tested yesterday I was still on OS 3.2. I upgraded to OS 4.0.3 this morning and using a domain with a valid SSL still works.

[CajuCLC]

Stop talking about SSL. This issue has nothing to do with with SSL. It is because the cookie changed in 4.x making existing sessions incompatible. If you literally have any other issue with logging in, it is off topic.

You are an extremely rude person. If you don't like the community, don't write code for the community.
I have always seen how you respond to people and I have been just observing how you are so rude to people seeking help.

Either way, I was replying to other folks comments, not to you. If you have a problem with it, I don't care. Go be rude to someone else.

[fxstein]

I have the same problem for the past 2 days on Protect 3.0.26 on UniFi OS v3.2.17 both on the Official Release Channel

[CajuCLC]

It does not matter who you were talking to. You are contributing nothing to this conversation except confusing people. No one else has mention SSL issues. The issue is that upgrading to UniFi OS 4.0.3 can cause auth to stop working. The cause is because the session cookie was renamed.

You have already stated that the issue occurs on 3.2.x for you and upgrading to 4.0.x does not fix it. That further enforces your issue is 100% not related. Stop trying to introduce a completely unrelated issue onto this one and learn how issue tracking works.

I mentioned how I fixed it. It is STILL failing on OS 3.2, I just tested again. Someone else just commented that it's also failing for them.
For ME the fix was to use a valid SSL.

I also decided to run HASS and UniFi OS in a separate environment and it also failed to auth. Once I created a self signed certificate and made sure HASS trusted that certificate, then it worked.

Again, this is how I fixed it. If it's different for anyone else, then it's different for them.
For ME that was the fix.

[CajuCLC]

Again, THIS ISSUE HAS NOTHING TO DO WITH SSL. IT HAS TO DO WITH UNIFI SO 4.0.

If you have another issue, GO MAKE ANOTHER ISSUE. This one is NOT GOING TO BE REOPENED. No matter how much you complain. UniFi OS 4.0 is NOT SUPPORTED by this integration yet.

And while we are on the topic of your "fix" your whole fucking issue is probably because you checked the Verify SSL checkbox when you did not have one. But guess what? I do not have any way to know that because you are trying to stow away on an unrelated issue instead of making your own issue with your own logs and diagnostics.

The error is the same either on 3.2 or 4.0. I didn't check anything, I know how to read. I am not your typical person that is just using HASS and comes here often to ask for help.
You are really the type of person who gives the open source community a bad reputation. If you don't want to deal with people, then don't respond.
I am not asking to reopen any issue. I simply posted here trying to help others that might have the same issue.

What I find absurd is how HASS allows you to be a contributor when you like to curse at people, be rude, just because you wrote an integration that is being used by HASS.
Do better.

[johnypony3]

@AngellusMortis, I hope you don't speak like this in a professional setting.

[TheJulianJES]

Thanks for the report! Opening this issue back up for visibility (to avoid duplicate issues being created) and to help with tracking this for other contributors.

I want to note again that EA versions (of UniFi Protect and UniFi OS) are not supported by the HA integration.
However, we still need to get this issue fixed, as it'll become a GA release eventually.

And just a reminder: if you're experiencing the same issue but don't have new information to add to the issue, please just upvote the original post. "+1" comments only cause unnecessary notifications.

[Nixon506E]

I see that the fix for the authentication issue was in >6.0.0 of the pyunifiprotect library but there has been a falling out with the author of that library and the Nabu Casa devs leading to a license change and >6.0.0 not being merged.

@bdraco I am wondering if there is a near term solution for this or if the suggestion at the moment will be to not upgrade? Just hoping for a message to the community to assure us. Thanks!

[Bascht74]

I have the same problem now. Using 192.168.x.x doesn't work anymore for unifi protect.

[darkpixel]

Yeah...what the heck is that? That license change is pretty hostile....from the same @AngellusMortis who had some pretty angry/hateful comments in this thread. Not sure if he deleted his own comments or someone from Home Assistant deleted them, but he apparently decided to change the license for pyunifiprotect to specifically target home assistant for exclusion: https://github.com/AngellusMortis/pyunifiprotect/commit/2fcc0f61778767cb4db86f6b6b48ef5510e6faae

It's sad, but oh well.

[darkpixel]

Nowhere in my previous commend did I call you an "idiot developer that does not know what they are doing and a clown".

I'm not sure why you are so angry over a user requesting help.

Regardless, it's your code, so do as you wish. If I had the time, I'd fork the MIT licensed code and support it myself. But I don't have the time.

If you're struggling with anger issues, please seek professional help.

If I personally angered you, my apologies. That was never my intent.

[darkpixel]

Again, I apologize.
Please seek professional help.

[bharvey88]

You are the one fucking tagging me and targeting me right now. So, go fuck yourself.

You're better than this man. The situation sucks for everyone involved at this point and you making yourself look worse effects you the most. Go enjoy some free time man this isn't the way to get even or whatever.

[CajuCLC]

@darkpixel can you try using a valid SSL when configuring the integration?
It's working for me just fine with the EA 4.0.19:

And from NVR:

Within HASS:

[CajuCLC]

can you try using a valid SSL when configuring the integration?

Oh, look it is this fucking idiot again that does not understand how SSL and cookies fucking work. This issue still has nothing to fucking do with SSL, dumbass. It is only "appearing" to work because you are having your session and getting new cookies. But again, I do not know anything about the fucking code. I only wrote it.

https://github.com/AngellusMortis/pyunifiprotect/blob/v5.1.2/pyunifiprotect/api.py#L141-L145

#117100 (comment)

[darkpixel]

At the risk of further...annoying a certain user...I replaced the cert on my UNVR Pro with one trusted by Home Assistant and my local box and it immediately reconnected. Thanks @CajuCLC

EDIT: And the files on the UNVR Pro are /data/unifi-core/config/unifi-core.crt and ``/data/unifi-core/unifi-core.key```.

[zhazell]

Deleting user and creating a new one with a new name helped me ;-)

I tried deleting and creating a new local user, but the HA Plugin keeps saying "Invalid authentication"

[Shad0wWulf]

Deleting user and creating a new one with a new name helped me ;-)

I tried deleting and creating a new local user, but the HA Plugin keeps saying "Invalid authentication"

For me, I had to delete the integration and then add it back in with the new username and password. For me i used my NVR IP without a Valid SSL and it re-added it just fine. I did revert my doorbell image back to the default though, I don't see the option in the integration yet to have a custom so assume its still not supported. But atleast its back up and running again.

If you have any automations etc setup they should be retained, mine were anyway.

[bdraco]

Can someone running Unifi OS confirm that #119308 fixes this issue?

You can test that PR as a custom component using this one liner:

cd /config
curl -o- -sSL https://gist.githubusercontent.com/bdraco/43f8043cb04b9838383fd71353e99b18/raw/core_integration_pr | bash /dev/stdin -d unifiprotect -p 119308

Be sure to delete the custom component it will generate after upgrading to 2024.6.2

[u20p17]

@bdraco: works for me! Thanks!

Unifi OS v4.0.4, Protect v4.0.26, G4 Doorbell Pro v4.71.94

[paradizelost]

I applied as well, and working so far with 1 minor exception, the camera preview on the area card isn't pulling up the picture.
Unifi OS v4.0.3, Protect 4.0.21

[paradizelost]

Just had the authentication expired issue recur

[bdraco]

I'll leave this issue open in that case as it looks like more work is needed on the library.

Hopefully someone can contribute a followup fix.

I don't have anything running 4.x yet, but I'll take a look after I upgrade if it's not solved by then. That could be a while before I do upgrade my production so please don't wait for me.

[jasperslits]

For those with problems still, what’s in the logs?

[paradizelost]

Which specific log, i'm not familiar with where HA keeps that

[bdraco]

Which specific log, i'm not familiar with where HA keeps that

https://www.home-assistant.io/docs/configuration/troubleshooting/#enabling-debug-logging

[paradizelost]

I've got it enabled now, but its been a crapshoot on how often it happens and i'm not able to cause it on command, so might be a bit.

[frenck]

Should be fixed by Home Assistant 2024.6.2

[paradizelost]

Still no recurrence of the issue so not sure if the error message i had before was a false positive or not

[TheJulianJES]

Please keep monitoring and report back, as it may not be fully fixed. There might be an issue where the cookie isn't properly stored and reauthentication takes place leading to rate limiting at some point.

[paradizelost]

Its also possible that i had to re-auth once after the fix was in place, i've only had it pop-up the once time

[alexruffell]

Was told to provide my feedback here instead of #119308 so posting my same comment here (hope that is ok, and what I was expected to do) with a few minor tweaks:

I have a UNVR running 4.0.5 OS and Protect 4.0.33. I had several log messages related to authentication since I updated to the unsupported OS. I was able to somewhat mitigate the issue by re-authenticating using a new local user (the previous one would no longer work) and that stopped the repair issue about Unifi Protect Authentication however I still had several log messages about Protect.

Today, after updating to the latest core 2024.6.2 release that includes this fix, I deleted the Unifi Protect integration and added it back (for testing purposes) with the same HA local user and it worked flawlessly. I rebooted HA to check for Unifi Protect related logs, and there are none. If this is a sufficient test, I'd say the issue appears fixed. If not, please let me know what I need to do to test it. Glad to help.

[u20p17]

i just deleted the unifiprotect in my custom_components and updated to 2024.6.2

everything seems to work on my system. only minor issue now is that the EA-warning always reappear. there is already another issue opened #118134

[bdraco]

There is another cookie fix coming in #119436.

[bdraco]

Unless anyone is still have a problem after reauth, I think we can close out this issue.

[mukul-k]

Unless anyone is still have a problem after reauth, I think we can close out this issue.

Been working great since latest release. Thank you everyone for contributing and working through this!