I’m doing a fresh install of OH on a PI4. My OH2.4 ubuntu laptop bricked. I’ve gone though the install steps, created an admin user via web UI. When I log in, all I get is a gray screen. The openhab.log file is pretty verbose, so not practical to post whole thing. Here are first few lines. There are several hundred ‘at …’ that follow.
Blockquote
2021-01-24 18:02:16.171 [ERROR] [core.io.rest.auth.internal.JwtHelper] - Error while initializing the JWT helper
java.lang.NullPointerException: null
at java.io.StringReader.(StringReader.java:50) ~[?:?]
My intent was to do a vanilla install right out of the instructions. I’m guessing abuser error. I would have done openhabian, and actually have it downloaded, but I’m fuzzy on whether there are different versions for Pi4 vs 3. Installer that came with the PI suggested here was.
I have got the same gray screen, after upgrading OH2.5 to OH3.
I am using openhabian, and did also the upgrade with openhabian.
At the first time running http://localhost:8080, I could create an admin account. But when I log in with this account, then I only recieve a grey screen.
Any suggestions, what I can do?
Same problem here on OH 3.0.1.
I’m not able to login via the local Ip adress: https://192.168.0.2:8448/
(the port is correct)
But I’m able to login as admin from an personal domain mydomain:8448 (port is forwarded in the fritz!box)
What is wrong here?
When I delete in CSS the visibility: none; then I see instead of a grey screen this:
Same problem as here. I seem to remember it was another service listening on another port on the same machine setting an invalid cookie - cookies are name=value so simply secure is indeed not a valid one - which would make the CookieHeaderProvider crash. Not sure what can be done.
At least clearing the cookies (or try in an incognito/private window to make sure) should have worked.
Strangly it doesnt help.
Neither clearing ALL cookies nor Incognito solves it on Chrome for me now.
If I use Edge I can log in to Admn area of Main UI.
Chrome and Edge are both based on Chromium, so this must be something Chrome sends. When you return from the auth page find the token?setCookie=true in the developer tools’ Network tab and check what you have in the response headers, especially the Set-Cookie header. It should look like this:
So you do have a Cookie: secure header, which is an invalid format since it has no “=”; therefore it looks like it wasn’t properly cleaned or set again immediately after somehow.
Seems similar to here:
You may have a device running on the same IP address, maybe another port, like a camera, and it sets an invalid cookie like Set-Cookie: secure (the actual syntax is Set-Cookie - HTTP | MDN) and then the Java implementation of the cookie parser doesn’t like it. There’s no way to change that.
Without more details on your environment, what runs on the machine, I can’t help further.
Well I also the IP Camera Binding you are referring too.
This binding exposes all camera feeds (in my case a still image) on: http://openhabIP:PortCanBeConfiguredForEachCamera/ipcamera.jpg
So is this a issue of the binding probably? @matt1 could you comment if you see a workaround?
it likely is … the cam images are on my front page and called right away.
Edit: I tried Still Image and MJPEG for a test on my Front page.
I removed the MJPEG widget and can log in to Admin now.
So its likley related as @ysc outlines above to the camera binding any !maybe! to MJPEG channel?
I suspect it is the widget causing it and not the binding. You could find an online mjpeg feed and use that with the widget for testing amd if it still occurs then you have a way to possible reproduce it without your camera. Posting the code for the widget may be helpful.