Update stable branch to 4.4

.github/workflows/checks.yml

@@ -5,14 +5,14 @@ on:
 
 jobs:
   checks:
-    runs-on: ubuntu-20.04
+    runs-on: ubuntu-latest
     name: Code check and tests
     steps:
       - uses: actions/checkout@v4
       - name: Setup node
         uses: actions/setup-node@v1
         with:
-          node-version: 16
+          node-version: 22
       - run: npm ci
       - name: Enforce code style
         run: npx prettier --config ./prettier.config.cjs --list-different "src/**/*.[jt]s" "tests/**/*.[jt]s" "src/**/*.vue"

.github/workflows/e2e.yml

@@ -6,7 +6,7 @@ jobs:
   test:
     strategy:
       matrix:
-        os: [ubuntu-20.04, macos-latest]
+        os: [ubuntu-latest, macos-latest]
     name: E2E Testing on ${{ matrix.os }}
     runs-on: ${{ matrix.os }}
     env:
@@ -16,24 +16,24 @@ jobs:
         with:
           fetch-depth: 0
       - name: Install node-canvas deps (macos)
-        if: matrix.os != 'ubuntu-20.04'
+        if: matrix.os != 'ubuntu-latest'
         run: brew install pkg-config cairo pango libpng jpeg giflib librsvg pixman
       - name: Install dependencies
         run: npm ci
         env:
           DETECT_CHROMEDRIVER_VERSION: true
       - name: Install xvfb (linux)
-        if: matrix.os == 'ubuntu-20.04'
+        if: matrix.os == 'ubuntu-latest'
         run: sudo apt-get install xvfb
       - name: Run E2E on chrome (linux)
-        if: matrix.os == 'ubuntu-20.04'
+        if: matrix.os == 'ubuntu-latest'
         run: xvfb-run --server-args="-screen 0, 1400x1000x24" --auto-servernum npm run test:e2e:chrome
       - name: Set screen resolution (windows)
         if: matrix.os == 'windows-latest'
         run: Set-DisplayResolution -Width 1920 -Height 1080 -Force
         shell: pwsh
       - name: Run E2E on chrome (non-linux)
-        if: matrix.os != 'ubuntu-20.04'
+        if: matrix.os != 'ubuntu-latest'
         run: npm run test:e2e:chrome
       - name: Archive test results
         if: success() || failure()

.github/workflows/publish.yml

@@ -19,7 +19,7 @@ concurrency:
 jobs:
   build:
     name: Build Docs
-    runs-on: ubuntu-20.04
+    runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v3
         with:
@@ -35,7 +35,7 @@ jobs:
       - name: Build docs
         run: npm run docs:build
       - name: Upload pages artifact
-        uses: actions/upload-pages-artifact@v1
+        uses: actions/upload-pages-artifact@v3
         with:
           path: './docs/.vitepress/dist'
 
@@ -49,4 +49,4 @@ jobs:
     steps:
       - name: Deploy to GitHub Pages
         id: deployment
-        uses: actions/deploy-pages@v1
+        uses: actions/deploy-pages@v4

.gitignore

@@ -32,3 +32,6 @@ bundle-analysis.html
 reports
 *.log
 .tmp/
+
+.github/copilot
+CLAUDE.md

docs/.vitepress/config.ts

@@ -53,6 +53,16 @@ export default defineConfig({
           { text: 'Configuration File', link: '/configuration_file' },
         ],
       },
