Issue Initialising OpenComposer

[james-s-willis]

Hi, thank you for creating OpenComposer I really like the interface!

I have been testing it on our OOD cluster and have a problem with the initialisation process.

When clicking on the OpenComposer app for the first time I get:

then when I click "Initialize App" I get a 404:

Now if I replace "http" with "https" OpenComposer initialises and it works fine. I'm wondering if it is my reverse proxy settings in OOD that is causing the issue. Have you seen this before? Do you have any clues what is going wrong?

Thanks,

James

[mnakao]

Thank you for your interest!
This is the first time I’ve seen an issue like that.

A very simple solution is to add the Open Composer URL to your manifest.yml.

# manifest.yml
url: https://<OOD>/pun/dev/OpenComposer

If you want to find a fundamental solution, you need to find out whether the problem is caused by Open Composer itself or by the reverse proxy.

$ cd ${HOME}/ondemand/dev
$ mkdir test
$ (EDIT) config.ru
$ (EDIT) app.rb

# config.ru
require_relative 'app'
run App

# app.rb
require 'sinatra/base'

class App < Sinatra::Base
  configure :development do
    set :host_authorization, { permitted_hosts: [] }
  end

  get '/' do
    "Hello World"
  end
end

If you experience the same problem with the code above, the reverse proxy is likely the cause.

Best regards,

[james-s-willis]

Thanks for your quick response!

I tried adding:

# manifest.yml
url: https://<OOD>/pun/dev/OpenComposer

like you suggested, it goes to the initialise page as normal at https but after clicking "Initialize App" I get the 404 again at http://<OOD>:443/nginx/init?redir=%2fpun%2fdev%2fOpenComposer.

I also tried the test app, but it doesn't show up in my list of apps even under the Sandbox section.

Cheers

[james-s-willis]

Here's my ood_portal.yml:

listen_addr_port: 8080
port: 8080
servername: "https://<OOD>"
proxy_server: "<OOD>"
security_csp_frame_ancestors: https://<OOD>
auth:
  - "AuthType shibboleth"
  - "ShibRequestSetting requireSession 1"
  - "RequestHeader edit* Cookie \"(^_shibsession_[^;]*(;\\s*)?|;\\s*_shibsession_[^;]*)\" \"\""
  - "RequestHeader unset Cookie \"expr=-z %{req:Cookie}\""
  - "RequestHeader set X-Forwarded-Proto \"https\""
  - "Require shib-user"
  - "Require shib-attr ccServiceAccess trillium-access"

# Use Shibboleth logout
logout_redirect: "/Shibboleth.sso/Logout?return=https%3A%2F%2F<OOD>"

# Capture system user name from authenticated user name
user_map_match: '([^@]+)@alliancecan.ca'

# Log files
errorlog: "<OOD>_error.log"
accesslog: "<OOD>_access.log"

host_regex: '[\w.-]+'
node_uri: "/node"
rnode_uri: "/rnode"

# Redirect to register page if user is authenticated but does not have a Trillium account
map_fail_uri: "/register"
register_uri: "/register"
register_root: "/var/www/ood/register"

# Attempt to fix proxy errors by increasing the no. of retries (Default: 5)
pun_max_retries: 10

# Maintenance mode
use_rewrites: true
use_maintenance: true

Likely - if you've never booted a passenger app, then you've never seen it. It doesn't have anything to do with opencomposer specifically.

Ah, I've never booted a passenger app outside the default passenger apps.
Thanks I really appreciate your help in this Jeff!

[johrstrom]

OK - now I'm wondering where port 443 is coming from and guessing it's from the proxy? Maybe you've uncovered a bug here as it appears you're using a proxy.

Confirm this for me -

• you're connecting to https://<OOD>/ (implicit port 443)
• your proxy is terminating https and contacting the actual instance at http://<internal hostname?>:8080 over plain http.

I think I see what's happening here - apache sees plain http request and sets the redirect URL accordingly, unbeknownst to it that the proxy is using https not http.

That said - if our lua scripts are setting the port to 443 that suggests to me that the proxy is actually forwarding requests to apache on that port as well. So there's something still funny to me about that - like maybe the 8080 configurations are ignored or unused and apache is listening and serving on port 443.

As you can see in my output above to boot a PUN in a demo container - apache is using 8080, but also the redirect URL is also 8080, so there's something amiss here.

[james-s-willis]

• you're connecting to https:/// (implicit port 443)
• your proxy is terminating https and contacting the actual instance at http://<internal hostname?>:8080 over plain http.

I think this is correct, we're using a Traefik reverse proxy for this but I will need to confirm with my colleague who set that up.

[james-s-willis]

So it is a bit complicated:

