A tiny test repo that simulates the Queenie service setup.
Find a file
2024-03-04 14:21:53 -08:00
src/bin setting the SameSite cookie policy to lax fixes the issue 2024-03-04 14:21:53 -08:00
.gitignore minimal session use example 2024-03-03 15:12:18 -08:00
.rustfmt.toml minimal session use example 2024-03-03 15:12:18 -08:00
Cargo.lock minimal session use example 2024-03-03 15:12:18 -08:00
Cargo.toml minimal session use example 2024-03-03 15:12:18 -08:00
README.md setting the SameSite cookie policy to lax fixes the issue 2024-03-04 14:21:53 -08:00

What is this?

I'm trying to replicate an issue I'm having with Tower Sessions, where the session seems to be missing data upon initial return from Stripe, but if you manually enter the URL, it works.

How to run

In order to demonstrate the issue, the "stripe" service must be run on a different origin than the "princess" service. The following will set that up:

cargo run --bin=stripe & cargo run --bin=princess -- http://$(hostname):4001/

Now visit http://localhost:4000/ and click the buttons. At the end, you'll end up at a page at http://localhost:4000/success and see the test data inserted in the initial get of /, or a message indicating failure. To see it succeed, run:

cargo run --bin=stripe & cargo run --bin=princess

and follow the buttons starting from http://localhost:4000/ again to the end.

UPDATE!

The issue I was having, where an inbound request would cause the cookie to not be read until manually triggering a load, was due to the default setting of the SameSite cookie policy to "strict". Setting it to "lax" fixes the problem. See https://web.dev/articles/samesite-cookies-explained

Why is it called "princess"?

Because it's the baby version of Queenie, a small service using the same crates that sends users to Stripe and then receives a redirect from there once a user has successfully paid. I just wanted to get a minimum test case.