WebUI Vue

The Vue-based WebUI lives in webui-vue/ and is currently documented as a technical preview that exists in parallel with the classic PHP-based WebUI in webui/.

Coexistence model

The repository currently contains two different WebUI implementations:

  • webui/ for the classic PHP-based WebUI

  • webui-vue/ for the Vue-based technical preview

Documentation, packaging, and operational guidance should reflect that both variants currently coexist. Changes to the Vue WebUI should not implicitly assume that it has already replaced the classic WebUI everywhere.

Repository layout

The most relevant parts of the Vue WebUI are:

  • webui-vue/src/ for the application source

  • webui-vue/src/pages/ for page-level route components

  • webui-vue/src/components/ for reusable UI components

  • webui-vue/src/composables/ for shared page and data-loading logic

  • webui-vue/src/stores/ for Pinia stores

  • webui-vue/src/generated/ for generated version and translation data

  • webui-vue/tests/unit/ for unit tests

  • webui-vue/tests/e2e/ for Playwright-based end-to-end tests

Build and installation

The installable SPA bundle is generated from the repository root with:

cmake --build <builddir> --target bareos-webui-vue-build

The build logic is implemented in:

  • webui-vue/CMakeLists.txt

  • webui-vue/build-dist.cmake

The installed Apache configuration is generated from:

  • webui-vue/install/apache/bareos-webui-new.conf.in

The SPA is installed below $CMAKE_INSTALL_FULL_DATAROOTDIR/bareos-webui-new and exposed by Apache below /bareos-webui-new.

Runtime architecture

Unlike the classic PHP WebUI, the Vue WebUI does not talk to the Director through PHP. Instead it uses bareos-webui-proxy for both HTTP session handling and WebSocket-based director communication.

The default Apache configuration:

  • serves the SPA from /bareos-webui-new

  • rewrites SPA routes back to index.html

  • proxies /ws to bareos-webui-proxy on port 9104

  • proxies /api/ to bareos-webui-proxy on port 9104

The HTTP side provides /api/session for session lookup/deletion and /api/session/directors/selector/login for Director login. The WebSocket side is then used for the live director connection once the session has been established.

The proxy configuration behavior is:

  • without --config, it first tries /etc/bareos-webui-proxy/bareos-webui-proxy.ini

  • if that file is missing, it uses built-in defaults

  • with explicit --config, the specified file is required

Any existing configuration file must satisfy Configuration file access rights, regardless of whether it enables PAM. The loader checks the opened file and immediate containing directory before parsing. Unsafe access rights cause startup failure with an actionable diagnostic.

The default configuration template is installed as bareos-webui-proxy.ini in $configtemplatedir.

PAM login

The existing Vue login form and API both accept only the user’s username and password. For a PAM-enabled Director target, configure pam_console_name and pam_console_password in that target’s proxy INI section. The proxy uses these server-side credentials for TLS-PSK and CRAM-MD5 Console authentication. It interprets the submitted username/password as the PAM user’s credentials:

{
  "username": "<pam-user>",
  "password": "<pam-password>"
}

Post this payload to /api/session/directors/selector/login. The Director’s Console must have UsePamAuthentication = yes; login fails if it does not request PAM, rather than granting the Console’s own access. A matching Director User resource determines the authenticated user’s access. PAM usernames and passwords must be nonempty and contain no NUL or record-separator characters. Separate pam_username/pam_password API fields are not accepted. Malformed requests return HTTP 400 and authentication failures return HTTP 401.

This implements bconsole’s direct-credentials mode, not interactive PAM prompts. Configuring PAM with tls_psk_disable = yes is a startup error. Targets without the PAM Console settings retain ordinary Console login. Protect browser/API traffic with HTTPS as well; Director TLS protects only the proxy-to-Director connection.

After successful login, use the session cookie for subsequent requests. WebSocket sessions use {"type":"session","director":"<selector>","mode":"raw"} for a text console, or "mode":"json" for JSON commands. The proxy retains the user’s credentials in server-side session memory for reconnects and explicit credential reuse. Each Director connection uses that target’s configured Console credentials, including when reusing the same user credentials across Directors. Shared Console credentials remain in the restricted server-side INI file, not browser requests or session records. Session expiry, logout, or removing a Director removes its stored user credentials. Session responses identify the user but never expose passwords or the shared Console credentials. See Bareos WebUI Vue for setup.

Testing

Typical local validation commands are:

cd webui-vue && npm run build
cd webui-vue && npm run test:unit
ctest --test-dir cmake-build --output-on-failure -R '^webui-vue:'

The browser-based system tests use the shared WebUI Vue test setup under:

  • systemtests/tests/webui-vue-common/

Translations

The Vue WebUI currently reuses the legacy WebUI locale sources and generated catalog data.

Relevant files are:

  • webui-vue/scripts/generate-webui-i18n.mjs

  • webui-vue/src/generated/webui-locales.js

  • webui-vue/src/generated/webui-messages.js

  • webui/module/Application/language/

To regenerate the committed Vue translation catalog files, run:

cd webui-vue && npm run generate:i18n

Documentation guidance

When documenting Vue WebUI work:

  • add operator-facing documentation to the introduction/tutorial manual

  • add implementation and workflow details here in the developer guide

  • clearly mark the Vue WebUI as a technical preview while it coexists with the classic PHP WebUI

  • avoid wording that implies the classic WebUI no longer exists unless that product decision has changed