From: “Trans” [email protected]
tracking that down, or did you just “see it” when looking over the
code?
Thanks 
I didn’t end up using your test case, because my
test suite for my online store controller already tended to
encounter the cookie problem every so often. (I had switched
to the MemorySessionStore awhile back as a workaround.)
So I went low-tech and put in some print statements and kept
re-running my test suite until the error occurred.
But I haven’t studied the rest of the code enough to understand
why the data in context.cookies[Session.cookie_name] is already
CGI.unescape’d (maybe it’s supposed to be.)
Regards,
Bill
data = Base64.encode64(Marshal.dump(session)).chop
data = CGI.escape("#{data}–#{generate_digest(data)}")
as you can see the diggest is generated before escaping, ie it is
unescapped just like when it read back.
am I missing something?
-g.
From: George M.
data = Base64.encode64(Marshal.dump(session)).chop
data = CGI.escape("#{data}--#{generate_digest(data)}")
as you can see the diggest is generated before escaping, ie it
is unescapped just like when it read back.
am I missing something?
I think the encode is fine. But:
def decode(data)
data, digest = CGI.unescape(data).split("–")
raise AlteredCookie.new unless digest == generate_digest(data)
return Marshal.load(Base64.decode64(data))
end
For whatever reason, ‘data’ passed to decode is already
unescaped. So calling unescape again seems to convert
‘+’ into ’ ’ (space).
E.g.
x = CGI.escape(“hey+there”)
=> “hey%2Bthere”
CGI.unescape(x)
=> “hey+there”
CGI.unescape(CGI.unescape(x))
=> “hey there”
Regards,
Bill
On Nov 13, 5:29 am, Timothy [email protected] wrote:
Anything more sensitive should be kept serverside.
I agree. I don’t think it wise to use a cookie for anything that needs
to be secure, other then a session key.
T.
I think the cookie session store is a great idea because it keeps the
(small) state to the client. So i can redirect the client to different
servers in my cluster w/o worrying about synchronizing state.
btw, bills fix seems to have solved the AlteredCookie bug! 
-g.
On Sunday 11 November 2007 14:24:54 Trans wrote:
couldn’t care less if anyone finds out my shoe size 
T.
Nitro-general mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/nitro-general
HMAC would be suitable for authentication of a message but how does
adding it
to cookies improve over using a single, random session id cookie and
storing
all sensitive data in a session store? Why would you want to
authenticate
messages to yourself when you could just keep them in your sight?
I’m aware that for some small things it could be advantageous to avoid a
roundtrip to a database due to frequent use but it’s these same,
frequently
used pieces of data that will be expensive to verify repeatedly. It is
common
to see user preferences in cookies because the user cannot do any harm
by
changing them. Such applications should assume that the user might do
so.
Anything more sensitive should be kept serverside.
Timothy
On Nov 13, 7:46 am, “George M.”
[email protected] wrote:
I think the cookie session store is a great idea because it keeps the
(small) state to the client. So i can redirect the client to different
servers in my cluster w/o worrying about synchronizing state.
Sure, i think it’s great too. But not for secure data.
btw, bills fix seems to have solved the AlteredCookie bug!
Yea!
Shall we add the bug he found as a testcase? We can use the one I put
together as a basis if need be.
T.
Shall we add the bug he found as a testcase? We can use the one I put
together as a basis if need be.
A test case (rspec) would be great. Can you handle it?
-g.