HTTPS/redirect issues...

[augustf]

Greetings,

I attempting to set up player (vmdk 0.9.1 version) for the first time pointing at a Concerto 2 server using https URL.

However, once I enter the token produced by the player on the server's sample screen, I see the Player try to get proceed to the next step (I assume displaying the screen) and instead the player is stuck in a loop attempting the pre-authorization step.

It looks like, even though I entered a https scheme URL, the player has decided to substitute it with http.

This is causing the server to redirect from http to https (we're forcing https).

However, the client doesn't seem to like this redirecting between schemes.
I see the following in the Player ( hit F12 >> Console ):

http:///frontend/1?request_cookie. The request was redirected to https:///frontend/1?request_cookie ,

which is disallowed for cross-origin requests that require preflight.

Other than using non-ssl, is there something we can do at our end to resolve this?

Or, would this be considered a bug?

Thanks for your time,
Ryan Russo
University at Albany

[augustf]

While I'm unable to reproduce this myself, the description above suggests that the problem may lie in the javascript at https://github.com/concerto/bandshell/blob/master/lib/bandshell/application/public/javascripts/authenticate.js#L125 not understanding HTTPS.

[mikldt]

The javascript just makes a HTTP request to the bandshell local server (`/authenticate.json'). So everything should be funneled back to app.rb and hardware_api.rb. May want to do a triple-check through the code to make sure there are no requests without the HTTPS, and otherwise try to reproduce and look at the bandshell logs.

[mikldt]

The URL that the javascript redirects to comes from Bandshell's Hardware API fetch_screen_data, which in turn makes a (HTTPS enabled) request to concerto's /frontend.json.

We should test the frontend index to make sure that it is properly returning an HTTPS URL when accessed over HTTPS. From there if we need to debug we'd want to add debug code to the Hardware API to make sure we're passing a good URL to JS.

[augustf]

Turning off any sort of SSL redirection, I'm unable to replicate this issue. In trying to use any sort of self-issued SSL certificate in some tests, I've run into some issues, but I believe those are unrelated.

[augustf]

After a bit of tinkering, it seems as if this could be an SSL thing in at least some cases. After generating a self-signed SSL certificate, I began getting the loop and errors reported here. I went over to https://github.com/concerto/bandshell/blob/master/lib/bandshell/application/public/javascripts/authenticate.js#L125 and couldn't find anything wrong. I then took the player out of kiosk mode and went directly to the server URL and noticed it had become untrusted since last reboot. After again telling Chromium to trust the server, things began working.