mengw15 commented on code in PR #5258:
URL: https://github.com/apache/texera/pull/5258#discussion_r3430786723
##########
common/config/src/main/resources/storage.conf:
##########
@@ -150,4 +150,15 @@ storage {
password = "postgres"
password = ${?STORAGE_JDBC_PASSWORD}
}
+
+ # Configurations of the JupyterLab service
+ # Default values are provided for each field, which you don't need to
change if you deployed Jupyter via docker-compose.yml in
notebook-migration-service/src/main/resources/docker-compose.yml
+ jupyter {
+ url = "http://localhost:9100";
+ url = ${?STORAGE_JUPYTER_URL}
+ # Must match JUPYTER_TOKEN in
notebook-migration-service/src/main/resources/docker-compose.yml.
+ # The backend sends this token when loading the iframe and uploading
notebooks.
+ token = "texera"
+ token = ${?STORAGE_JUPYTER_TOKEN}
Review Comment:
The "must match" coupling between this `STORAGE_JUPYTER_TOKEN` and the
Jupyter container's `JUPYTER_TOKEN` is currently maintained only by a comment.
In production:
- **K8s Helm:** the chart author has to remember to template BOTH env vars
from the same value (e.g., `{{ .Values.texera.jupyterToken }}`). If they
template only one, the other silently defaults to `"texera"` and every backend
→ Jupyter call returns 403 — but `isJupyterAvailable()` treats 403 as
"available" (`NotebookMigrationResource.scala:65`: `status == 200 || status ==
403`), so the misconfiguration doesn't trip the health check and surfaces only
at first user request.
- **Token rotation:** changing the prod token requires updating both sides
atomically — no rolling update.
- **`bin/single-node/.env`:** same drift risk for whoever maintains that
file.
Could both sides read from the **same** env var (e.g., rename to
`JUPYTER_TOKEN` without the `STORAGE_` prefix, consumed by `docker-compose.yml`
and `storage.conf` alike)? That removes the human-maintained "must match"
obligation. If that's a bigger refactor than fits here, at minimum consider
tightening the healthcheck to fail-fast on 403 so a token mismatch surfaces
immediately rather than at first user request.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
