Hey, thanks for fixing the variable name! I would prefer not to add .secret() as it suggests users should directly compare the secret as a string using ==, which would create a timing side-channel vulnerability.

To avoid introducing the vulnerability, the comparison must be done in constant time, either using a constant-time crate like constant_time_eq (which could break if a future compiler version decides to be overly smart about its optimizations), or by first computing a cryptographically-secure hash (e.g., SHA-256) of both values and then comparing the hashes using == (see #232).

The timing-resistant-secret-traits feature flag adds a safe (but comparatively expensive) PartialEq implementation to the secret types. Timing side-channels are why PartialEq is not auto-derived for this crate's secret types, and the lack of PartialEq is intended to prompt users to think more carefully about these comparisons.

I would suggest either only fixing the variable name, or adding a separate section about securely comparing secrets such as the CSRF state, and then referencing it in each example.

Thanks so much for the thorough feedback! Fixed instructions to compare just against csrf_token. Sent #246 for the additional docs.

Thanks!