Logging into /admin shows error and success on same page

RESOLVED FIXED in Future

Status

Socorro
Webapp
RESOLVED FIXED
7 years ago
4 years ago

People

(Reporter: automatedtester, Assigned: laura)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Q42011wanted] [Q12012wanted], URL)

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
When I log onto https://crash-stats.stage.mozilla.com/admin I get a screen saying there was an error and it was successful. See screenshot attached
(Reporter)

Updated

7 years ago
Created attachment 491218 [details]
Screenshot
OS: Mac OS X → All
Hardware: x86 → All
I see this a lot (but not always), too.  I wonder if it's related to the (new) problem I'm seeing where random pages will load logged-out after I've logged in (I haven't figured out how to reproduce it cleanly yet besides "load lots of crash-stats pages" or I'd have filed it).

Comment 3

7 years ago
I'm always seeing this when trying to directly go to https://crash-stats.mozilla.com/admin/branch_data_sources when not being logged in and then enter the login data - I'm being sent back to the main page (in my case /products/SeaMonkey) and I get both the error and login messages.
Flags: in-testsuite?
Flags: in-litmus?
So, if you go to https://crash-stats.mozilla.com/products/Firefox and then click Log in bottom right, you are authenticated successfully and only the success message is visible.

However, if you do the following:

1) Ensure you are logged out
2) Go to https://crash-stats.mozilla.com/admin/branch_data_sources
3) You are automatically logged in but see two messages:
    - The first states 'You must be logged in to do that.' (This error comes from the fact that you tried to access a auth only page without being logged in but),
    - The second success message is because on redirect to the front page you got logged in.

My feeling is that the first message is not cleared from the session so when this is called:

if ($messages = Session::instance()->get_once('client_messages')) {

It get's both messages from the session and hence the incorrect double display of messages.
(Assignee)

Comment 5

6 years ago
Reassigning to myself
Assignee: nobody → laura
(Assignee)

Updated

6 years ago
Whiteboard: Q42011wanted
(Assignee)

Updated

6 years ago
Whiteboard: Q42011wanted → [Q42011wanted] [Q12012wanted]
(Assignee)

Updated

6 years ago
Target Milestone: --- → 2.4.1
Component: Socorro → General
Product: Webtools → Socorro
(Assignee)

Updated

6 years ago
Component: General → Webapp
(Assignee)

Comment 6

6 years ago
I'm struggling a bit with how to test this - our auth is LDAP based, and we usually dev with noauth.  Do we have an LDAP test server I can use?  (I'm assuming you don't want me to use the prod one.)  (Otherwise I guess I'll have to mock something, ugh)
Laura & Skaulk, while trying to find steps to reproduce I came across this behavior, bug 718706. Are they related?
Duplicate of this bug: 718706
(Assignee)

Updated

6 years ago
Target Milestone: 2.4.1 → 2.4.2
(Assignee)

Updated

6 years ago
Target Milestone: 2.4.2 → 2.4.3
(Assignee)

Comment 9

6 years ago
Annoyingly, this (il)logic is buried in Kohana code, in modules/auth/libraries/Auth.php::login_required() L110-112:

client::messageSend(Kohana::lang('auth.auth_login_required_not_logged_in'), 
                    E_USER_WARNING);
session::instance()->set("requested_url", "/" . url::current());
url::redirect(url::site('login', $this->config['proto']));

I'll try and work around it.

Updated

6 years ago
Target Milestone: 2.4.3 → 2.4.4
(Assignee)

Updated

6 years ago
Target Milestone: 2.4.4 → 2.5
(Assignee)

Updated

6 years ago
Target Milestone: 2.5 → 2.5.1
(Assignee)

Updated

6 years ago
Target Milestone: 2.5.1 → 2.5.2
(Assignee)

Updated

6 years ago
Target Milestone: 2.5.2 → 3
(Assignee)

Updated

6 years ago
Target Milestone: 3 → 4
(Assignee)

Updated

6 years ago
Target Milestone: 4 → 5
(Assignee)

Updated

6 years ago
Target Milestone: 5 → 6
(Assignee)

Updated

6 years ago
Target Milestone: 6 → 7
(Assignee)

Updated

6 years ago
Target Milestone: 7 → 8
(Assignee)

Updated

6 years ago
Target Milestone: 8 → 9
(Assignee)

Updated

6 years ago
Target Milestone: 9 → Future
(Assignee)

Comment 10

4 years ago
Gone with PHP
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.