What problem does this solve?
I configured OpenConcho through an AI agent. The agent added my Honcho URL but left the token blank. That was the right call. I had not authorized it to handle secrets.
When I opened the app, it loaded in a half-working state. Workspace information showed up. Conclusions and other requests failed. Nothing said the Honcho token was missing, so the errors looked unrelated. I had to diagnose it myself.
checkConnection already maps HTTP 401 and 403 to an auth-required health status. The UI only surfaces that as a small sidebar health dot with a hover tooltip. On a narrow layout the instance switcher (and the dot) is hidden.
Proposed solution
When the active instance has no token and the health check returns auth-required, show a banner in the shared layout. The banner should say the Honcho instance requires an authentication token and that none is configured. It should link to Settings so the token can be added there. It must not show or log the token.
Self-hosted instances that do not require auth should keep working with an empty token and should not show this banner. A generic network failure or a 500 should stay distinct from an auth failure. After a token is saved and the health check succeeds, the banner should disappear without any localStorage cleanup.
I implemented this on a fork branch by reading the existing health query in the root layout. I can open a PR once this issue is filed.
Alternatives considered
Rejecting a save when the token field is empty. That would break public self-hosted Honcho instances, which are allowed to run without authentication.
Only showing a hint on the settings form after clicking Test connection. That hint already exists, but it does not help if you are on another page and never ran Test.
Related
Related to #95, which concerns authentication protecting access to the OpenConcho Web UI. This issue concerns the token OpenConcho uses to authenticate requests to a Honcho instance.
What problem does this solve?
I configured OpenConcho through an AI agent. The agent added my Honcho URL but left the token blank. That was the right call. I had not authorized it to handle secrets.
When I opened the app, it loaded in a half-working state. Workspace information showed up. Conclusions and other requests failed. Nothing said the Honcho token was missing, so the errors looked unrelated. I had to diagnose it myself.
checkConnectionalready maps HTTP 401 and 403 to anauth-requiredhealth status. The UI only surfaces that as a small sidebar health dot with a hover tooltip. On a narrow layout the instance switcher (and the dot) is hidden.Proposed solution
When the active instance has no token and the health check returns
auth-required, show a banner in the shared layout. The banner should say the Honcho instance requires an authentication token and that none is configured. It should link to Settings so the token can be added there. It must not show or log the token.Self-hosted instances that do not require auth should keep working with an empty token and should not show this banner. A generic network failure or a 500 should stay distinct from an auth failure. After a token is saved and the health check succeeds, the banner should disappear without any localStorage cleanup.
I implemented this on a fork branch by reading the existing health query in the root layout. I can open a PR once this issue is filed.
Alternatives considered
Rejecting a save when the token field is empty. That would break public self-hosted Honcho instances, which are allowed to run without authentication.
Only showing a hint on the settings form after clicking Test connection. That hint already exists, but it does not help if you are on another page and never ran Test.
Related
Related to #95, which concerns authentication protecting access to the OpenConcho Web UI. This issue concerns the token OpenConcho uses to authenticate requests to a Honcho instance.