SignedCookieJar and PermanentCookieJar properly delegate everything to parent_jar #6745

Closed
wants to merge 3 commits into from

5 participants

@fxposter

Earlier it was not possible to do cookies.signed.delete or cookies.permanent.clear, cause this and other methods were not properly delegated to parent jar and were called on SignedCookieJar (or PermanentCookieJar) itself, which raised errors. Now SignedCookieJar and PermanentCookieJar can be used anywhere, where regular CookieJar is acceptable.

@steveklabnik
Ruby on Rails member

Won't making them not CookieJars anymore cause things to break? Or were these the only methods that were being used by the parent class? Basically, I'm not sure why you removed the inheritance.

@fxposter

@steveklabnik Try to call PermanentCookieJar#delete - if there is inheritance - it will not work at all. if we remove inheritance - this call will be properly dispatched to parent cookie jar.

@rafaelfranca
Ruby on Rails member

This needs a rebase. @spastorino @NZKoz what do you think?

@spastorino
Ruby on Rails member

👍, but @fxposter can you rebase?.
We now also added encrypted cookie store so the same thing needs to be done for that

@fxposter

I'm sorry, I could not easily rebase these changes against current master, but I'll do it today or tomorrow.
And yes, I saw encrypted cookies jar class, so I'd like to know, what is the real public interface of CookieJar classes.

Cause my changes only properly propagate everything to parent cookie jar, which is okay for #delete or #clear methods, but actually fail for #update (so cookies.signed.update will not get the signed part really working).

Also, #signed_using_old_secret should only be available on cookies, or cookies.permanent should also get it?

@fxposter

I had time to walk through current CookieJar code. As I understand, the real public interface of CookieJar is [], []=, delete, clear, key?, has_key?, deleted? and subclass creation methods: permanent, signed, encrypted and signed_using_old_secret (is this meant to be chained?).

@fxposter

So, as long as I understand - we can run all calls except [] and []= through method_missing chain.

fxposter added some commits Jun 15, 2012
@fxposter fxposter SignedCookieJar and PermanentCookieJar properly delegate everything t…
…o parent_jar

Earlier it was not possible to do cookies.signed.delete or
cookies.permanent.clear, cause this and other methods were not properly
deletegated to parent jar and were called on SignedCookieJar (or
PermanentCookieJar) itself, which raised errors. Now SignedCookieJar and
PermanentCookieJar can be used anywhere, where regular CookieJar is
acceptable.
fa46aa1
@fxposter fxposter Add more cookie tests 52a4346
@fxposter fxposter Add even more cookie tests, fixed InvalidMessage exception scope ba7d38a
@fxposter

Rebased, and added more tests. /cc @spastorino

@spastorino
Ruby on Rails member

@fxposter what we would need to just allow [], []=, permanent, signed and encrypted. And deprecate method_missing without doing anything. Doesn't make sense to do cookies.signed.delete, just do cookies.delete

@fxposter

But in that case we can allow users to pass any cookie object (signed or encrypted) to any part of the system without having to know if it is a signed cookie or the default one..

@rafaelfranca
Ruby on Rails member

@spastorino are there blockers for accept this pull request?

@spastorino spastorino was assigned Dec 23, 2012
@spastorino
Ruby on Rails member

@fxposter not sure I follow what you mean. My english is terrible. /cc @NZKoz
I don't see any problem of doing what I've said. Try to explain again please :)

@fxposter

The main reason I want this to be submitted - is that I want methods like #clear and #delete and others to be accessible through other cookie jars (encrypted, signed, etc) and not only through default one.
Use case is simple - If I make a library, which needs to do something with cookies - I can pass cookie jar object to it and it can set or delete values to it. I want the user to have ability to pass any cookie jar to it:

class MyLibrary
  def initialize(cookies)
    @cookies = cookies
  end

  def do_something_useful
    @cookies.delete(:wrong_key)
  end
end

# in controller
MyLibrary.new(cookies).do_something_useful
MyLibrary.new(cookies.signed).do_something_useful
@NZKoz
Ruby on Rails member

The problem I have with that use case, is that passing the signed cookies jar is incredibly misleading because:

cookies[:not_signed] = "hello"
cookies.signed.delete(:not_signed)

I'd personally say that exposing delete and clear to the other cookie jars is likely to lead to people thinking "I can call clear because it'll only ever clear the signed cookies" and being horribly surprised. The other cookie jars should probably just expose [] and []= and leave the rest to the top-level cookie jar.

@spastorino
Ruby on Rails member

agree with @NZKoz that's what I wanted to do. Sorry for my broken english :P

@fxposter

@NZKoz what do you mean by "leave the rest to the top-level cookie jar"? Now if I try to call cookies.signed.clear it will raise NoMethodError: undefined method 'each_key' for nil:NilClass, which is really confusing.

@NZKoz
Ruby on Rails member

I think that the signed jar simply shouldn't respond to clear or delete at all, so the NoMethodError is fine, but the message is clearly confusing

@spastorino
Ruby on Rails member

I would do something like this https://gist.github.com/a8a1f6f58a040951cf7b
But better programmed ;). Could be nice to make it more DRY.

@spastorino
Ruby on Rails member

I've committed the code for now 2b773e1 we can start refactoring. I have plans to make all the cookies code better because the current status it's not good and my commit is not making it any better ;)

@spastorino spastorino closed this Dec 31, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment