Open LDSamson opened 1 month ago
Hi, as far as I know HTTP headers may not contain all UTF-8 characters, but only ASCII characters, see https://stackoverflow.com/questions/47687379/what-characters-are-allowed-in-http-header-values/48138818#48138818 . One way to work-around is to base64 encode the value (see https://shinyproxy.io/documentation/spel/#tips--tricks) :
- id: 01_hello
display-name: Hello Application
description: Application which demonstrates the basics of a Shiny app
container-cmd: ["R", "-e", "shinyproxy::run_01_hello()"]
container-image: openanalytics/shinyproxy-demo
container-network: sp-example-net
http_headers:
test_header: "#{T(java.util.Base64).getEncoder().encodeToString('ěšťůšěř Főřáťěš'.getBytes())}"
Thanks for providing this workaround, this indeed helps with this problem and I will apply it to our application in production.
In the long term, would it be possible to make shinyproxy
a bit more robust for these cases and, for example, create informative error messages if shinyproxy is asked to send non-ascii characters as http headers? Or, send a warning that the string is an invalid http header and send an empty string instead? I think this would be helpful for many shinyproxy users if their names consist characters less commonly used in English. If this is difficult to achieve, a small warning in the documentation about this problem would also already be helpful.
In my use case, my application will display a user name but will fall back to the email address if the user name is not available.
Yes, I agree ShinyProxy could handle this better. I created and internal ticket and we will improve this in the next release. In the meantime I added an example to the demo https://github.com/openanalytics/shinyproxy-shiny-demo-auth?tab=readme-ov-file#utf-8-characters and a note on the website: https://shinyproxy.io/documentation/configuration/#http-headers
To reproduce:
application.yml
by adding a http_header with special characters to the '01_hello' spec id:Now, the app named 'Hello Application' cannot be started anymore.
I stumbled upon this issue when users with special characters in their name tried to start an application but failed to do so. In our production version, I am extracting the name (witrh special characters) from an OpenID connect claim, but below shows the issue also occurs in shinyproxy with the demo shiny applications and simple login.
These are the ShinyProxy error logs: