Closed Bug 612897 Opened 9 years ago Closed 7 years ago

Logging into /admin shows error and success on same page

Categories

(Socorro :: Webapp, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED
Future

People

(Reporter: automatedtester, Assigned: laura)

References

()

Details

(Whiteboard: [Q42011wanted] [Q12012wanted])

Attachments

(1 file)

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
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).
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.
Reassigning to myself
Assignee: nobody → laura
Whiteboard: Q42011wanted
Whiteboard: Q42011wanted → [Q42011wanted] [Q12012wanted]
Target Milestone: --- → 2.4.1
Component: Socorro → General
Product: Webtools → Socorro
Component: General → Webapp
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
Target Milestone: 2.4.1 → 2.4.2
Target Milestone: 2.4.2 → 2.4.3
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.
Target Milestone: 2.4.3 → 2.4.4
Target Milestone: 2.4.4 → 2.5
Target Milestone: 2.5 → 2.5.1
Target Milestone: 2.5.1 → 2.5.2
Target Milestone: 2.5.2 → 3
Target Milestone: 3 → 4
Target Milestone: 4 → 5
Target Milestone: 5 → 6
Target Milestone: 6 → 7
Target Milestone: 7 → 8
Target Milestone: 8 → 9
Target Milestone: 9 → Future
Gone with PHP
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.