Closed Bug 645685 Opened 13 years ago Closed 13 years ago

Users unable to view docs even when logged in

Categories

(mozilla.org Graveyard :: Server Operations, task)

x86
All
task
Not set
blocker

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jswisher, Assigned: justdave)

Details

Attachments

(2 files)

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
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.)?
Attached image login form in page
That's how the login form looks if it is embedded into the 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 63.245.213.90 and you aren't afraid of editing your hosts file, try putting in 63.245.209.139 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 63.245.209.139 without problem, removed this routing from the hosts file and on second try got again the http auth prompt.
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.
> which IP address are you getting for developer.mozilla.org?  If you're getting
63.245.213.90 and you aren't afraid of editing your hosts file, try putting in 63.245.209.139

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.
Works for me now - thanks
ok everything seems back to normal here too, thank you for your support.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Assignee: cshields → justdave
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: