Various auth related fixes

[florian-h05]

Fixes #4354: Implicit user role disabled breaks Main UI.

Fixes a regression from #3575 with reverse proxy-based AA. The more advanced error handling in App.vue::fetchData`` is designed for XHR, not fetch`.

Also simplifies the auth.ts & auth-mixin.js code by always sending an access token with SSE and removing the getRequireToken() method.

[florian-h05]

@jsjames This should be backported to 5.2.x.

[relativeci]

#6043 Bundle Size — 13.89MiB (~-0.01%).

2c594f0(current) vs 6e95b9c main#6036(baseline)

Warning

Bundle contains 2 duplicate packages – View duplicate packages

Bundle metrics   1 change 1 improvement

	Current #6043	Baseline #6036
Initial JS	1.47MiB(~-0.01%)	1.47MiB
Initial CSS	0B	0B
Cache Invalidation	0%	0%
Chunks	843	843
Assets	983	983
Modules	2743	2743
Duplicate Modules	0	0
Duplicate Code	0%	0%
Packages	122	122
Duplicate Packages	1	1

Bundle size by type   1 change 1 improvement

	Current #6043	Baseline #6036
JS	11.57MiB (~-0.01%)	11.57MiB
CSS	907.43KiB	907.43KiB
IMG	638.41KiB	638.41KiB
Fonts	526.1KiB	526.1KiB
Media	295.6KiB	295.6KiB
Other	847B	847B

Bundle analysis report Branch florian-h05:auth Project dashboard

---

^{Generated by RelativeCI Documentation Report issue}

[Nadahar]

@florian-h05 Did you even look at what I did in #4365? I bet it's pretty much the same things.

[Nadahar]

Ok, I see that you have changed things much more drastically. I actually got the existing logic to work by fixing the fact that it didn't pick up on 401s where it should.

[Nadahar]

If there's no need to ever do SSE without a token, your simplification makes sense - I just don't know if that's the case. The existing logic allows not keep sending the token when the implicit user role is enabled. I don't know if the bandwidth use is of any relevance.

[florian-h05]

Did you even look at what I did in #4365? I bet it's pretty much the same things.

No, I didn't look at it yet because its add-on related fixes acc. to its title and I decided to look at it later.

Ok, I see that you have changed things much more drastically.

While looking at issue #4354 I noticed that not only the 401 detection is broken, but very likely the whole detection of reverse proxy authentication in front of openHAB, so I reverted the changes I considered problematic as well.

I don't know if the bandwidth use is of any relevance.

I don't think it is of any relevance.
I guess when implicit user role is enabled, a good part of Main UI users isn't logged in, so there is simply no access token to send with the SSE request.
If a user is logged in, we send the token with every normal HTTP request -- SSE requests ultimately are HTTP requests that expect an event stream as response type, so it doesn't really differ. Also, an SSE connection is not established that often (the tracking list is updated through a separate HTTP request that carries the access token).

[Nadahar]

No, I didn't look at it yet because its add-on related fixes acc. to its title and I decided to look at it later.

It's not always easy to name a PR. What the PR is, is me browsing around in MainUI and finding warnings and errors in the browser console, which I then address. It started out with doing that for add-ons against my core PR for add-ons, but those changes are just a few ?s here and there. But, when I found issues in the console that wasn't related to add-ons, I dealt with them as well.

So, it's more of a "universal warnings and errors fixes" PR. It should be very easy to review, the only thing in it that isn't immediately obvious is that I made it stop trying to reconnect SSE if it fails because of invalid credentials. There is just no point in it doing that over and over again, causing "error logging" on both sides. To fix it, the user must log in, after which new SSE's will be initialized, so that particular connection will never connect.

[Nadahar]

I don't think it is of any relevance.
I guess when implicit user role is enabled, a good part of Main UI users isn't logged in, so there is simply no access token to send with the SSE request.
If a user is logged in, we send the token with every normal HTTP request -- SSE requests ultimately are HTTP requests that expect an event stream as response type, so it doesn't really differ. Also, an SSE connection is not established that often (the tracking list is updated through a separate HTTP request that carries the access token).

I'm just wondering why it was made that way in the first place. I agree that it shouldn't matter to send the token for those few requests, but when I see something like this, I always assume that there's a reason I don't know about, so I try to make it work without changing what I don't understand. But, I agree with the assessment, it's very hard to see why it would serve any purpose, and the code can be simplified without it.

[jsjames]

LGTM

[Nadahar]

I hope you guys are planning on backporting this, we can't wait for 5.3.0 to make MainUI work with the implicit user role is disabled.