Connection View

The HTML template file view.html.erb is responsible for providing the user with a small web interface that makes connecting to the backend web server running on the compute node for a given interactive session as simple as possible. It is located in the root of the application directory. There are three ways to connect to interactive apps detailed below:

  1. VNC

  2. reverse proxy using full path node

  3. reverse proxy using relative path rnode

For a list of apps using each, please see Install Other Interactive Apps <>

Assuming we already have a sandbox Interactive App deployed under:


The view.html.erb configuration file can be found at:


The .erb file extension will cause the HTML file to be processed using the eRuby (Embedded Ruby) templating system. This allows you to embed Ruby code into the HTML file for flow control, variable substitution, and more.

This connection view will be retained for a week in ‘My Interactive Sessions’ for debugging purposes. The link to Session ID opens a files app directly to the output of the batch connect app.


If developing a VNC Interactive App, DO NOT include the view.html.erb file. The Dashboard has internal logic in place for displaying connection information of VNC sessions to the user.

Session Information

A running interactive session will generate a connection information file in the working directory of the corresponding batch job. This information is then made available to the HTML template view.html.erb when it is rendered. The possible connection information attributes are:


the hostname of the compute node that the interactive session is running on


the port number that the running web server is listening on


the password that the web server expects when authenticating the user

Typically these attributes are used to construct links or forms within the view.html.erb file. See the various Examples below.

Reverse Proxy

A detailed introduction to the reverse proxy can be found in Configure Reverse Proxy. Under a default installation the following URL paths will be enabled:

GET /node/(host)/(port)(path)

reverse proxies the request to the given host and port using the full and untouched URL request path


By visiting the hypothetical link below:

the following URL request:


is sent to the web server running on host and port 8080.

GET /rnode/(host)/(port)(path)

reverse proxies the request to the given host and port using ONLY the path portion of the URL request path


By visiting the hypothetical link below:

the following URL request:


is sent to the web server running on host and port 5000.


In order to leverage the reverse proxy that comes with Open OnDemand the system administrator must have it enabled as outlined under Enable Reverse Proxy. It only needs to be enabled once and then all developers can take advantage of it within their applications.

Typically generating links with /node is preferred if the web server can be configured with a sub-URI. For instance, the Jupyter Notebook server can be configured with a sub-URI using the NotebookApp.base_url option:

c.NotebookApp.base_url = '/node/'

Some web servers that are known to work with /node:

Links can be generated with /rnode if the web server relies ONLY on relative links and does not use any absolute links. Some web servers that are known to work with /rnode are:


The view.html.erb HTML template has access to Bootstrap 3 and Font Awesome allowing any stylistic pizzazz to be added to it.

For example, to make a link that appears as a button with an icon in it, you can do:

<a href="#" class="btn btn-primary">
  <i class="fa fa-eye"></i> Connect to My App

All stylization is handled through the HTML class global attribute using predefined Bootstrap and Font Awesome classes.


The simplest example of a view.html.erb consists of just a plain link to the backend running web server using the Open OnDemand reverse proxy:

<a href="/node/<%= host %>/<%= port %>/">Click me!</a>

where host and port are rendered using the interactive session’s connection information.


It is not safe to submit password in a GET request as this can appear in logs. It is recommended to use a POST request if available, see below.

POST Password

For some Interactive Apps you may want a single click solution that not only connects the user to the backend web server but also logs them in with the generated session password. This may be possible depending on the web server you use.

For the case of a Jupyter Notebook server we can create a button that submits a form with the password included in it to the Jupyter server’s login page.

<form action="/node/<%= host %>/<%= port %>/login" method="post">
  <input type="hidden" name="password" value="<%= password %>">
  <button class="btn btn-primary" type="submit">
    <i class="fa fa-eye"></i> Connect to Jupyter

In this example, the password is stored in a hidden input field that the user doesn’t see and it gets communicated to the Jupyter server in the POST request.

Adding Native VNC instructions to the panel

Your site may wish to provide users with instructions on how to connect to interactive jobs with native VNC tools instead of connecting through the browser. To enable this feature configure the dashboard with ENABLE_NATIVE_VNC=true in the dashboard’s environment file /etc/ood/config/apps/dashboard/env.

Enabling this will provide generic instructions for the user to create an ssh tunnel a host. If you wish to specify the host users should tunnel to (a well known login host for example) use the OOD_NATIVE_VNC_LOGIN_HOST configuration in the same environment file.

You can also create your own instructions for major OS platforms. You can create _native_vnc_{windows,mac,linux}.html.erb files and place them in /etc/ood/config/apps/dashboard/views/batch_connect/sessions/connections/ directory to override the default instructions for a given platform.

These file are eRuby (Embedded Ruby) extensions and so here are some useful variables and objects you may need to create helpful instructions. You can also refer to the original files for help in creating new panels.


The OOD_NATIVE_VNC_LOGIN_HOST configuration if given.

The compute node host the interactive job is on


The compute node port the interactive job has opened


The VNC password for the interactive job


The USER environment variable