Open jeremybmerrill opened 1 year ago
Welcome back @jeremybmerrill! 😁
Could you elaborate a bit on how this helps your scenario? Is the idea that your Klaxon instance is already so walled off from the world that you are all using the same email to login and it's whatever, so you want it to have like a 999 day expiration?
More or less! We rely on SSO/firewall to keep out bad guys. So, we're not relying on Klaxon's auth for that. Klaxon's auth is being used just to make sure that by default when I set up an alert, it goes to me and when you set up an alert, it goes to you.
That means we just don't need to re-auth to Klaxon very often. The upside of this change is one less login screen for users (who already log into SSO a zillion times a day), for all visits after the first each N days (we'll probably set this var to 365. Chrome caps cookie expirations at 400 days). The worst case downside to this change is an alert goes to the wrong person (in a situation where you logged into Klaxon on my machine 6mo ago).
Hi y'all -- Github informs me it's been six years since I interacted with this repo :) Hope everyone's doing all right.
I dusted off my old Ruby skills to submit this pull request which will let cookie expiration be set with an env var. We have an internal setup that's gated by the SSO platform and the firewall, so we're relying on the built-in auth exclusively for making sure emails go to the right place. Please let me know if this is a bad idea!