WAIIDE OAuth Workaround for Named Servers

Calliope Integration: This component is integrated into the Calliope AI platform. Some features and configurations may differ from the upstream project.

Issue

When using WAIIDE as a named server in JupyterHub, OAuth authentication fails with a 404 error on:

/user/{username}/{servername}/hub/api/oauth2/authorize

This happens because the service prefix is incorrectly prepended to the hub OAuth URL.

Workaround Options

Option 1: Access Without Named Server Path (Recommended)

Instead of accessing:

http://localhost:8008/user/lmata/waiide/

Try accessing directly:

http://localhost:8008/user/lmata/proxy/8081/

This bypasses the named server OAuth flow and should work immediately.

Option 2: Use Default Server Configuration

Modify your JupyterHub spawner configuration to not use named servers:

# In hub_config_for_waiide.py, remove or comment out:
# c.JupyterHub.allow_named_servers = True
# c.JupyterHub.named_server_limit_per_user = 1

# Change container naming to not use servername
c.DockerSpawner.name_template = '{username}-waiide'

Then restart JupyterHub and spawn a regular server.

Option 3: Direct Container Access (Development Only)

For development/testing, you can access the container directly:

# Find the container IP
docker inspect lmata-waiide-00602a | grep IPAddress

# Access WAIIDE directly (replace with actual IP)
http://172.18.0.4:8081/

Root Cause

This is a limitation in how JupyterHub handles OAuth for named servers. The jupyter-server (running inside the container) constructs OAuth URLs by prepending the service prefix to all hub URLs, which breaks the OAuth flow.

Permanent Fix (Future)

A proper fix would require either:

1. Patching jupyterhub/jupyterhub-singleuser to handle named server OAuth correctly
2. Using jupyter-server-proxy’s standalone mode with custom OAuth handling
3. Implementing a custom OAuth handler that strips the service prefix from hub URLs

For now, use Option 1 (direct proxy access) for the best experience.