NBIS/sda-download-ui

Watch

Fork 0

SDA-download UI #16

New issue

Open

opened 2026-03-16 08:52:14 +00:00 by aaperis · 3 comments

aaperis commented

2026-03-16 08:52:14 +00:00

(Migrated from github.com)

Sda-download User Interface

sda-download-UI — Web UI for authenticated dataset discovery and download via sda-download API

The project concerns the development of sda-download-UI, a webapp that talks to the sda-download service via its API.

Quick Resources

Mock UI in #2 .
User workflow diagram in #1 .

Background:

sda-download is a backend service with a rest api. It accepts a jwt that is issued by ls-aai OIDC provider (either by getting it directly via ls-aai or using an OIDC client like sda-auth). It uses the jwt to check the user's granted access to datasets by checking the user's c4gh passport and visas.
It then returns a session cookie that contains info about which datasets the user is granted access to and is allowed to download. This can be used in subsequent queries to sda-download's endpoint which allows sda-download to skip the visa checks in order to save time.

Summary of goals

Build sda-download-UI (front-end only) that enables a user to:

Authenticate using LS AAI (OIDC) to obtain a JWT (directly or via an OIDC client flow similar to sda-auth).
Send the JWT to sda-download to establish a server-side session and receive a session cookie.
Use that cookie for subsequent API calls (dataset listing, file listing, download requests) without repeatedly querying LS AAI / inspecting visas.
Provide clear UX for datasets the user can access, files within datasets, and download options (single file, dataset-level, and batch download support), including handling of checksums and (optionally) a cached public key needed by downstream tools.

Key Concepts

Login page (OIDC, similar to or utilize sda-auth)
After login, UI calls sda-download:
- JWT-based authentication initially
- then cookie-based session for subsequent calls
Datasets page: list datasets the user has access to; allow dataset download
Files page: browse files within a dataset; allow file download; show checksums
“Batch download” flow likely needs:
- cookie
- optional cached pub-key
- file list + checksums
UI should explain:
- how/when it expires and how to refresh
- how to provide/upload/cache a public key (if required)

Out of scope

Implementing or modifying sda-download backend behavior.
Managing LS AAI configuration beyond what’s needed to run the UI (redirect URIs, client ID).

Acceptance Criteria

A user can log in via LS AAI OIDC.
A user can view only datasets they are authorized to access.
A user can navigate dataset → file listing and initiate downloads.
UI consistently uses cookie-based session for subsequent calls and handles expired/invalid sessions gracefully.
UI provides a batch-download friendly output including checksums
UI provides public key handling (upload/store in session).
UI is deployable (container/static hosting), configurable via environment variables or config file. Will be deployed in k8s cluster.

Breakdown into Tasks (and later into Issues)

Project Scaffolding & Architecture ✅ Done

Choose framework & scaffold app

Create UI repo structure.
Add linting, formatting, etc.
Create app docker files, incl. compose
Create dev helper environment with sda stack (can include mocks)
AC: App runs locally, has consistent lint/format rules, is configurable via config/env variables.

Implement OIDC login flow

Use OIDC Authorization Code in browser.
AC: User can log in, UI receives ID token/access token (JWT) that is usable with sda-download.
Question: Can we use sda-auth as client? Is old CORS logic in auth working?
A: An implementation using sda-auth as an IdP proxy was implemented but rejected in favor of a standalone OIDC client implementation.

Exchange JWT for sda-download session cookie Obsolete, download V2 does not require the client to exchange seesion cookies.

Call sda-download (whatever endpoint is more suitable) with JWT.
Ensure cookie is set.
AC: After login, session cookie exists and subsequent calls succeed using cookie and JWT.

Session state management

Detect:
- Not logged in
- Cookie expired / 401 → trigger re-auth or re-init session
AC: User is prompted appropriately.

Logout

Clear local auth state.
AC: After logout, datasets are no longer accessible; cookie-based requests fail.

Datasets Discovery UI ✅ Done

Datasets page (list authorized datasets)

Table/cards of datasets returned by sda-download.
Include basic metadata (dataset ID, title/description if available).
AC: Displays datasets filtered by backend authorization.

Dataset details & navigation

Click dataset → route to dataset detail / files list.
AC: Deep linking works; refresh keeps user on same dataset (if session valid).

Loading/empty/error states

“No datasets” UX and guidance (access not granted).
AC: Clear, actionable messaging on 401/403/5xx.

File Browsing & Download UX ✅ Done

Files page for a dataset

List files, size, path/name, checksum(s) if available.
Filtering/search within dataset.
AC: File list matches API and is accessible with cookie session.

Single file download initiation

Trigger download link provided by API for each file.
If API streams file: handle via browser download and show progress limitations.
AC: User can download a selected file; errors are reported.

Checksums display & export

Show checksum type/value (e.g., sha256).
Allow copy/export for validation.
AC: User can retrieve checksums for chosen files.

Batch Download Support ✅ Done

