Want to get started with Refactor Rails' Cookie Implementation and Improve Signing with Expiry

[Amarjeet Singh]

Hey!

I'm Amarjeet Singh Mudhar, intermediate RoR based web application developer pursuing CS from JIIT, India. I've prior experience of collaborating with others on github but that has always been restricted to small projects. Projects as big as RoR are quite honestly, overwhelming for me. 

But, I find Refactor Rails' Cookie Implementation and Improve Signing with Expiry and Purpose to be enticing. I need some starting point for Rails repo.

Thank you,

Amarjeet Singh Mudhar 

[Robin Dupret]

Hello Armajeet,

Actually, the description of this project has just been updated on the wiki, it was copy-pasted from last year's wiki and it was out of date.

You can contact Kasper for further information ; you can contact him checking out his GitHub profile.

Have a nice day. :-)

[Kasper Hansen]

Hey Armajeet,

Please keep questions to the mailing list. I doubt there's a thing we need to discuss that can't happen in the open. 😊

--
Kasper

[Amarjeet Singh]

Yes, for sure. 😊 

So Kasper, how should I start and proceed?

[Saurabh Sikchi]

Hi Amarjeet,

I am also interested in upgrading rails' cookie implementation. Go through this pull #28132 from the new wiki to get a general idea of how cookies in rails work and how to change that. I am also a fellow student who has benefited a lot from rails.

[Kasper Timm Hansen]

Hey there both of you, Amarjeet and Saurabh!

Yes, the proposal was just updated on the project wiki — and reading that pull is a start as it touches some of the files a student would be working on.

I or Robin will be happy to answer more specific questions if you have any :)

--

Kasper

[Amarjeet Singh]

Hey y'all!

I want to clarify something about backward compatibility. Are we talking about cookie part of the framework so that it can be used in rails 3,4,5 or about  the cookies of web apps based on older rails version should seamlessly work when app gets updated? And for backward compatibility what all rails version do we need to account for 4,5 or lesser also?

Is Google's SHA1 collision the motivation behind this idea as suggested in https://github.com/rails/rails/pull/28132 ?

[Amarjeet Singh]

Expiry time needs to be in control of developer, right?

On Friday, March 10, 2017 at 12:25:53 AM UTC+5:30, Kasper Hansen wrote:

[Kasper Timm Hansen]

Hey,

For backwardscompatibility we’d probably be looking at one or two releases back, though it’s possible we have to support earlier as well. We’ll do trade offs when we get to that.

The tough part about cookies is that they can survive more than one Rails release because a person who visited the site long ago, with an old cookie, could come back and thus the cookie must still be supported.

We want this to have better expiry built in to cookies and Google’s SHA1 collision has nothing to do with it :)

--

Kasper

[Kasper Timm Hansen]

Yep, exactly like the SignedGlobalID class handles it with both expires_in and expires_at. Same goes for the purpose via the for option.

--

Kasper

[Michael Coyne]

Hello,

I'm the author of the PR for AEAD. I'm definitely interested in exploring this sort of feature. It is long overdue for default Rails to support such a thing. I'm happy to help out anyway I can to see this sort of feature get implemented!