+      {
+        text: 'Deployment',
+        items: [
+          { text: 'Overview', link: '/deployment_overview' },
+          { text: 'Building for Production', link: '/building_for_production' },
+          { text: 'Deploying VolView', link: '/deploying_volview' },
+          { text: 'Authentication & Authorization', link: '/authentication' },
+          { text: 'Cross Origin Resource Sharing (CORS)', link: '/cors' },
+        ],
+      },
     ],
 
     socialLinks: [

docs/authentication.md

@@ -0,0 +1,29 @@
+# Authentication & Authorization
+
+VolView itself does not specify any given authentication mechanism to use. How you let VolView access authenticated resources depends on individual deployment needs.
+
+## VolView behind Login Portal
+
+The easiest approach to securing a VolView instance is to host VolView behind an authentication portal. This will secure access to VolView, and allow VolView to automatically use existing user credentials to request protected data.  Often the credentials are stored in a cookie.
+
+## OAuth Tokens via URL
+
+When accessing OAuth-protected resources, VolView by default does not add the `Authorization` header to requests. It is possible to tell VolView to add `Authorization` headers to all requests, via the `token` and `tokenUrl` parameters.
+
+### `token` URL parameter
+
+> [!WARNING]
+> This is a discouraged approach! Only use it if you absolutely must.
+
+You can pass in the `token` URL parameter like so: `https://example.com/VolView/?token=XXXX`. When VolView sees this, it will extract the token from the URL and use it for all subsequent data requests. VolView will also strip the token from the URL to prevent saving the token into the browser history.
+
+### `tokenUrl` URL parameter
+
+As an alternative to passing in the token via the URL, if you have an endpoint that returns the user's token then you can use the `tokenUrl` parameter like so: `https://example.com/VolView/?tokenUrl=https://example.com/userToken`. If VolView successfully receives a token from this endpoint, it will use the token in subsequent data requests.
+
+The token URL is expected to return the access token as plaintext, i.e. `text/plain`. Please note that you cannot use an OAuth token endpoint here! OAuth token endpoints are used to exchange auth information, while `tokenUrl` must return just the access token under an already-authenticated session.
+
+By default, VolView will make a `GET` request to the token URL. If another type of request is needed, you can configure it via the `tokenUrlMethod` parameter. For example, to make a `POST` request: `https:/example.com/VolView/?tokenUrl=https://example.com/userToken&tokenUrlMethod=POST`.
+
+> [!NOTE]
+> This requires CORS to be properly configured for the token URL endpoint. See the [CORS](/cors) documentation for more info.

docs/building_for_production.md

@@ -0,0 +1,14 @@
+# Building for Production
+
+To build VolView, ensure you have the latest `node.js` and `npm` tools installed. `git` is optional for fetching the VolView sources.
+
+To build, run the following commands.
+
+```bash
+git clone https://github.com/Kitware/VolView.git
+cd VolView/
+npm install
+npm run build
+```
+
+If all goes well, the build artifacts will be located in `dist/`. This directory should consist of a bunch of static HTML, CSS, JS, font files, and images. These files can be copied to any static site hosting root for immediate deployment.

docs/cors.md

@@ -0,0 +1,29 @@
+# Cross Origin Resource Sharing (CORS)
+
+CORS is a browser mechanism to let servers protect user data from malicious user-side scripts. In a nutshell, CORS protections prevent browsers from allowing JavaScript to read the responses of cross-origin requests unless certain conditions are met.
+
+For VolView, this manifests most prominently when fetching remote datasets. If the public VolView instance at <https://volview.kitware.app> requests MRI data from <https://example.com/mri-data.nrrd>, the request may fail if `example.com` has not whitelisted `volview.kitware.app`.
+
+The rest of this document describes two ways to resolve this issue.
+
+## Whitelist your VolView domain on the data server
+
+If you have control over the data server, you can whitelist your VolView domain. The simpliest way to do this is to set the `Access-Control-Allow-Origin: MYDOMAIN` header on the server. How this is done depends on the static file server that you are using. An example is provided below.
+
+### Nginx example
+
+Please see [the deployment docs](/deploying_volview) for more info on what an expanded nginx configuration may look like.
+
+```
+server {
+    ...
+
+    # Replace "volview.kitware.app" with the domain on which
+    # VolView is being hosted.
+    add_header Access-Control-Allow-Origin "volview.kitware.app"
+}
+```
+
+## CORS proxy
+
+If you do not control the data server, you can use a CORS proxy. A CORS proxy is a lightweight proxy server that is configured to attach CORS headers to responses originating from the data server.

docs/deploying_volview.md

@@ -0,0 +1,46 @@
+# Deploying VolView
+
+Deploying VolView is straightforward: just take the locally built files in `dist/` and put them on any static site hosting.
+
+As a local example, running `npx serve dist/` will spin up a static file server (running on <http://localhost:3000>) that reads the locally built files from `dist/`.
+
+> [!NOTE]
+> Using `npx serve` is *not* a recommended way to deploy VolView. It is only used to demonstrate how easy it can be to deploy VolView in simple scenarios.
+
+## Managed Hosting (S3, GCP, etc.)
+
+Please refer to your hosting provider's documentation on how to host a static site. You will need to upload the built files in `dist/` to wherever your provider specifies.
+
+## Self-hosted Server (nginx, apache2, etc.)
+
+Please refer to your desired server's documentation on how to serve static files. You will need to upload the built files in `dist/` to the static file directory on your server. Several examples are provided below.
+
+### Apache example config
+
+In this apache2 example, the `dist/*` files are located under `/var/www/VolView`, and the domain is `example.com`. This does *not* configure TLS.
+
+```
+<VirtualHost *:80>
+   ServerName YOUR_SERVER_NAME
+   DocumentRoot "/var/www/VolView"
+</VirtualHost>
+```
+
+### Nginx example config
+
+In this nginx example, the `dist/*` files are located under `/var/www/VolView`, and the domain is `example.com`. This does *not* configure TLS.
+
+```
+server {
+	listen 80;
+	listen [::]:80;
+
+	server_name example.com;
+	root /var/www/VolView;
+
+	# index.html fallback
+	location / {
+		try_files $uri $uri/ /index.html;
+	}
+}
+```

docs/deployment_overview.md

@@ -0,0 +1,10 @@
+# Deployment Overview
+
+VolView is a client-side application, which means deploying VolView does not have much overhead. That being said, this section of the documentation will cover some common deployment environments that may be of interest.
+
+Generally, most deployments follow a similar pattern:
+
+1. [Building VolView for production](./building_for_production)
+2. [Deploying VolView](./deploying_volview)
+
+The other articles in this section cover other scenarios that may be applicable to your situation.

docs/mouse_controls.md

@@ -2,23 +2,26 @@
 
 ## Data management
 
-| Shortcut | Action |
-| -------- | ------ |
+| Shortcut | Action                |
+| -------- | --------------------- |
+| Ctrl + . | Delete Current Image  |
+| Ctrl + / | Clear all data        |
 
 ## Slice
 
-| Shortcut    | Action         |
-| ----------- | -------------- |
-| Up arrow    | Next Slice     |
-| Right arrow | Next Slice     |
-| Down array  | Previous Slice |
-| Left array  | Previous Slice |
+| Shortcut            | Action          |
+| ------------------- | --------------- |
+| Up arrow            | Next Slice      |
+| Right arrow         | Next Slice      |
+| Down array          | Previous Slice  |
+| Left array          | Previous Slice  |
+| Alt + mouse up/down | navigate slices |
 
 ## Mouse Controls
 
 | Action       | 2D              | 3D     |
 | ------------ | --------------- | ------ |
-| Left         | grayscale       | rotate |
+| Left         | window level    | rotate |
 | Mid          | pan             | pan    |
 | Right        | zoom            | zoom   |
 | Ctrl + Left  | zoom            | zoom   |