fix(workbench): session launch tests fail with SAML/Okta auth — login not shared from interactive auth

Abierto
  • ¿Algo no está bien?
#263 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
python
Área
authentication, backend, testing-qa

Línea de trabajo

Empieza en src/vip_tests/workbench/conftest.py alrededor de workbench_login() en las líneas 110 y 126-129, y después ejecuta test_launch_rstudio, test_launch_vscode y test_launch_jupyter con --interactive-auth. Compara el manejo del storage-state de Connect y Workbench durante la reproducción de SAML/Okta con ALB separado. La tarea está terminada cuando las pruebas obtienen la autenticación de Workbench necesaria o informan de un skip claro e intencionado en lugar de un fallo de inicio de sesión genérico.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

team: workbench

Context

During a VIP verification call with Intuitive Surgical (2026-05-14), all Workbench IDE session launch tests (test_launch_rstudio, test_launch_vscode, test_launch_jupyter) failed with "login failed" errors on both their Workbench 2023 and Workbench 2026 instances.

Their environment:

  • AWS EKS deployment
  • SAML authentication via Okta
  • ALB in front of each product (separate ALBs for Connect and Workbench)
  • Interactive auth (--interactive-auth) was used

Connect tests passed (content publishing worked for all types), but the interactive auth session captured during Connect login did not carry over to Workbench.

Root Cause (Suspected)

workbench_login() in src/vip_tests/workbench/conftest.py:110 skips when auth_provider != "password" and there's no pre-loaded session. When --interactive-auth IS used, the storage state is captured from the Connect auth flow, but the SAML session cookie is scoped to the Connect hostname — it doesn't authenticate Workbench on a separate ALB/hostname.

The code at line 126-129 explicitly handles this case:

pytest.skip(
    "Interactive auth storage state did not authenticate Workbench. "
    "The OIDC session may not be shared between Connect and Workbench."
)

But the test reports "login failed" rather than gracefully handling the separate auth domain.

What the Customer Saw

FAILED test_launch_rstudio - login failed
FAILED test_launch_vscode - login failed  
FAILED test_launch_jupyter - login failed

With --verbose, no additional actionable trace was produced beyond the login failure.

Expected Behavior

When interactive auth is used and the products are on separate auth domains (common with ALB + SAML setups), VIP should either:

  1. Prompt for a separate Workbench interactive auth session, or
  2. Attempt to use the same IdP session cookies (if the IdP domain is shared even when product domains differ), or
  3. Provide a clear skip message explaining that Workbench requires its own auth session

Reproduction

  • Deploy Workbench behind a separate ALB from Connect
  • Configure SAML (Okta) auth
  • Run vip verify --workbench-url <url> --interactive-auth
  • Observe that the interactive auth captured for Connect does not authenticate Workbench

Additional Context

  • Gong call recording: https://us-1237.app.gong.io/call?id=348267831445141666
  • Customer offered to email full verbose trace stack output
  • Sam suspects the specific issue is SAML vs OIDC handling — VIP may be "looking for the wrong thing when it comes to logging in" for SAML providers
  • The 2023 Workbench failures were initially attributed to UI version differences, but the same failure occurred on 2026, confirming it's an auth issue not a selector issue
Lenguaje dominante
Python
Estrellas
8
Forks
1
Merge medio
2 d 2 h
PR fusionados (30 d)
33

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de posit-dev/vip

Todos los issues de posit-dev/vip

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.