Friends
I wish to run a Raspberry Pi with a touch screen displaying the home page, from Homeassistant OS
I have created a user for this client and a “long lived access token”
I am starting the browser (Chromium or Firefox) in kiosk mode, but it is opening the login screen
This is useless as there is no keyboard on the machine running the client
Can I utilise the access token from a script starting the browser kiosk such that it opens straight onto the dash board?
Am I going about this wrong?
What do you think a touch screen is?
Unhelpful, mate.
A 7-inch touch screen is not a user interface for browsing
Wow. You need to log in. A touch screen will help you do that. Once logged in, set it up.
Why did you mention a touch screen?
Color me confused!!!
You need to login at least once and check “Keep me logged in” otherwise there will be no user profile set. If you are being prompted to login every time, the cookie saving the user info is likely being blocked. You can test this with Chrome in incognito mode and see that you are prompted to login every time.
You need to be aware that what you want to do is insecure, so I expect that you totally trust anyone connected to your network.
If you set up the trusted_networks auth provider. If the instance only has one user, you can use the allow_bypass_login option to login that user by default if that user access Home Assistant from a specific IP/network. If you have multiple users, you need to check the trusted_users option in the documentation to designate which users will automatically login depending on the IP/network. For example, if your Home Assistant instance has only one user, the next example will login that user automatically from any IP (0.0.0.0/0 represents all possible IP addresses in the IPv4 address space).
homeassistant:
auth_providers:
- type: trusted_networks
trusted_networks:
- 0.0.0.0/0
allow_bypass_login: true
It’s normal that the first time you open the browser and connect to your HA you need to provide credentials.
If you don’t close the browser, your session stays active/you stay logged in to HA so no need anymore to fill in the user/pw.
Everybody here is missing the point. Sorry, maybe I was not clear.
What I want:
Finding “long lived tokens” I thought I had what I need. I could have a script on the client that starts the browser in kiosk mode and passes the token to bypass the login screen, which as I say is useless in this context.
This means the client can be shut down and restarted, re made if corrupted, any number of times.
Most of this can be achieved using a keyboard temporarily to enter credentials and then “remember me” works. It is my current solution
But:
This was possible once. Is it no longer possible?
AFAIK it was never possible before to log in via long lived access tokens. The o ly way to bypass the login is by trusted networks as mentioned before.
I however would suggest to at least set the ip network in this setting to your subnet (e. g. 192.168.0.0/24) or better the IP of the kiosk with /32 instead of /24. That way you’re still forced to login with other devices or when in another network, which is especially helpful if you access from the internet as well.
On the other hand, I can also recommend a multimedia keyboard for when you rebuild such systems here and there. There is one from Logi that I tegrates a touchpad for mouse. This is way more secure than using trusted networks.
Long Lived Tokens are used as authentication to call Home Assistant APIs, not to login in Home Assistant. What is the problem of using trusted networks? If you feel safe to expose an auth token in a script in that device, there should not be an issue authorizing the IP of the device to bypass the login screen and login automatically (assuming that you manually assign that IP to the device in the DHCP resolution of your router).
I am sorry you think security is tacky. It’s also necessary. Just because you don’t like it doesn’t mean it’s not required.
No this is not possible as you’ve tried… There is a concept of a trusted endpoint but I will not recommend it to anyone.
This could be what I am looking for
I am asking for a way to set up a device as a client where the trust is in the client.
If I set password in a browser installed on the client, that is what I’ve done, I want to do it at installation rather than first execution
I will look into "trusted networks ". I do not know yet what that means in HA context, can you point me at useful documentation?
It is not security that is tacky, it is using the login screen to enter data known at installation time, only on first run time, because I do not know how to enter it at installation that is tacky
Security wise IMO ir is no more secure to have the browser hold the credentials than a script.
Why not? If the client is compromised (it is pinned to the wall) access to the HA, using the profile for the client to use, is achieved.
That is literally what I want.
Just a note, it is not about “trust” but “security”, the client could be completely trustworthy but their system will be vulnerable.
I left a link above in my response.
That is precisely a security measure, so yes, you find that security measure tacky. 
That also has a level of insecurity, but bypassing the login is more insecure because that user will be able to login even if you delete all the current tokens or even if you change their password.
Because you are opening a security hole in the Home Assistant instance, this is not about the device client but about your Home Assistant instance.
Why waste time spending 20 seconds entering your login credentials once, when you can spend 2 days arguing about it?
Yes. But, you do NOT want to hear it.
That is on the face of it, nonsense
The token is (should be) tied to the same identity in HA as the password, and both are stored on the client . How is having a token stored in a client less secure than a login/password pair?
You keep saying "insecure " like a magic incantation. That does not make it so.
It looks like I could writte a bespoke script to use the API directly (I have moved on from this now, so I will not) how is that less secure than a bespoke script that sets off a web client?
Having credentials stored in a client, in whatever form, has the same issues no matter how those credentials are stored. That is the issue on the face of it, and there is nothing said here that changes that.
None of the previous can be achieved with a token exposed in a local script.
I am telling you what is insecure because it is one of the fields in which I have certain expertise. It is not insecure because of magic, it is insecure because it is. But it is up to you to listen or not.
Both are insecure if they are stored locally. Secrets should be used in a hidden way, for example, on CI pipelines stored as env variables, not stored locally accesible by anyone with access to the device without the proper rights.
That is true, you should never store secrets in the clients, I don’t recommend that (and nobody has recommend that in this thread). It seems that you are confusing letting a session open (which is also insecure but much less insecure) than writing secrets in a file in a device (something that can be copied, stolen, distributed, and used later from another device even without you noticing it).