Error subscribing to HTTP middlewares from HTTPS frontend

[justinotherguy]

Steps to reproduce:

• start FF (v35.0 on OSX)
• open https://demo.volkszaehler.org/frontend/ with an empty list of channels (same behaviour if channels are present)
  -> pop-up "Kanal hinzufügen" shows
  -> click on "Öffentliche Kanäle"
  -> error message:
  "404: error
  http://demo.volkszaehler.org/middleware.php/entity.json?padding=jQuery213073203720364775_1422050824977&_=1422050824979:
  Unknown middleware response"

Rolling back to "Merge pull request #204 from andig/fix-cdn-usage" (304f39b) removes the behaviour.

Does not occur with Safari 8.0.2 and Chrome 40.0 on OSX.

Regards, J.

[andig]

No osx. Can you check in the developer pane how the rquest looks? Http body/ response?

[justinotherguy]

Thanks for the good questions :-)

• it's about this here: http://support.xqueue.de/docs/artikel/firefox-blockiert-gemischte-inhalte/
• I've tried it with an empty profile (osx, as well) - error does not occur
  -> my fault: accessing the URL using http instead of https (see above) the error does not occur
  so, trying the same with FF 35 on Win8.1 (using https!) the same happens
  console says:
  'Lade gemischte (unsichere) aktive Inhalte auf einer sicheren Seite "http://demo.volkszaehler.org/middleware.php/entity.json?padding=jQuery21305514022129555723_1422094699433&_=1422094699435" jquery-....min.js (Zeile 4)'
  I can't map this to the any of the changes, though.
  Does that help? Can I provide more details?

[andig]

Reproducible on Windows FF35

[andig]

Mhm. Looks like a valid JSONP request: http://demo.volkszaehler.org/middleware.php/entity.json?padding=jQuery21305383623512019367_1422096647035&_=1422096647037

Wondering if this is part of the problem: http://stackoverflow.com/questions/4281274/jquery-ajax-404-handling

I'll look into this...

[andig]

Ok, Firefox is blocking "insecure content" on the https page. Once disabled, problem is gone. As you still have the problem, could you check what is being blocked by ff?

[andig]

Found it. The public MW request is http, not https: http://demo.volkszaehler.org/middleware.php/entity.json?padding=jQuery21301786527374471366_1422097116416&_=1422097116417

Now need to find why and where...

[andig]

Could you please check your options.json? How are the middlewares configured? Explicit http preventing https? If yes, could you check if this works:

remoteMiddleware: [{
    title: 'Volkszaehler Demo',
    url: '//demo.volkszaehler.org/middleware.php'
}],

[justinotherguy]

bingo! :-)
options.js has the default setting (see https://github.com/volkszaehler/volkszaehler.org/blob/master/htdocs/frontend/javascripts/options.js#L39), so it is set to http, not https.
I'd prefer to set the default to https (or have another entry with https; one of them could have a hint in its description); I'm surprised that omitting the protocol actually works; so - despite my lack of understanding why - that does work as well. If this is the way it should behave without the protocol, we could set it to that, as well. My first choice would be https, though.
Your opinion?

[justinotherguy]

Update:
Safari (on OSX as well as iOS) seems to dislike the new setting :-/
Apparantly the mix of http and https is the root cause.
Steps to reproduce:

• start Safari (v8.0.2 on OSX)
• open http://demo.volkszaehler.org/frontend/ with an empty list of channels (same behaviour if channels are present) -> pop-up "Kanal hinzufügen" shows -> click on "Öffentliche Kanäle" -> error message: "404: error
  https://demo.volkszaehler.org/middleware.php/entity.json?padding=jQuery21306341436936054379_1422430832787&_=1422430832788:
  Unknown middleware response"
  Changing the url in remoteMiddleware (options.js) from https://demo.... to http://demo... or (!) "//demo..." solves the issue; "http" will cause the error with FF, of course.
  I've justed tried "//demo..." (after checking against http://en.wikipedia.org/wiki/Uniform_resource_locator#Protocol-relative_URLs ) and it seems to work (currently demo.volkszaehler.org has this setting) for both FF and Safari (OSX and iOS)

[andig]

@justinotherguy what is the specific error displayed in the firefox console (developer console, opens with F12 on Windows)? What are the HTTP request/ response?

[andig]

@justinotherguy the problem is your certificate. Try https://demo.volkszaehler.org/middleware.php/entity.json?padding=jQuery21304080840314272791_1422543722973&_=1422543722974

Firefox:

demo.volkszaehler.org uses an invalid security certificate. 
The certificate is not trusted because no issuer chain was provided. 
(Error code: sec_error_unknown_issuer)

Chrome:

This server could not prove that it is demo.volkszaehler.org; its security certificate is not trusted by your computer's operating system. This may be caused by a misconfiguration or an attacker intercepting your connection.

Proceed to demo.volkszaehler.org (unsafe)

NET::ERR_CERT_AUTHORITY_INVALID

Therefore, the solution to this problem must be:

1. provide a real certificate if you want to use https
2. change the setting back to http and ensure that http will remain available
3. force every user to accept a security exception and document this behaviour

2. ist actually what was in place before. It is valid as a default but not for demo when it's hosted on https.

For now, I'll change options.js back to http and you'll have to manually switch to your liking.

[andig]

@justinotherguy can we close this?

[justinotherguy]

1. sorry for not responding any sooner!
2. I don't think the cert is the issue - I have installed to root CA cert in my browser, the error message comes up anyway
3. the error message (in FF, when I have set the URL to "http://" in options.js and access http://demo... is shown here: Error subscribing to HTTP middlewares from HTTPS frontend #231 (comment)
4. apparantly my comment Error subscribing to HTTP middlewares from HTTPS frontend #231 (comment) ("bingo!") does not refer to your comment Error subscribing to HTTP middlewares from HTTPS frontend #231 (comment) ("url: '//demo"), but to your comment Error subscribing to HTTP middlewares from HTTPS frontend #231 (comment) ("Found it. The public MW request is http, not https") -> from what I can tell, using "url:'//demo" seems to fix all cases mentioned above (it's the setting that's still present in demo.volkszaehler.org).

I suggest, we'll set options.js to "url:'//demo" - agreed?