NB Folder Access - nightly link not working

Started by ddire, May 12, 2014, 02:53:04 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

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?


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.
5D Mark III -- 7D   SOLD -- EOS M 22mm 18-55mm STM -- Fuji X-T1 18-55 F2.8-F4 & 35 F1.4
Canon Glass   100L F2.8 IS -- 70-200L F4 -- 135L F2 -- 85 F1.8 -- 17-40L --  40 F2.8 -- 35 F2 IS  Sigma Glass  120-300 F2.8 OS -- 50 F1.4 -- 85 F1.4  Tamron Glass   24-70 2.8 VC   600EX-RT X3


Stedda

Thanks...

Works fine in IE, Firefox show connection reset error/problem loading page error.
5D Mark III -- 7D   SOLD -- EOS M 22mm 18-55mm STM -- Fuji X-T1 18-55 F2.8-F4 & 35 F1.4
Canon Glass   100L F2.8 IS -- 70-200L F4 -- 135L F2 -- 85 F1.8 -- 17-40L --  40 F2.8 -- 35 F2 IS  Sigma Glass  120-300 F2.8 OS -- 50 F1.4 -- 85 F1.4  Tamron Glass   24-70 2.8 VC   600EX-RT X3

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


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


Stedda

Same for me... only that direct link you posted works and only in IE.
5D Mark III -- 7D   SOLD -- EOS M 22mm 18-55mm STM -- Fuji X-T1 18-55 F2.8-F4 & 35 F1.4
Canon Glass   100L F2.8 IS -- 70-200L F4 -- 135L F2 -- 85 F1.8 -- 17-40L --  40 F2.8 -- 35 F2 IS  Sigma Glass  120-300 F2.8 OS -- 50 F1.4 -- 85 F1.4  Tamron Glass   24-70 2.8 VC   600EX-RT X3

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.
5D Mark III -- 7D   SOLD -- EOS M 22mm 18-55mm STM -- Fuji X-T1 18-55 F2.8-F4 & 35 F1.4
Canon Glass   100L F2.8 IS -- 70-200L F4 -- 135L F2 -- 85 F1.8 -- 17-40L --  40 F2.8 -- 35 F2 IS  Sigma Glass  120-300 F2.8 OS -- 50 F1.4 -- 85 F1.4  Tamron Glass   24-70 2.8 VC   600EX-RT X3

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.
5D Mark III -- 7D   SOLD -- EOS M 22mm 18-55mm STM -- Fuji X-T1 18-55 F2.8-F4 & 35 F1.4
Canon Glass   100L F2.8 IS -- 70-200L F4 -- 135L F2 -- 85 F1.8 -- 17-40L --  40 F2.8 -- 35 F2 IS  Sigma Glass  120-300 F2.8 OS -- 50 F1.4 -- 85 F1.4  Tamron Glass   24-70 2.8 VC   600EX-RT X3

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....
5D Mark III -- 7D   SOLD -- EOS M 22mm 18-55mm STM -- Fuji X-T1 18-55 F2.8-F4 & 35 F1.4
Canon Glass   100L F2.8 IS -- 70-200L F4 -- 135L F2 -- 85 F1.8 -- 17-40L --  40 F2.8 -- 35 F2 IS  Sigma Glass  120-300 F2.8 OS -- 50 F1.4 -- 85 F1.4  Tamron Glass   24-70 2.8 VC   600EX-RT X3

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.
5D Mark III -- 7D   SOLD -- EOS M 22mm 18-55mm STM -- Fuji X-T1 18-55 F2.8-F4 & 35 F1.4
Canon Glass   100L F2.8 IS -- 70-200L F4 -- 135L F2 -- 85 F1.8 -- 17-40L --  40 F2.8 -- 35 F2 IS  Sigma Glass  120-300 F2.8 OS -- 50 F1.4 -- 85 F1.4  Tamron Glass   24-70 2.8 VC   600EX-RT X3

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.
Canon EOS 50D | 17–40mm f/4L & 70–300mm f/4.5–5.6 DO IS | Lexar 1066x

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

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.
Canon EOS 50D | 17–40mm f/4L & 70–300mm f/4.5–5.6 DO IS | Lexar 1066x

Audionut

Thanks ayshih.

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

QuoteThe 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/

QuoteOur "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.

QuoteTo 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.