Un-hide "UserTokenBuilder::set_csrf" from docs

[themasch]

This may be me misunderstanding how to use this lib, or not seeing the obviously correct solution, but right now I do not see a good solution to implement a authorization code flow in a server scenario without either keeping a map of active user session => UserTokenBuilder around, or storing the generated CSRF secret for a session, and re-creating the UserTokenBuilder and calling set_csrf when the redirect comes in.

What is the suggested way to implement this right now? Since set_csrf is doc(hidden) with a comment that we should preferably not use this, I assume its keeping the actual UserTokenBuilder in memory and "find it" so we have it around when the response comes in. This would - imho - be more complex than just serializing the CSRF token in a (encrypted & signed) cookie and reading that from the redirected response again. The UserTokenBuilder::generate_url method even returns the CSRF token which makes this pretty easy. I am getting mixed messages here ;)

Am I missing something obvious?

For me, right now, it seems like set_csrf should be displayed in the docs, or we need a UserTokenBuilder::new_with_csrf constructor that also accepts a pre-existing CSRF token (how to handle that in generate_url? Guess that is the reason for hiding set_csrf?).

[Emilgardis]

I think it would be ok to expose it, there's no real reason for the library to hide it.

[C0D3-M4513R]

I think it would be ok to expose it

I think it would be counter-intuitive to do so, because the generate_url method currently always overrides the csrf.

[Emilgardis]

you would only use it if you've already called generate_url though and didn't bother to carry the struct around, and only kept the csrf

[C0D3-M4513R]

My use-case was to get the csrf as a raw byte array with a compile-time known length for easier usage in a hashmap.
I have since just decided to just create the url manually and then later generate the struct, after I've already gotten the response.