the backend is actually https. This is because we have a consul connect sidecar to handle mTLS and acl.
The sidecar is an envoy proxy running in the same job and talking to the "real" backend service port 8080 on plain http.

When I look in /var/log/httpd/<OOD>_error.log I see entries like this:

[Mon Nov 10 07:48:53.497755 2025] [lua:info] [pid 108:tid 213] [client 127.0.0.1:56926] req_handler="proxy:http://<ood_node>:41366" allowed_hosts="https://<OOD>,<OOD>"

they're always from 127.0.0.1 because of the proxy.

I see we have made it complicated with the proxy. Do you know of a good way to debug this?

[james-s-willis]

I was able to fix this issue by creating a OpenComposer.conf file in /var/lib/ondemand-nginx/config/apps/sys:

#/var/lib/ondemand-nginx/config/apps/sys/OpenComposer.conf

location ~ ^/pun/sys/OpenComposer(/.*|$) {
  error_page 404 @error_404;
  alias /var/www/ood/apps/sys/OpenComposer/public$1;
  passenger_base_uri /pun/sys/OpenComposer;
  passenger_app_root /var/www/ood/apps/sys/OpenComposer;
  passenger_document_root /var/www/ood/apps/sys/OpenComposer/public;                                                                         
  passenger_enabled on;                                                                                                                      

  passenger_app_env production;

  # Give apps the ability to download files from filesystem
  passenger_env_var HTTP_X_SENDFILE_TYPE X-Accel-Redirect;
  passenger_env_var HTTP_X_ACCEL_MAPPING "/=/sendfile";
  passenger_set_header X-Sendfile-Type "X-Accel-Redirect";
  passenger_set_header X-Accel-Mapping "/=/sendfile";
}

So that it looks in the system apps path. I imagine I can do something similar for sandbox apps too.

[johrstrom]

Now if I replace "http" with "https" OpenComposer initialises and it works fine.

Seems like you just need to use https. Looks like you're trying to access on port 443, so I'm not sure why you're trying to access it over plain http. This is the scheme you're using to access apache with, not the PUN or apps that the PUN starts.

Seems like you've turned use_rewrites off in ood_portal.yml? In any case, it seems to me like you just need to use https.

[james-s-willis]

I agree I need to use https, but the "Initialize App" button is defaulting to http for some reason. In ood_portal.yml I have use_rewrites: true. I have no issue with any other app apart from Open Composer and after I initialise it by changing the address to https there is no issue with it from then on.

Also, why do I need to initialise this app and not the other interactive apps that I have set up, e.g. Jupyter and RStudio? Is it because it's a Passenger app?

We run OOD as a container that gets restarted roughly once a week for updates. Does this mean that users will have to initialise Open Composer at least once a week?

[johrstrom]

Hmmmmm... there is something off here. But it's not due to any OpenComposer issue (hence my getting involved). It does appear to be some issue with Open OnDemand. It's likely something simple that we're just missing.

How are you accessing this link? Is it though the dashboard -> my sandbox apps -> Launch Open Composer or are you entering the URL by hand?

We run OOD as a container that gets restarted roughly once a week for updates. Does this mean that users will have to initialise Open Composer at least once a week?

No, it's this file that you're trying to 'initialize'. Our RPM packages do this for us, so you don't have to. That's for a system app - for a dev application, it's in another location but even so, only needs created & modified once.
https://github.com/OSC/frame-renderer/blob/4d3b252de8e1b91246d8eb8d70e7cae3f4f47577/packaging/frame_renderer.spec#L66

[james-s-willis]

How are you accessing this link? Is it though the dashboard -> my sandbox apps -> Launch Open Composer or are you entering the URL by hand?

From the dashboard I go to Apps -> All Apps -> Open Composer. Which I have as a Sandbox App in ~/ondemand/dev.

Now I also have Open Composer in /var/www/ood/apps/sys/OpenComposer but I have it disabled with Unix permissions:

drwx------.  1 root root 4.0K Nov  3 12:32 OpenComposer

in case you think that may be interfering. I re-enabled the /var/www/ood/apps/sys/OpenComposer and tried opening that in OOD, but I get the same 404 that I get with the dev instance.

[johrstrom]

So the URL is has a direct relationship with the directory it's under. I.e., ~/ondemand/dev/foo would be /pun/dev/foo. Maybe it's as simple as uppercase throwing this all off?

First, let me know the directory in ~/ondemand/dev you've cloned this to and if ~/ondemand/dev/open_composer works better.

[james-s-willis]

I had it as ~/ondemand/OpenComposer. I renamed it to open_composer.

That changes the addresses to https://<OOD>/pun/dev/open_composer (on clicking on the app) and http://<OOD>:443/nginx/init?redir=%2fpun%2fdev%2fopen_composer after clicking "Initialize App", but I still get the same 404 error after clicking on the "initialise" button.