Open julesair opened 2 years ago
The state should not be user input, it should be created and used by the app only
The state should not be user input, it should be created and used by the app only
Yes, agree. I did not express myself correctly in the previous message. With user
I meant myself, a developer using this library and defining how the state is computed. Not the end user.
There is no protection against a developer using characters in the state string (e.g. a base64 string), that need to be encoded when used as query parameter in the url. Also it is not documented, that the state needs to be encoded before handing it over to this function. In my opinion it would be a small change, that should not break existing usages of the function, but reduces the probability of unexpected behavior. I patched the library for my use case, but would like to not have to patch it
hello @julesair thank you for presenting this to us. I have filed a ticket for our team to look into making this change.
Link to PR: https://github.com/docusign/docusign-esign-node-client/pull/288
Use case: when using a base64 encoded string, the value read from the location path when the user is redirected is not always the same as the one given to
getAuthorizationUri
.Like the redirectUri, the state is an user input and as such not safe to be used in an url without escaping certain characters
Can we use
encodeURIComponent
on the state parameter?