I also get this, and it is always caused by a known app or browser. If they are local, I see the device’s address, if connected through the cloud I get 127.0.0.1 (local). I can’t figure out where this would be coming from.
Thomas
I also get this, and it is always caused by a known app or browser. If they are local, I see the device’s address, if connected through the cloud I get 127.0.0.1 (local). I can’t figure out where this would be coming from.
Thomas
Well, I’ve very very recently (pending for release 0.115) implemented a change that allows Home Assistant to access the current web request. So, I guess we now can do things like the actual browser/client info as of just now.
I run Hass behind a reverse proxy, so all my login failures come from the reverse proxy docker IP address. It would be nice if the “real” IP address could be shown instead.
Geo-ip resolution would be cool too.
Something like this?
The user agent will only be added if it is available.
Well that library can parse elements out of it, but other than just displaying there is no goal to parse it (+ since the http
component is a core requirement, adding that library extends the core requirements, which we should avoid unless absolutely necessary).
That is possible, if you set it up correctly. Make sure you set the X-Forwarded-For headers in your proxy, enable the use_x_forwarded_for
option on the http
integration and set the trusted_proxies
configuration option so Home Assistant will process those headers when a request from your proxy comes in.
Alright:
Implemented, merged and this improvement will be part of Home Assistant Core 0.115
Whitelist IP’s so they won’t get banned, ever
Done. These failed attempts are mostly false (is my experience. Mostly comes from the devices that have the HA app. When I open them, they login just fine. Is this caused by an expired token, because those should not pop up as failed attempts imho.
The problem for me (like many others it seems) is that these failed requests come from known clients using the web UI. They just appear sometimes in the Notifications, but from my perspective, all the clients are working as expected and have never been otherwise.
In other words, for this message to be meaningful, we probably need to know WHAT uri was requested and what was wrong with the supplied credentials. Were no credentials supplied? Were they expired? Or was it just a lovelace card with a typo in some URI it’s requesting?
As @niro1987 said, if it’s just an expired token which gets auto-refreshed, then it probably shouldn’t be listed as failed attempt, but right now without details logged, it’s just a blind guess.
Im pretty sure it is something like an expired token, because it pops up when I open an idle tab with HA in chrome.
Edit: and with me it is always showing with the same (docker) IP address “Login attempt or request with invalid authentication from 172.30.33.7” (supervised install)
That sounds like you are using a reverse proxy and haven’t configured Home Assistant for a reverse proxy.
Oh thanks for pointing that out, this is the first time I hear about that you need to setup your instance for reverse proxy, maybe also good to put that information on this page? https://github.com/hassio-addons/addon-nginx-proxy-manager/blob/1ec5f456166b4f7a419038e74155ae1cb79884e3/proxy-manager/DOCS.md
I’m not running a reverse proxy. These messages all come from normal browsers or iOS apps on my lan that I used to normally access hass without login failure or anything.
Great improvement Frenck! Cant wait to see who’s logging in
what about the invalid logins from ones own 192.168.1.1 address… those are the ones I see most frequently, while I did set that as an allowed address in the trusted_networks. Would those be trackable too?
Yes! Looks good.
In my case it’s the mjpeg streams which already has an open issue to fix. But this helps a lot to know what or who is trying to get in
My invalid 127.0.0.1 login attemps sometimes comes from, my Lovelace view where I have defined the cameras… I think it’s somekind of refresh issue with some old token… Will this also be resolved with that new PR?