Use base64 encoding for usernames in http headers (shinyproxy specific) #123
Conversation
…g if the result is not UTF8 (i.e. if the string was initially not encoded)
LDSamson
force-pushed
the
ls_use_base64_encoded_usernames
branch
from
6ac735d to
a22a5b5
Compare
|
Not really familiar with what's going on here. Are you encoding the values into base 64 in the deployment and this PR is just decoding/checking those values? |
|
Is the first test an example of a user name that would have caused issues previously? |
|
Yes exactly, to both of your questions. See the news description. I now ensure that all user names are base 64 encoded in shinyproxy, and then they need to be decoded in the app. This PR will do just that (decoding the user names). The provided user name in the test indeed previously caused issues. |
| @@ -46,6 +46,7 @@ Imports: | |||
| tools, | |||
| withr | |||
| Suggests: | |||
| base64enc, | |||
There was a problem hiding this comment.
I have mixed feelings about this but since we are including base64enc in the suggests, I think decode_base64() should at the very list check if the packaged has been installed. (I have mixed feelings because it is a dependency for other packages, so I can't really think of a scenario where it wouldn't be available.)
There was a problem hiding this comment.
It is a function that will only run in production. It should be installed already since the package bslib depends on it. What other reservations do you have for adding it in suggests, other than checking in decode_base64 a check if the package is installed?
I will add the check mentioned by you in the function.
Closes #125. HTTP headers can only contain ascii signs, which causes issues when using names with less common names. Therefore, a solution is that user names are base64 encoded by the application serving the app (usually
shinyproxy), and then decoded by clinsight once done.