Select multiple files and download

Selection UI (checkboxes) + “Download selected”.
AC: Perform batch file download, resume download, generate checksum files.

Full dataset download

“Download dataset”.
AC: Allow for a full dataset download.

Public C4GH Key handling ✅ Done

UI to provide / upload public key

Add UI control to paste/upload a public key file.
Validate c4gh format (basic checks).
Store in session storage.
AC: User can provide key and UI remembers it for the session.

Security, Privacy, and Compliance Hardening ✅ Done

Token and cookie handling review

Ensure:
- JWT not logged
- cookie not printed by default
- use credentials: include
- CORS expectations (if any) documented (sda-downloadandsda-download UI`
  should eventually share the same domain name but have different hostnames/origins)
  EDIT: Since all external calls (sda-download and OIDC) are done server-side, the webapp does not appear to have any CORS expectations atm.
AC: Security checklist satisfied.

Route protection

Prevent access to dataset/file routes without valid session.
AC: Unauthorized user is redirected to login.

Harden Content Security Policy

Provide recommended CSP, frame-ancestors, etc.
AC: CSP passes OWASP checks.

CI, Packaging, and Deployment ✅ Done

CI pipeline

Lint, test, build.
AC: PR checks required, release builds produced.

Deployment documentation

AC: A new environment can be set up from docs.

Suggested improvements (not MVP)

Use js crypt4gh implementation library.

generate c4gh keys from UI
download decrypted files

Browse dataset directory structure

User can browse files of a dataset by navigate using links the dataset folder structure

# Sda-download User Interface ## sda-download-UI — Web UI for authenticated dataset discovery and download via sda-download API The project concerns the development of sda-download-UI, a webapp that talks to the `sda-download` service via its API. **Quick Resources** - Mock UI in #2 . - User workflow diagram in #1 . ### Background: - `sda-download` is a backend service with a [rest api](https://github.com/neicnordic/sensitive-data-archive/blob/main/sda/cmd/download/swagger_v2.yml). It accepts a jwt that is issued by [ls-aai](https://lifescience-ri.eu/ls-login.html) OIDC provider (either by getting it directly via ls-aai or using an OIDC client like [sda-auth](https://github.com/neicnordic/sensitive-data-archive/blob/main/sda/cmd/auth/auth.md)). It uses the jwt to check the user's granted access to datasets by checking the user's c4gh [passport and visas](https://www.ga4gh.org/product/ga4gh-passports/). It then returns a session cookie that contains info about which datasets the user is granted access to and is allowed to download. This can be used in subsequent queries to sda-download's endpoint which allows sda-download to skip the visa checks in order to save time. ### Summary of goals Build **sda-download-UI** (front-end only) that enables a user to: 1. **Authenticate using LS AAI (OIDC)** to obtain a JWT (directly or via an OIDC client flow similar to `sda-auth`). 2. Send the JWT to **sda-download** to establish a **server-side session** and receive a **session cookie**. 3. Use that cookie for subsequent API calls (dataset listing, file listing, download requests) without repeatedly querying LS AAI / inspecting visas. 4. Provide clear UX for **datasets the user can access**, **files within datasets**, and **download options** (single file, dataset-level, and batch download support), including handling of **checksums** and (optionally) a **cached public key** needed by downstream tools. ### Key Concepts - **Login page** (OIDC, similar to or utilize `sda-auth`) - After login, UI calls sda-download: - **JWT-based authentication initially** - then **cookie-based session** for subsequent calls - **Datasets page**: list datasets the user has access to; allow dataset download - **Files page**: browse files within a dataset; allow file download; show checksums - “Batch download” flow likely needs: - cookie - optional cached **pub-key** - file list + checksums - UI should explain: - how/when it expires and how to refresh - how to provide/upload/cache a public key (if required) ### Out of scope - Implementing or modifying sda-download backend behavior. - Managing LS AAI configuration beyond what’s needed to run the UI (redirect URIs, client ID). ### Acceptance Criteria - A user can log in via LS AAI OIDC. - A user can view **only datasets they are authorized to access**. - A user can navigate dataset → file listing and initiate downloads. - UI consistently uses cookie-based session for subsequent calls and handles expired/invalid sessions gracefully. - UI provides a batch-download friendly output including checksums - UI provides public key handling (upload/store in session). - UI is deployable (container/static hosting), configurable via environment variables or config file. Will be deployed in k8s cluster. # Breakdown into Tasks (and later into Issues) ## Project Scaffolding & Architecture ✅ Done **Choose framework & scaffold app** - Create UI repo structure. - Add linting, formatting, etc. - Create app docker files, incl. compose - Create dev helper environment with sda stack (can include mocks) - **AC:** App runs locally, has consistent lint/format rules, is configurable via config/env variables. ## Authentication & Session Cookie Flow ✅ Done **Implement OIDC login flow** - Use OIDC Authorization Code in browser. - **AC:** User can log in, UI receives ID token/access token (JWT) that is usable with `sda-download`. **Question:** Can we use `sda-auth` as client? Is old CORS logic in auth working? A: An implementation using `sda-auth` as an IdP proxy was implemented but rejected in favor of a standalone OIDC client implementation. **Exchange JWT for sda-download session cookie** Obsolete, download V2 does not require the client to exchange seesion cookies. - Call sda-download (whatever endpoint is more suitable) with JWT. - Ensure cookie is set. - **AC:** After login, session cookie exists and subsequent calls succeed using cookie and JWT. **Session state management** - Detect: - Not logged in - Cookie expired / 401 → trigger re-auth or re-init session - **AC:** User is prompted appropriately. **Logout** - Clear local auth state. - **AC:** After logout, datasets are no longer accessible; cookie-based requests fail. ## Datasets Discovery UI ✅ Done **Datasets page (list authorized datasets)** - Table/cards of datasets returned by `sda-download`. - Include basic metadata (dataset ID, title/description if available). - **AC:** Displays datasets filtered by backend authorization. **Dataset details & navigation** - Click dataset → route to dataset detail / files list. - **AC:** Deep linking works; refresh keeps user on same dataset (if session valid). **Loading/empty/error states** - “No datasets” UX and guidance (access not granted). - **AC:** Clear, actionable messaging on 401/403/5xx. ## File Browsing & Download UX ✅ Done **Files page for a dataset** - List files, size, path/name, checksum(s) if available. - Filtering/search within dataset. - **AC:** File list matches API and is accessible with cookie session. **Single file download initiation** - Trigger download link provided by API for each file. - If API streams file: handle via browser download and show progress limitations. - **AC:** User can download a selected file; errors are reported. **Checksums display & export** - Show checksum type/value (e.g., sha256). - Allow copy/export for validation. - **AC:** User can retrieve checksums for chosen files. ## Batch Download Support ✅ Done **Select multiple files and download** - Selection UI (checkboxes) + “Download selected”. - **AC:** Perform batch file download, resume download, generate checksum files. **Full dataset download** - “Download dataset”. - **AC:** Allow for a full dataset download. ## Public C4GH Key handling ✅ Done **UI to provide / upload public key** - Add UI control to paste/upload a public key file. - Validate `c4gh` format (basic checks). - Store in session storage. - **AC:** User can provide key and UI remembers it for the session. ## Security, Privacy, and Compliance Hardening ✅ Done **Token and cookie handling review** - Ensure: - JWT not logged - cookie not printed by default - use `credentials: include` - CORS expectations (if any) documented (sda-download` and `sda-download UI` should eventually share the same domain name but have different hostnames/origins) EDIT: Since all external calls (sda-download and OIDC) are done server-side, the webapp does not appear to have any CORS expectations atm. - **AC:** Security checklist satisfied. **Route protection** - Prevent access to dataset/file routes without valid session. - **AC:** Unauthorized user is redirected to login. **Harden Content Security Policy** - Provide recommended CSP, frame-ancestors, etc. - **AC:** CSP passes OWASP checks. ## CI, Packaging, and Deployment ✅ Done **CI pipeline** - Lint, test, build. - **AC:** PR checks required, release builds produced. **Deployment documentation** - **AC:** A new environment can be set up from docs. ## Suggested improvements (not MVP) ### Use [js crypt4gh](https://github.com/fathelen/crypt4ghJS) implementation library. - generate c4gh keys from UI - download decrypted files ### Browse dataset directory structure - User can browse files of a dataset by navigate using links the dataset folder structure

