actix-web: Cookie parser fails for certain characters
Hey,
I noticed some cookies always appear as None
in req.session()
(despite being in the Cookie header), depending on what characters are being used apparently.
Quick example :
let payload = "hello";
let value = req.session().get::<String>("test");
println!("Value found in headers : {:?}", value); // Ok(Some("hello"))
let res = req.session().set("test", payload);
println!("Set result : {:?}", res); // Ok(())
// send response
Run this a couple times and everything works as expected. Header looks like this :
actix-session=zsf1hIJu4CLUesyWHTQ/pedxPET4eqHjO5AQpvOawMU={"test":"\"hello\""}
Now if I change the payload, this is what happens :
let payload = "FJc%26continue_url%3Dhttp%253A%252F%252Fconnectivitycheck.gstatic.com%252Fgenerate_204"
let value = req.session().get::<String>("test");
println!("Value found in headers : {:?}", value); // Ok(None)
let res = req.session().set("test", payload);
println!("Set result : {:?}", res); // Ok(())
Header looks like this :
actix-session=dQxdyG08q5mLMu0Q6KAysLEtYbM/Uak/neM5L3QDj0Y={"test":"\"FJc%26continue_url%3Dhttp%253A%252F%252Fconnectivitycheck.gstatic.com%252Fgenerate_204\""}
It seems like the session middleware never picks up this value for some reason. I assume this is an encoding issue. This happened while storing a URL, my current workaround is to base64 encode the payload and everything works fine.
Any idea what could be causing this ?
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 16 (12 by maintainers)
Both cookies shown in the first post are invalid, as you can’t have backslashes in cookie values:
https://tools.ietf.org/html/rfc6265#section-4.1.1 https://tools.ietf.org/html/rfc2616#section-2.2
Either they should either be magically percent-encoded, or refused by cookie-rs
@DoumanAsh I feel like we’re working around the problem rather than addressing it here.
With your proposed fix, if someone attempts to put some invalid characters in the store (either by inadvertence or simply because they might be unaware of the consequences), then we’re back to square one :p
The way I see it, we can do one of the following things :
Option 2 should be pretty straightforward to implement (decode the session payload when a request arrives, encode it before sending the response) and would effectively prevent this sort of things to happen again. Although this should be transparent to most users, it might be considered a breaking change. What do you think of this solution ?