I'm the author of this gem -- more than happy to help out with it.
The problem it solves is small but important, and this is now the third company at which I've solved it...so I'm sure there are more folks out there dealing with this same issue. ;)
Besides analytics, seems like this could help SaaS products that want to offer a trial or demo without ever creating an account up front–just spin up an account on the fly with the uid. If they actually signup, marge their real info.
Sure thing -- I built it because I needed it, but I'm really happy to be able to share it, too.
You definitely could use this for trial/demo accounts, too. You'd want to think carefully about abuse prevention, I suspect, but in the right circumstances it could be a really lightweight way to handle this.
Really good point. Even better, I'd really like these cookies to be digitally signed (like Rails' session cookies are by default), so that they're unforgeable.
Seems like it wouldn't be too terribly hard to add to nginx...hmm... ;)
What, in particular, is problematic about them? Do you mean their particular implementation, the fact that they aren't also encrypted, or the general "password equivalent in a cookie" concept overall?
Yeah, the one ring to rule them all problem. One bad employee, or one of the many rails zero-day issues, potentially compromises the site indefinitely for all eternity.
Nice! Thanks for turning me on to that -- I've been looking for something like that.
I actually think they're pretty different problems. WebServerUid is about uniquely identifying a single browser over hours, days, months, or years, while X-Trace is about tracking a single request over its (hopefully) single-second-at-most lifecycle -- but they're both really useful, and I'm glad you posted that link.
The problem it solves is small but important, and this is now the third company at which I've solved it...so I'm sure there are more folks out there dealing with this same issue. ;)