Warning, /swf-monitor/docs/EXTERNAL_ACCESS.md is written in an unsupported language. File is not indexed.
0001 # External Access — swf-remote Proxy
0002
0003 swf-monitor lives inside the BNL authentication perimeter on
0004 `pandaserver02.sdcc.bnl.gov` and is not reachable from the open
0005 internet. External users (collaborators outside BNL, LLM tools) access
0006 swf-monitor through **swf-remote**, a separate Django app deployed on
0007 `ec2dev` and served at `epic-devcloud.org` / `etaverse.com`.
0008
0009 swf-remote is a thin proxy: it forwards rendered HTML pages and REST
0010 responses from swf-monitor over an SSH tunnel, preserving the user
0011 identity via `X-Remote-User`. Static assets are proxied too, so CSS
0012 and JS stay in sync without redeployment on the swf-remote side.
0013
0014 **Repo**: `/data/wenauseic/github/swf-remote/` (cloned read-only on
0015 swf-testbed; the deployed copy lives on ec2dev). Git policy:
0016 solo-maintained, commits direct to `main`, no PRs.
0017
0018 ## URL forwarding model
0019
0020 swf-remote enumerates every proxied path explicitly in
0021 `src/remote_app/urls.py`. Each entry maps a path to a generic proxy
0022 view (`views.pcs_proxy` for `/pcs/...`, `views.panda_proxy` for
0023 `/panda/...`, etc.) which reads `request.path_info` and forwards to
0024 swf-monitor's matching path.
0025
0026 Generic forwarding *mechanism*, explicit forwarding *enumeration*. A
0027 URL that exists on swf-monitor but lacks an entry in swf-remote
0028 `urls.py` returns 404 to external users, regardless of whether the
0029 page itself works on swf-monitor.
0030
0031 ## Contract: adding a new swf-monitor URL intended for external access
0032
0033 When you add a new URL to swf-monitor (typically in `src/pcs/urls.py`
0034 or `src/monitor_app/urls.py`) and you want external users to reach
0035 it through `epic-devcloud.org`, you must **also** add a sibling entry
0036 in `swf-remote/src/remote_app/urls.py` pointing at the appropriate
0037 proxy view. Without this, the page is BNL-internal only.
0038
0039 Pattern:
0040
0041 ```python
0042 # swf-remote/src/remote_app/urls.py
0043 path('pcs/<your-path>/', views.pcs_proxy, name='<your-name>'),
0044 ```
0045
0046 The `name=` should mirror the swf-monitor URL name where practical, so
0047 existing `{% url %}` template references resolve correctly when
0048 templates are rendered server-side on swf-monitor and proxied through.
0049
0050 REST API endpoints under `/pcs/api/` are already covered by a
0051 catch-all (`pcs/api/<path:path>`) — those do not need per-endpoint
0052 entries.
0053
0054 ## Static assets
0055
0056 CSS, JS, and images at `/swf-monitor/static/...` proxy through
0057 `views.static_proxy`. New static files committed to swf-monitor reach
0058 external users automatically on the next swf-monitor deploy; no
0059 swf-remote change is required.
0060
0061 ## Authentication
0062
0063 External users authenticate against swf-remote (OIDC via CILogon, same
0064 identity provider as swf-monitor's Apache layer). swf-remote forwards
0065 the resolved username to swf-monitor as `X-Remote-User` for both
0066 HTML-page and API requests.
0067
0068 ## Why explicit enumeration
0069
0070 The historical reason is auditability: external exposure is opt-in
0071 per-path, not blanket. Internal-only pages (admin, debug, raw
0072 management endpoints) stay internal even after they're added to
0073 swf-monitor.
