3 ms·

WebServerUid: Easy Unique Browser IDs for Rails

20 points by geweke 13y ago

geweke 13y ago
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. ;)
- 100k 13y ago
  And now you never need to solve it again! :)
- jcampbell1 13y ago
  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 13y ago
    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 13y ago
      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 13y ago
        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 13y ago
        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.
- callmeed 13y ago
  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 13y ago
    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.
josegonzalez 13y ago
This is similar to the Sysadvent 2013 post by TR Jordan on using an `X-Trace` header to track users across your stack: http://sysadvent.blogspot.com/2013/12/day-5-gentle-introduction-to-x-trace.html http://sysadvent.blogspot.com/2013/12/day-5-gentle-introduct...
- geweke 13y ago
  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.

20 points by geweke 13y ago

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

100k 13y ago
And now you never need to solve it again! :)
jcampbell1 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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 13y ago
        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.
callmeed 13y ago
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 13y ago
  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.

josegonzalez 13y ago

This is similar to the Sysadvent 2013 post by TR Jordan on using an `X-Trace` header to track users across your stack: http://sysadvent.blogspot.com/2013/12/day-5-gentle-introduction-to-x-trace.html http://sysadvent.blogspot.com/2013/12/day-5-gentle-introduct...

geweke 13y ago
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.