bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Users unable to view docs even when logged in



mozilla.org Graveyard
Server Operations
7 years ago
3 years ago


(Reporter: Janet Swisher, Assigned: justdave)




(2 attachments)



7 years ago
Not seeing this myself, but getting multiple reports like:

* The wiki pages do not get loaded and even after logging in i cant seem to be able to access the pages..Fix this asap please..

* if I log in, I get the message Sie haben keine Berechtigung, diese Seite zu betrachten. (You have not the right to see this page)

* Why even after registering to MDN I got no permission on: https://developer.mozilla.org/en/Configuring_Build_Options

Comment 1

7 years ago
Also, apparently getting "YOU NEED TO LOGIN FOR THIS CONTENT" if not logged in.
(In reply to comment #1)
> Also, apparently getting "YOU NEED TO LOGIN FOR THIS CONTENT" if not logged in.

This seems like an access restriction issue in DekiWiki. Configuring_Build_Options should be a public page though. Hard to diagnose without knowing specific users and pages.
Yeah, I'd need details of who's seeing the problem and if it's on all pages or just certain ones.
Perhaps check to see if the Deki databases have gotten damaged or corrupted? User "Jonathan Watt" is reporting that he can view the site fine unless he logs in, but logged in, he gets errors about permissions, but his permissions are configured correctly.

Any errors in logs indicating that we're getting DB errors of some kind?
Jeremy or Justin, can you PM me if/where I can see logs from prod dekiwiki?
Also, there's some indication this might be related to the Europe mirror only, as all the reports seem to be coming from there.
Transferring ownership to mozilla.org -- they need to look at this.
Assignee: nobody → server-ops
Component: Docs Platform → Server Operations
Product: Mozilla Developer Network → mozilla.org
QA Contact: docs-platform → mrz
Version: Deki → other
Seeing also this, search page works ok, but clicking a link often either shows a HTTP auth prompt (page gets loaded) or a login form in the page with access denied.

Living in Germany. Do you need other information (header logs etc.)?
Created attachment 522427 [details]
login form in page

That's how the login form looks if it is embedded into the page.
Created attachment 522430 [details]
http auth login prompt while loading page

This is the http auth login prompt I sometimes get.

I tried to load https://developer.mozilla.org/en/XUL_School/Getting_Started_with_Firefox_Extensions four times:
1x loaded normal
2x with http auth and loading the page
1x loaded login page
aryx, can you try again please?
Assignee: server-ops → cshields
lowering severity while awaiting confirmation that the problem is still there or not.
Severity: blocker → critical
Hard reload (ctrl+shift+r) still shows login form page. Second try login form, third try http auth.
Critical > blocker
Severity: critical → blocker
which IP address are you getting for developer.mozilla.org?  If you're getting and you aren't afraid of editing your hosts file, try putting in for developer.mozilla.org in your hosts file and see if that fixes (just to test).  If it does, then we've confirmed it's the Amsterdam proxy.  

I just tried the reverse (I edited my hosts file to use Amsterdam) and I'm unable to reproduce.  I still get the correct page, even when logged in.
Loaded ten times from without problem, removed this routing from the hosts file and on second try got again the http auth prompt.

Comment 16

7 years ago
I am also having this problem. For example I cannot view https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date. If you need any information from me then let me know.

Comment 17

7 years ago
> which IP address are you getting for developer.mozilla.org?  If you're getting and you aren't afraid of editing your hosts file, try putting in

confirmed by my side
I just made a change to the way the load balancer in San Jose handles the X-Forwarded-For header (I have a feeling it was nuking the end client address out of the header when proxying requests from Amsterdam that went through it, so everyone looked like they were coming through Amsterdam).  Give it a try again?  Whether this worked or not depends entirely on whether dekiwiki parses that header properly.  Probably the reason I couldn't reproduce before just means I got lucky and nobody else tried to log in from Europe while I was testing it.
Looks like the above in tandem with Sheppy banning an abusive user in Europe probably caused this.  Since the X-Forwarded-For was getting replaced instead of appended, it was replacing the client IP with the IP of the Amsterdam proxy, so the proxy got banned instead of the user.

Comment 20

7 years ago
Works for me now - thanks

Comment 21

7 years ago
ok everything seems back to normal here too, thank you for your support.
Last Resolved: 7 years ago
Resolution: --- → FIXED
Assignee: cshields → justdave
Duplicate of this bug: 645710
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.