Using app access the url_pathname returns the endpoint it (old issue went back)

[dylancis]

Hi @fmichielssen ,
It seems that an old issue you took care of a few years ago went back recently: #102

Using latest ShinyProxy version, while using app/ access the session$clientData$url_pathname now returns the pod id:

app_proxy/7b8d7c0d-4d1a-4bf7-b15d-a15d09ab9c38/?guid=6c912f3b-3cb2-4277-bffd-ab6ce289b798

With app_direct/ access it does shows the expected firendly name /app_direct/eurmbsinsight/

Thanks, Dylan

[rac359]

Yes, this creates an issue for server-side bookmarks as well. The generated bookmark URL includes the pod id using app_proxy/, which prevents bookmark URLs from loading after the pod has terminated. Using app_direct/ seems to work correctly as @dylancis pointed out.

[LEDfan]

@dylancis this has changed in ShinyProxy in 3.0.0, because it's needed for various features of ShinyProxy (multiple app instances, app pre-initialization, crash detection, shinyproxy operator etc). For what reason do you need the friendly URL names?

@rac359 server-side bookmarking should work, even with these URLs. E.g. using the following app configuration:

    - id: shiny-bookmarking
      container-image: bookmark-server
      track-app-url: true
      container-volumes:
        - /tmp/shiny:/root/euler/shiny_bookmarks

The URL in browser will automatically update with the new hash and the user can easily bookmark this. This keeps working when the app or shinyproxy is restarted. If you have a button that generates a URL with the bookmark, you'll have to change it to use the URL that is shown in the browser.
Even if ShinyProxy would internally use /app_direct, this would be needed, since otherwise the bookmark would load the app without the ShinyProxy navbar (and without any of the client-side features).

[dylancis]

@dylancis this has changed in ShinyProxy in 3.0.0, because it's needed for various features of ShinyProxy (multiple app instances, app pre-initialization, crash detection, shinyproxy operator etc). For what reason do you need the friendly URL names?

@rac359 server-side bookmarking should work, even with these URLs. E.g. using the following app configuration:

    - id: shiny-bookmarking
      container-image: bookmark-server
      track-app-url: true
      container-volumes:
        - /tmp/shiny:/root/euler/shiny_bookmarks

The URL in browser will automatically update with the new hash and the user can easily bookmark this. This keeps working when the app or shinyproxy is restarted. If you have a button that generates a URL with the bookmark, you'll have to change it to use the URL that is shown in the browser. Even if ShinyProxy would internally use /app_direct, this would be needed, since otherwise the bookmark would load the app without the ShinyProxy navbar (and without any of the client-side features).

The app has a feature to share unique model run among users.

url.app <-
    paste(session$clientData$url_protocol,
          "//",
          session$clientData$url_hostname,
          sep = "")
  if (session$clientData$url_port != "") {
    url.app <-
      paste(url.app, ":", session$clientData$url_port, sep = "")
  }

[rac359]

@LEDfan

Hm, that's not the behavior I'm seeing. I've enabled track-app-url in the YAML file but the URL in the browser does not change. I've worked around this issue. Thanks for getting back to us users, and all the work you do for ShinyProxy!

[LEDfan]

@dylancis in that case it's best to generate an url to https://your-instance.com/app/<myapp>/... When users click on this URL they benefit from all client-side features. If you want to dynamically generate the URL in your app, you can pass the base url to your app using an environment variable (see container-env). Using SpEL expression you could even fetch the protocol and host from java (https://shinyproxy.io/documentation/spel/)