NB Folder Access - nightly link not working

[ddire]

Hi, I cant access the nightly builds folder, just keeps on taking me back to the https://builds.magiclantern.fm/ homepage when I click on browse nightly builds?? Any ideas why?

[Walter Schulz]

http://builds.magiclantern.fm/#/
or browse
http://builds.magiclantern.fm/jenkins/

[a1ex]

Link doesn't work (Firefox 29, didn't work before upgrading FF either).

I told Nanomad about it last week, but maybe he couldn't reproduce it.

[Audionut]

Been working fine with firefox here.

[Stedda]

Am I the only one still having an issue with this?

I can't access through IE, Firefox, or IPhone (just to be sure)... takes me in an endless loop back to the main page when I click to access Nightly Builds.

[Audionut]

This link http://builds.magiclantern.fm/#/

?

[Stedda]

Thanks...

Works fine in IE, Firefox show connection reset error/problem loading page error.

[Audionut]

Works fine here with FF.  Considering only yourself and a1ex appear to have the issue*, I expect the issue might be a difficult one to solve.
Nanomad should know more, but he appears to be attending to life atm.

* Normally, an issue results in many duplicate posts.  So far, this is the only thread regarding this issue.

[a1ex]

This link http://builds.magiclantern.fm/#/

?

Yes. Still not working here in Firefox, but works with Chrome.

[Audionut]

The download page http://www.magiclantern.fm/downloads.html sends a redirect from here http://nanomad.magiclantern.fm/nightly/

Long shot, but does that last link work?

[a1ex]

Nope. It redirects to https://builds.magiclantern.fm/ and it stops there.

[Stedda]

Same for me... only that direct link you posted works and only in IE.

[Audionut]

Hmm, I also get an error when using the encrypted link.

Do you guys have some plugin that tries to encrypt everything?

[Stedda]

Not that I know of.

I run AdBlock Plus, Ghostery, Privacy Eraser, and StopScript.

[Audionut]

A quick google search for StopScript didn't turn up anything immediately helpful. 

I assume it's some Java blocking thing similar to NoScript.  The nightly download page relies on Java (I think, based on the page source).  You may need to explicitly allow an exception.

[a1ex]

All extensions disabled, still not working.

[Stedda]

Same here just did the same... only started after the new Firefox update.

[a1ex]

Here it's been broken for 1 or 2 weeks, so nothing to do with FF update (FF updated itself a few days ago).

Some forum links also seem to behave in weird ways (for example, when linking to a earlier post on the same page, I remember it used to simply scroll to the old post rather than reloading the entire page). Not 100% sure about this though.

[Stedda]

Mine is still scrolling as you describe.

The day of the update is the day the problem started, but it could have been the first time in a while Super Start Page updated links....

[Walter Schulz]

Running Firefox 24.5.0 ESR with NoScript and some other blockers. OS is Windows 7/64

No problem to access
http://builds.magiclantern.fm/#/
but will be denied to
https://builds.magiclantern.fm/#
and
https://builds.magiclantern.fm

http://builds.magiclantern.fm
redirects to
http://builds.magiclantern.fm/#

[Audionut]

I'm out of ideas.
I can confirm it (also) works in the ML development VM, with both the installed version (18.?), and an updated version (29.0).



Perhaps it is related to this, which appears to be a cloudflare issue.  I have noticed this issue myself.
I guess we have to wait for nanomad.

[Stedda]

At least I have one way to access it now... thanks for the help.

[ayshih]

I just discovered that Chrome on my OS X box can no longer access the nightly-build page.  It redirects to the HTTPS version of the URL, which then dies.  I do not know when this behavior started.  Every other browser I've tried, including Chrome on Windows, does not redirect from the HTTP URL to the HTTPS URL.

This suggests to me that my OS X Chrome is being too "smart", and substituting in the (non-functional) HTTPS version of the URL.  I do not knowingly have any extension installed that could be responsible.

[ayshih]

Beautiful, found the explanation: somehow the web server, at some point, used HSTS to tell my Chrome that it must use HTTPS to access it.  That's a problem because HTTPS doesn't work for this server.

The fix for Chrome: go to

Code Select Expand


chrome://net-internals/#hsts

and remove "builds.magiclantern.fm" from the HSTS set.  I can now access the nightly build page.

Presumably something analogous can be done on other clients that are exhibiting this problem.  Also, there may be something misconfigured on the server.

[Audionut]

Thanks ayshih.

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

