[geweke]

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. ;)

[callmeed]

This is cool, thanks for building this.

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.

I'll definitely be trying this out.

[geweke]

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.

[100k]

And now you never need to solve it again! :)

[jcampbell1]

This is a good technique to know. I feel like that cookie should be HTTP only though. It looks like nginx doesn't support that out of the box.

[geweke]

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... ;)

[jcampbell1]

They should be secure random strings, no need to sign.

BTW, rails signed session cookies are terrible from a security perspective. Thank god Github has moved away from them.

[geweke]

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?

[jcampbell1]

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.