aaperis commented

2026-03-16 08:53:37 +00:00

(Migrated from github.com)

Whiteboard discussion.

Whiteboard discussion. <img width="600" src="https://api.zenhub.com/attachedFiles/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBODlBRFE9PSIsImV4cCI6bnVsbCwicHVyIjoiYmxvYl9pZCJ9fQ==--b5fd308bad53d8fb4a85d4a1893c85514415d49e/IMG_20260204_110935150.jpg" alt="IMG_20260204_110935150.jpg" />

aaperis commented

2026-03-24 10:10:22 +00:00

(Migrated from github.com)

Decision on technologies in #6.
Summary:

we use modified sda-auth for OIDC
next.js/react for our website development
CSS bootstrap for styling
Docker for packaging

Update: We use our own implementation for OIDC client

Decision on technologies in #6. Summary: - we use modified `sda-auth` for OIDC - `next.js/react` for our website development - CSS bootstrap for styling - Docker for packaging Update: We use our own implementation for OIDC client

aaperis commented

2026-03-26 10:25:03 +00:00

(Migrated from github.com)

An example of relevant security policies for deployed containers in the sda clusters can be found here.

An example of relevant security policies for deployed containers in the sda clusters can be found [here](https://github.com/neicnordic/sensitive-data-archive/blob/8116ecaad05d784335bd6043ecea7fe87093cdd6/charts/sda-svc/templates/auth-deploy.yaml#L55-L69).