intermittent authentication problem

[MHCPU]

I've recently moved an application from:

TG 2.3.2

Python 2.6.6

Apache 2.4.4 with the event MPM

to:

TG 2.4.2

Python 3.7.6

Apache 2.4.34 with the prefork MPM

Seemingly at random, people can't log in.  The problem seems unrelated to who is trying to log in.  For example, one person could, and then later could not.  Unfortunately I always can, making it harder to troubleshoot.

Both versions of the application authenticate against LDAP.  Here's is the auth section of app_cfg.py for the new version:

base_config.update_blueprint({

    'auth_backend': 'authmetadata',

    'sa_auth.cookie_secret': "xxxxx",

    'sa_auth.authmetadata': ApplicationAuthMetadata(model.DBSession, model.User),

    'sa_auth.post_login_url': '/post_login',

    'sa_auth.post_logout_url': '/post_logout',

    'identity.allow_missing_user': True,

    'sa_auth.form_plugin': None,

    'sa_auth.authenticators': [('myauth', ldapauth.LDAPAuthenticatorPlugin())],

    'sa_auth.mdproviders': [('myprovider', ldapauth.LDAPMDProvider())],

})

Here is an except from the Apache logs from a user logging in only one time.  It seems to be running the code multiple times, with some attempts working, and some failing:

[auth] no identity returned from <FastFormPlugin:/login_handler xxxxxxxxxxx2016> (None)

[auth] identity returned from <AuthTktCookiePlugin xxxxxxxxxxxx1960>: {'timestamp': 1580833320, 'repoze.who.plugins.auth_tkt.userid': 'mcahn', 'tokens': [''], 'userdata': {}}

[auth] no identity returned from <FastFormPlugin:/login_handler xxxxxxxxxxx2016> (None)

[auth] no identity returned from <AuthTktCookiePlugin xxxxxxxxxxxx1960> (None)

[auth] no identity returned from <FastFormPlugin:/login_handler xxxxxxxxxxx2016> (None)

[auth] no identity returned from <AuthTktCookiePlugin xxxxxxxxxxxx1960> (None)

[auth] no identity returned from <FastFormPlugin:/login_handler xxxxxxxxxxx2016> (None)

[auth] no identity returned from <AuthTktCookiePlugin xxxxxxxxxxxx1960> (None)

[auth] identity returned from <FastFormPlugin:/login_handler xxxxxxxxxxx2016>: {'login': 'mcahn', 'password': 'xxxxxxxxx', 'max_age': None}

[auth] no identity returned from <AuthTktCookiePlugin xxxxxxxxxxxx1960> (None)

[auth] no identity returned from <FastFormPlugin:/login_handler xxxxxxxxxxx2016> (None)

[auth] identity returned from <AuthTktCookiePlugin xxxxxxxxxxxx1960>: {'timestamp': 1580834310, 'repoze.who.plugins.auth_tkt.userid': 'mcahn', 'tokens': [''], 'userdata': {}}

[auth] no identity returned from <FastFormPlugin:/login_handler xxxxxxxxxxx2016> (None)

[auth] identity returned from <AuthTktCookiePlugin xxxxxxxxxxxx1960>: {'timestamp': 1580834310, 'repoze.who.plugins.auth_tkt.userid': 'mcahn', 'tokens': [''], 'userdata': {}}

[auth] no identity returned from <FastFormPlugin:/login_handler xxxxxxxxxxx2016> (None)

[auth] identity returned from <AuthTktCookiePlugin xxxxxxxxxxxx1960>: {'timestamp': 1580834310, 'repoze.who.plugins.auth_tkt.userid': 'mcahn', 'tokens': [''], 'userdata': {}}

Any advice on where how I might troubleshoot this would be much appreciated.  I wonder if the change of which Apache MPM I'm using has anything to do with this problem.  I also have the (vague) understanding that the way I'm doing the authentication is deprecated in TG 2.4.

Thanks in advance,

Matthew Cahn

[MHCPU]

I left out one important piece of information.  If a user who can't log in opens a "private" or "incognito" browser, then the login works.

Matthew

[MHCPU]

"Private" or "incognito" browser window or tab, that is.

Matthew

[Alessandro Molina]

Upgrading from Python2 to Python3 changes the way the cookie signatures are generated if I remember correctly.
So authentication tokens created on PY2 don't work on PY3 and the user will have to reach to /logout_handler to delete the old cookie and enable the new one (or clear cookies).

That might be the problem you are facing.

On Wed, Feb 5, 2020 at 3:03 AM MHCPU <matthe...@gmail.com> wrote:

"Private" or "incognito" browser window or tab, that is.

Matthew

--
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbogears+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbogears/d90385a7-3293-40ee-9d2b-93b671e1c3ec%40googlegroups.com.

[Matthew Cahn]

Thanks, Alessandro.  That makes sense, although I'm not sure it exactly matches the behavior.  Since a private window works, it does seem cookie-related.  On the other hand one user was able to log in during testing, but then later was not.  He said it was the same browser on the same computer.  Since I can't duplicate the problem, it's very hard to diagnose.  I wound up pointing Apache at our Central Authentication Service (CAS), and skipping the Turbogears authentication entirely.  That at least has the advantage of two-factor authentication.

Best,

Matthew

To view this discussion on the web visit https://groups.google.com/d/msgid/turbogears/CAJfq2JEZutqTFT5ejJETkPFomMNkYpmMC77Vyz7T6tTgojaSZw%40mail.gmail.com.

[Alessandro Molina]

Well, I guess that the testing environment doesn't use the same domain of the production one. Right? So the cookie is different between the two.

But if someone was logged on the same domain with a cookie generated on PY2 and you upgraded to PY3 he would be unable to be recognised when he comes back and he would have to clear cookies to login again.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbogears/CACcPiD21Wh1tUytfba38EEpQ2LiK663n%3DrDiqJJ7w2RNrvmKkg%40mail.gmail.com.

[Matthew Cahn]

The “testing” I referred to was actually just some people I asked to try logging in to the production site, before a larger number of people would need to use it all at once.  So really, the one user could log in to the production site one day, and not a few days later (assuming his recollection of which computer and browser he used is correct). Also, I think I asked one user to clear everything from the browser, and that didn’t help, yet a private window did help, which doesn’t make a lot of sense to me.

On Feb 13, 2020, at 1:23 PM, Alessandro Molina <alessand...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/turbogears/CAJfq2JFgfLtWjgC27fT4fm6xmjnHuBAXRJOrd553E5S14bv4bA%40mail.gmail.com.