The initial request remains unprotected from active attacks if it uses an insecure protocol such as plain HTTP or if the URI for the initial request was obtained over an insecure channel.[22] The same applies to the first request after the activity period specified in the advertised HSTS Policy max-age (sites should set a period of several days or months depending on user activity and behavior). Google Chrome and Mozilla Firefox address this limitation by implementing a "STS preloaded list", which is a list that contains known sites supporting HSTS.[17][18] This list is distributed with the browser so that it uses HTTPS for the initial request to the listed sites as well.

https://blog.mozilla.org/security/2012/11/01/preloading-hsts/

Our "preload list" has been seeded with entries from Chrome's list of a similar function. To build our preload list, a request is sent to every host with 'mode: "force-https"' on Chrome's list. Only if a host responds with a valid HSTS header with an appropriately large max-age value (currently greater than or equal to 10886400, which is eighteen weeks) do we include it in our list. We also see if the includeSubdomains value for the entry on Chrome's list is the same as what we receive in the response header (if they do not match, we use the one we receive).

Since this problem only occurs for a subset of users, I can only assume it is some bug in the way Chrome/Firefox handles it.  I don't have knowledge of server side changes, so I'm uncomfortable in reporting the issue to Mozilla/Google devs.

It looks like the issue can be resolved on our side, like so.

To accomplish this task, we introduce the concept of "knockout" entries in our HSTS implementation. When the browser receives an HSTS header with "max-age=0″, a knockout entry is stored that overrides the corresponding entry in the preload list. The knockout entry essentially says, "We have no HSTS information regarding this host." As a result, the browser behaves as if the host were not on the preload list.

I assume something similar happens for Google' list also.

[a1ex]

Maybe related: today this link also stopped working: http://www.magiclantern.fm/forum/index.php (it redirects to the main home page, via a page named javaredirect.html).

This one works: http://www.magiclantern.fm/forum/

[a1ex]

Today, the forum link from the main page (second link from above post) stopped working too. Clicking on the link simply refreshes the home page (via javaredirect.html).

Directly typing www.magiclantern.fm/forum doesn't work either.

To access the forum, I have to start from a link to some existing message, from history.

[Walter Schulz]

Works fine here.
Do you use NoScript or another add-on able to block java, javascript, cookies?

[a1ex]

I use Adblock Edge, but I also tried with it disabled.

Clearing all history appears to have fixed all these errors though.

http://superuser.com/questions/539580/how-can-i-remove-a-website-accidentally-added-to-firefoxs-list-of-hsts-sites

[Stedda]

Working fine today.... like nothing ever happened.

[gjh1967]

Hi everyone

It may be that Firefox has disabled Java scripts from activating since V27

Cheers Glenn.

[Hask]

Guys, this just came up in the IRC channel.

As far as I can see, this is not an HSTS but a Content-Security Policy error, and modern webbrowsers are just protecting their end users.

The issue is what the Console in Chrome-developer tools will immediately tell you:
XMLHttpRequest cannot load http://builds.magiclantern.fm/jenkins/view/ML%20Platforms/api/json. Received an invalid response. Origin 'https://builds.magiclantern.fm' is therefore not allowed access.

In other words, non-HTTPS resources are attempted to be loaded from an HTTPS-site and the browser is not having any of it (and rightfully so).

Looking over the AngularJS source, this comes mostly down to hardcoded http-protocols being used in the urls.

Firstly, to get it to work, I've locally changed in the Chrome-debugger references to the protocol in the file app.js, change:
RestangularProvider.setBaseUrl('http://builds.magiclantern.fm/jenkins/');

so that it doesn't include the protocol (which means it'll use the protocol of the current site), so:
RestangularProvider.setBaseUrl('//builds.magiclantern.fm/jenkins/');


This is enough to get the downloads working, but, really, all the hardcoded protocols from the url-references should be deleted (or changed to HTTPS if it's really never meant to run under HTTP). There are also other errors in the console when clicking download, but at least it works.
Is the source of the app open for download somewhere? I'd happily help where I can with this.

Hope this helps!



EDIT:
Came up in the IRC-channel again.

It seems to work in IE11, but that can only be the case if you use the non-HTTPS link. If you use HTTPS, IE11 works correctly by blocking.
The difference is that if you use the non-HTTPS link in Chrome, it changes the protocol to HTTPS (because, HSTS). The site then automagically gets broken for a large part of your users.

So, I think removing the hardcoded http-references should still work, also when in the future IE will support HSTS.

[a1ex]

Solved, thanks @Hask.

Please test both http and https.

[Walter Schulz]

IE8 and FF26 tested with http and https. Both working now!

[Hask]

Solved, thanks @Hask.

You're welcome, glad I could do something back for Magic Lantern