feat:add configurable state

[shtayerc]

List of common tasks a pull request require complete

• Changelog entry is added or the pull request don't alter library's functionality

[DeepDiver1975]

Can you please explain under which circumstance this is of interest? Thx

[shtayerc]

I want to know which requests belong together. Right now the state is generated on the fly, so it is not possible to save it before authenticating and matching it after. Also, with this pull request it is possible to pass additional data with state (jwt for example).

[azmeuk]

I am not very comfortable with the state being a fixed string. Wouldn't it be better to set a custom user function that would be called to generate the state instead?

[shtayerc]

@azmeuk yes, custom function is more flexible. I changed the code.

[michaelcerne]

This would be beneficial to a project I am working on.

We need a reasonable way to identify a user before and after authentication without the use of additional session data.

[azmeuk]

I wonder if that callback function should take parameters, such as clientID. This is an open question, I don't really have an advice, but I think this should be thank early to avoid break compatibility if we find this will be needed in the future.
What do you think?

[michaelcerne]

@azmeuk Looking at the codebase... the primary class is architected as a singleton, thus you can receive the clientId by calling getClientID() on the instance where the callback was set, negating most of the need for this, no?

I suppose maybe this would have use if you were to create a number of different "clients" and then utilize the same callback method for all. In that case, I would imagine the easiest (and most versatile) solution would be to simply pass the entire client class as a single parameter. All (public) interfaces would be accessible.

I am not sure if this is favored from a stylistic perspective.

[dmlang]

Hi everyone, is there anything new about this pr? It would also be beneficial for my use case.
Thanks!

[DeepDiver1975]

I am more in favor of overloading method implementations by sub classing - all these callables are highly type-unsafe.