Any chance to make this work for “specific ip adresses”?
Use a condition:
alias: Dismiss login failure notifications from specific IPs
description: ''
trigger:
- platform: state
entity_id:
- persistent_notification.http_login
to: notifying
condition:
- condition: template
value_template: >-
{% set ns = namespace(ips=["192.168.1.1", "12.123.234.123"], found=false) %}
{% for ip in ns.ips if ("(" ~ ip ~ ")") in
state_attr("persistent_notification.http_login","message") %}
{% set ns.found = true %}
{% endfor %}
{{ ns.found }}
action:
- delay: '00:00:01'
- service: persistent_notification.dismiss
data:
notification_id: http-login
mode: single
NOTE: The above is a rather large edit of my prior condition template and multiple IPs example. The earlier version of my post had two issues: it was too naive about checking for exact IPs (would have matched 192.168.1.1 and 192.168.1.12 for instance) and the multiple IPs example I guessed at wouldn’t actually have worked. Both of these are now corrected for and tested. Add as many IPs to the array as needed. The array will be looped over and check the notification message for each of the ip(s) surrounded by parentheses (this makes sure the exact IP gets matched). If a match is found, the condition will be true and automation proceeds, and if not it will stop there and the notification will not be automatically dismissed.
6 Likes
Just wanted to draw attention to my earlier reply, as I had some errors in the condition code. I believe they’re all solved now, see my above reply for updated automation.
2 Likes
I’ve been running a HAOS install for close to two months and I got one of these notifications this morning.
Going to have to catch up on the thread here for more context, but is the root cause of these being investigated? A “bandaid” automation, while awesome, doesn’t really seems like a fix?
My understanding is that “something” hits the webserver? The request isn’t authenticated and we get a notification? Would it be possible to only send the notification if an actual authentication request failed, as opposed to just a web request failed, which could have it’s own optional notifications? I suppose that kinda creates an un-authed API builder with HA at the same time…
The notification I got today supposedly came from a Roku Ultra, it’s been setup just about as long as the HAOS install and hasn’t caused this notification in the past. It’d be a slim chance the Roku’s been compromised or tried to actually login to HA, as it doesn’t really have a browser. It’s possible it might have a bunch of autodetection/snooping and maybe that trigged a web request, maybe during a pushed update or reboot. I would have assumed to see this notification sooner though?
In worse case someone could be spoofing my Roku, which I still can’t really rule out.
This honestly cost me some time investigating and I’d really like to be able to trust such notifications rather than try to script around them.
The best way to solve this would be to add a configuration for a threshold value, below which there is notification. If there are 2-3 attempts in an hour, I dont care. If there are hundreds, I would like to know.
1 Like