Project

General

Profile

Bug #4043

flash message problem on login/restiration pages

Added by Marcin Kuzminski [CTO] over 4 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
Start date:
24.06.2016
Due date:
% Done:

0%

Estimated time:
Sorting:
Commit Number:
Affected Version:

Description

During the testing of issues with social auth i relizied that flash messages with errors are somehow not working.

Steps to reproduce.

  • turn of anonnymous access
  • misconfigure the social auth (enable google/github, put wrong tokens)
  • go to register/login page, and click a gh/google button

see that page reloads and nothing happens. There's a call to

def _handle_social_auth_error(self, result):

Which does log.error, and does session.flash with an error message.

When you disable anonymous access redirect is to the home page where the flash message is shown, so the problem is in the way that we generate register/login pages.

History

#1 Updated by Marcin Kuzminski [CTO] over 4 years ago

  • Assignee set to Martin Bornhold

#2 Updated by Marcin Kuzminski [CTO] over 4 years ago

  • Target version changed from v4.2 to v4.3

#3 Updated by Daniel D over 4 years ago

Seems like the session cookie id is different on each request - this points to a new session being regenerated - maybe auth fails - a logout_user() or similar call gets made which clears the session - losing the flash messages?

#4 Updated by Martin Bornhold over 4 years ago

  • Status changed from New to In Progress

First investigations are showing that we invalidate the session on a POST request to the login view. After this the user will get a new session and every related flash messages will be lost. Wondering why this invalidation is done. See https://internal-code.rhodecode.com/rhodecode-enterprise-ce/files/5cfdb31bf841ee6e6380acb63c01d12cd0c6bf20/rhodecode/login/views.py#L150

This affects not only EE and social auth. It affects all requests to the login page.

#5 Updated by Martin Bornhold over 4 years ago

  • Status changed from In Progress to Resolved

Turns out the invalidation on POST was not the cause. The problem is when deactivation anonymous users access in settings we are invalidating the session on each request due to a wrong if condition. This is fixed in https://internal-code.rhodecode.com/rhodecode-enterprise-ce/pull-request/2481

#6 Updated by Marcin Kuzminski [CTO] over 4 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF