Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API calls on cached page before websocket handshake causes 401/403s, UI breaks #1364

foosel opened this issue Jun 8, 2016 · 0 comments


None yet
1 participant
Copy link

commented Jun 8, 2016


There's a race condition in the following scenario:

  • browser has cached version of UI, is closed
  • server is (re)started, UI API Key changes
  • browser is opened, loads UI from cache including old UI API Key
  • both connection to websocket and initial settings GET are triggered at nearly the same time

If settings request now arrives at server before the initial websocket handshake can cause the UI API Key to be updated, the settings request responds with a 401 and the viewmodels are consequently never bound in the initial application startup.

Looks like this on the JS console:


To reproduce for debugging:

  • load UI as usual

  • in JS console set breakpoint here

  • reload

  • once breakpoint is hit, execute this in the JS console:

    $.ajaxSetup({headers:{"X-Api-Key": "invalid"}});
  • continue execution


Make sure settings GET is only run AFTER initial handshake with server has completed and ensured a valid UI API Key. Same also holds true for the onStartupComplete view model callback (causes the other 401's in the screenshot above).

Affected versions


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.