Login form always show "Login ticket invalid. Please try again" after submission in 10.3

MR added with a proposed solution that does work in our websites, making the error and the wrongfully redirection to disappear.

This MR isn't going to be merged into the branch. The session handling is something I have been looking into especially with the recent changes to sessions introduced back in Drupal 9.2. Session lazy start, and the session id no longer being reliable readble.

Drupal auto-creates the session so manually starting it like this would be problematic in module code. If it's working for you now that's great, but long term the session handling needs to change for this module.

I do have some proposed code to work on this but it's all in a new branch which is pretty much a re-write but have so far been unable to start committing it due to a bit of hang up on one of the first issues I worked on. I will need to post this soon. My thought was the push session related variables into the private store which would automatically trigger the full session. I think the true Drupal way would be to lazy load the LT into the form and not store it in the session at all as that's not part of the spec anyway.

I'm also running a number of sites on D10.3 + CAS Server which aren't having the same issues as you. It might be that I use the gateway feature on a number of key pages on the site which send the user to the CAS Server prior to their attempted login which may initiate the session then.

Setting back to NW since this does need work but this MR won't be merge in.

Can you see if this solves your issue? It's removing the LT from the $_SESSION completely, and using the LT for the purpose it was meant to be used which is to prevent replays of submissions due to bugs or attacks.

Tests need to be updated as the LT has tests.

Moved back to 2.0.x branch as the 2.1.x branch is D10.2||D11 at present and not presently a supported release. It would be ported to 2.1.x later in the branch.

This will not be ported to to 8.x-1.x branch.

While trying to fix these tests, it has become apparent that session handling inside the module is now borked for all tested Drupal 10 core versions; The D9 still works.

This was supposed to be broken a while ago but it was still working 4 days ago. Something has changed and now the session id returned is wrong.

I'll leave this as needs review, but the tests will not pass as they stand here. New issue needed for fixing all of the session handling which will need to move to something stored in the session instead of the session id itself.

It would be appreciated if you could test the LT changes in MR!21 and confirm if that is working for you, although the problems will session ids might be causing deeper problems.

Hi!

Thnks for the quick reaction to the issue.
I cannot test it before the 12th, but i will do it first thing on that day :)

Best

You'll need to patch off the current 2.0.x HEAD as there have been a few additions to fix the session handling which is probably related.

• 🐛 Use own Unique Id instead of Session ID Downport
• 🐛 Purging of tickets is offset by timezone Fixed (unrelated)

(It should be possible to patch this issue into 2.0.0 without HEAD/two above with a little wiggling)

I have so far been unable to replicate the problem with your steps, even with an exact match of setup and a few variants. I do however feel that this is probably a good change to merge in. I'm just more curious to see if this fixes the issue for you now.

ELC → changed the visibility of the branch 3464380-login-form-always to hidden.

@gorkagr Did you have a chance to test out if it fixed the problem for your situation? If that's working, it'll be ready for the 2.0.1 release.

Hi!
Tomorrow I will do the testing, i did not have time these last days due to last-minute urgent fixes on one project.
but those are done already, so tomorrow I will be able to jump on this

Sorry for the delay

In localhost,

first replaced the 2.0.0 version with the last in dev (dev-2.0.x 25cbfc8)
then applied MR 21 (as is 2.0.x) code as a patch via composer
a little bit of drush cr...

and then all good, if i repeat the steps from the original IS

1. Open a private session on the browser, so no cookies are on both sites (server and client)
2. Open the client page and use the 'login with CAS' to be redirected to the server
3. On the server site, fill username and password and login. Good!!

step 3 is executed good and redirects to the client site succesfully :)

Many thnks for the patch!!

Thank you @gorkagr!

elc → closed merge request !20

Automatically closed - issue fixed for 2 weeks with no activity.