Signed and Permanent Cookies in Rails 3 | Hacker News Reader

Signed and Permanent Cookies in Rails 3

m.onkey.org

19 pointslonestar11 comments

Looks like a cool feature, but I haven't yet gotten into Ruby or Rails. I do have one question, though. There is an interesting looking language feature I see: 20.years.from_now.utc. I would presume that to mean "20 years from this time in zulu". So presuming that 20.years.from_now.cdt means central daylight time, is that a different time?

To put the question a little shorter, isn't the concept of "20 years from now" independent of time zone, or am I missing something?

    irb(main):033:0> 20.years
    => 20 years               # ??????
    irb(main):030:0> 20.years.to_i
    => 631152000              # number of seconds in 20 years
    irb(main):026:0> 20.years.from_now
    => Sun Feb 10 10:14:11 +1100 2030 # AEDT
    irb(main):027:0> 20.years.from_now.utc
    => Sat Feb 09 23:14:14 UTC 2030   # UTC/GMT

Ruby Time instances have a timezone, calling Time#utc returns the instance time converted from localtime -- or whatever timezone it is -- to UTC or Greenwich Mean Time. You are correct in that it shouldn't matter which one you use in this situation though.

Your first one, commented with ??????, is an instance of a Duration object. It implements the #ago and #from_now methods, so that Integer objects aren't cluttered with methods that mean nothing to it.

http://api.rubyonrails.org/classes/ActiveSupport/Duration.ht...

It's independent of time zone. 20 years from now in any time zone will be the same "time" (in an absolute sense), but it will look different to different time zones. For example, it might look like 6:00pm for me and 5:00pm for you, but it is still the same time if we both convert our local times to utc. A Time object in ruby stores time zone, so 20.years.from_now.utc looks like this:

Sat Feb 09 23:07:46 UTC 2030

I feel like I'm not understanding something. How is this "signed"? It appears they're just storing the user's salt in their cookie... in which case you might as well store any other random info, it doesn't mean it's "signed", it just prevents people from changing their cookie's user_id and logging in as someone else. Didn't they already have something like that in place?

Usually signing a cookie means adding a HMAC to the end of it so the user can't modify the contents without invalidating it. The example given seems kinda misleading, because including the salt offers some measure of protection against tampering anyway.

See, that's signing. That has a lot of use, and there are a lot of ways to make that however secure you want. The example doesn't seem to do any of that, though, it's simply storing two user-specific details, one of which the user shouldn't know. Or, at least, one which other users wouldn't know.

Again, that's unless I'm missing something.

"A whole lot easier" Is this a joke?

I don't understand your objection.

1. Rails already makes things very easy. 2. The improvement was for something that (yes, subjectively) did not look overly burdensome to begin with.

Cookies with MACs did in fact get substantially easier, that was in fact a feature people regularly screwed up, and the fact that you have to manually arrange to expire user-based cookies when passwords change is a sign that there's still work left to be done.

The more of this functionality Rails takes over and stops leaving up to developers, the happier I'll be.

Reply on news.ycombinator.com