Unable to log in to view knowledge base articles

VERIFIED FIXED in 1.3

Status

support.mozilla.org
General
--
major
VERIFIED FIXED
9 years ago
9 years ago

People

(Reporter: krupa, Assigned: paulc)

Tracking

unspecified
x86
All

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: sumo_only urlhandling, URL)

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
steps to reproduce:
Note:tester is not logged in
1.Try accessing the link https://support-stage.mozilla.org/en-US/kb/hoova?bl=n
2.Log in page loads
3.provide valid credentials and click "login" button

observed behvaior:
login button is dead-unable to login

additional info:
-behavior can be reproduced while trying to access any KB article
-Normal log in works fine.

screencast:http://screencast.com/t/IgPLUMDk
Blocks: 500060

Updated

9 years ago
No longer blocks: 500060
Blocks: 500060

Updated

9 years ago
Assignee: nobody → smirkingsisyphus
Keywords: regression

Comment 1

9 years ago
webroot/silent_session_start_ajax.php is broken. Since we turned up error reporting on stage, this is probably why were are seeing it now.

I fixed the initial problem, but I now have to work through it because new problems with it are turning up.

Comment 2

9 years ago
webroot/silent_session_start_ajax.php has always been broken.

http://viewvc.svn.mozilla.org/vc/projects/sumo/trunk/webroot/silent_session_start_ajax.php?view=log

See any revision, line ~7.

Comment 3

9 years ago
If we turn error reporting back down, does the problem go away?  Because I'm ok with that for now.

Comment 4

9 years ago
This works on staging again by turning off error reporting via Admin->General.

Looking at SVN (sumo and tiki), I see that this is a SUMO-custom thing. It seems to have always been broken. Fixing the global variable problem mentioned in comment 2 only leads to more errors.

Comment 5

9 years ago
OK, we'll fix this soon but we don't have to fix it today (phew).
Severity: critical → major
Target Milestone: 1.2 → 1.3

Comment 6

9 years ago
This needs to be fixed for p10n, since it seems to be a SUMO only thing that has always been broken.
Blocks: 502087
No longer blocks: 500060
(Assignee)

Comment 7

9 years ago
Seems the behavior is not happening anymore. Fixed?
(In reply to comment #7)
> Seems the behavior is not happening anymore. Fixed?

Not happening because of comment 4, right?  (Turning off error reporting.)
(Assignee)

Comment 9

9 years ago
Indeed. My bad.
(Assignee)

Comment 10

9 years ago
https://support-stage.mozilla.org/en-US/kb/this.article.title.has.a.lot.of.periods?bl=n

I don't think it's just webroot/silent_session_start_ajax.php that causes the issue.
(Assignee)

Comment 11

9 years ago
Hey, you think you could clear the cache too?
(Assignee)

Comment 12

9 years ago
(In reply to comment #11)
> Hey, you think you could clear the cache too?
Oops. Wrong bug, sorry :)

Updated

9 years ago
Assignee: smirkingsisyphus → laura
Summary: Unable to login to view knowledge base articles → Unable to log in to view knowledge base articles
(In reply to comment #10)
> https://support-stage.mozilla.org/en-US/kb/this.article.title.has.a.lot.of.periods?bl=n
> 
> I don't think it's just webroot/silent_session_start_ajax.php that causes the
> issue.

Separate bug. This is a javascript error. The other is a PHP error received via
AJAX. I'll post STR momentarily.
Steps to reproduce for comment 2 (these need to be followed to view the PHP error):

1) Go to the error reporting section in Admin->General and turn on all security reporting. 'PHP error reporting' level should be at 'Report all PHP errors'. The 'visible to admin only' checkbox should be *unchecked*. Everything else should be on or checked.

2) Log out

3) Visit any staging page or try to edit any page while not logged in

Observed: PHP Error: Undefined variable: prefs
https://support-stage.mozilla.org/silent_session_start_ajax.php?client=all&stub=all
Line 561

Expected: No error. :(
(Assignee)

Comment 17

9 years ago
Created attachment 396012 [details] [diff] [review]
patch, v1

Apparently it's not the ajax session start. Gotta love those one line changes :)
Assignee: laura → paul.craciunoiu
Status: NEW → ASSIGNED
Attachment #396012 - Flags: review?(laura)
(Assignee)

Comment 18

9 years ago
I don't think it's a regression.
Keywords: regression

Updated

9 years ago
Attachment #396012 - Flags: review?(laura) → review+
(Assignee)

Comment 19

9 years ago
r50317 / r50318
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED

Updated

9 years ago
Whiteboard: sumo_triage
This is looking good to me on https://support-stage.mozilla.org/tiki-edit_translation.php?locale=en-US&page=Browsing+basics; I'll let Krupa mark it when she gets a chance.
(Reporter)

Comment 21

9 years ago
I think there is a regression:

STR:

1.Go to https://support-stage.mozilla.org/en-US/kb/Upgrading+to+Firefox+3%C2%B75
2.Click log in
3.Log in with valid credentials.

Observed behavior:
After successful log in,status still shows "login".However clicking on the "log in" link will inform the user that they are are already logged in.

See the screencast for more details.
screencast: http://screencast.com/t/3rPE1lfwknM

Also see bug 506781
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 22

9 years ago
Works for me. Try ctrl-F5 to refresh the page. I think you might be hitting the cache.
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
That you could log in means this bug was fixed -- the other bug is separate.
Can still reproduce this with an edge case:

http://screencast.com/t/rfGaEalD
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 25

9 years ago
(In reply to comment #24)
> Can still reproduce this with an edge case:
> 
> http://screencast.com/t/rfGaEalD

This works for me locally. Not sure what's going on here.
Paul, if you're in tomorrow, I'll do my best to show it to you :-)
(Assignee)

Comment 27

9 years ago
Stephen showed me this and we agreed that it's edge-case-y enough to leave for later.

The problem really is that the ajax way of enabling that "log in" input is not quite foolproof. Filed bug 514206 to find a way of improving this.
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
Verified FIXED; edge case spun off into bug 514206 (in a way; once fixed there, it shouldn't happen, and I tried to reproduce my own edge case and couldn't -- I'm sure it's still there, though).
Status: RESOLVED → VERIFIED

Updated

9 years ago
Whiteboard: sumo_triage → sumo_only urlhandling
You need to log in before you can comment on or make changes to this bug.