Required CAS login bug

What is your cache/performance settings? Are you using varnish or anything like that?

If the attached patch passes the test bot, can you give it a try?

Okay, so this approach won't work.

In the mean while I'd suggest turning caching off, if you can afford to do that.

Okay, here's another approach.

Bah! Maybe I should actually test these ideas out.

Can you try out two different things:
(1): Turn cache mode to off.
(2): Try the patch in #7.

Please report back if either (or both) resolve your issue.

Marking as cannot reproduce since nobody else has reported this and the original poster has not responded with any new debugging information in 6 months.

I'm seeing this problem on version 7.x-1.1 as well. I do not think it is a drupal cache issue.

I have a page that requires cas, let say a page with url alias "login".

This page is set to require cas.
The problem exist only if "Automatically create Drupal accounts" is disabled.

When you first access this page, you're require to login with cas.
Login with a cas account that is not already in the drupal.

You'll receive a message stating that there is no account for that user, this is expected since automatically create account is turned off and this user is not in the drupal user table. Now logout of cas.

Go visit the same login page again, you should be presented with the cas login page again since you've logged out of cas but you're not. Somehow it continue to pickup the cas user id of your previous login, even after logging out of cas, and present you with the same "no account for that user" message.

I cleared the drupal cache, logged in from another computer, and refresh the login page on the computer that i'm testing this on but the message stays.

The message does go away when i clear the browser cache, specifically the cookie, and it give me the cas login screen again. Something is saved in the cookies and the previous cas user(the one without access to the drupal site) is being pickup automatically, even if you logout of cas.

When "Automatically create Drupal accounts" is disabled, and a cas user successfully login with cas but do not have an account on the drupal site, it should clear out its cookie or just not add anything to the cookie.

Hmm, sounds like a phpCAS session is persisting throughout the request. This should be easy to check...

This time with a potential fix.

I was able to reproduce and the path addresses it. Makes sense - we need to remove the CAS session data if we reject the otherwise valid CAS login data.

Patch no longer applied, here's a new one.

For what it's worth, I'm pretty confused on the original request. The patch fixes what was described in #12, but the original request seems to imply some weird thing with caching happening (since ALL users were locked out). I don't see how that's possible, since when drupal_set_message() is called, the result of the page will NOT be cached.

I suggest that we get the patch in, consider this fixed, and have the OP re-open the ticket or new issue if still relevant afterwards.

Patch works for me, and I agree with #17.

Committed

(Note, I neglected to attribute authorship to @bfroehle on this. Sorry about that, will look out in the future)

This same problem still exists for a couple other cases where this function escapes out but leaves the phpCAS isSessionAuthenticated() info in place. Specifically, we were routinely hitting this for users without CAS associations (uid 1 admin wasn't linked to the client site uid 1 admin, and IT staff inadvertantly logged in as admin on cas_server would lock themselves out of CAS on the client even if they changed their cas_server user). But I believe the same applies for access checks or other modules blocking login.

Also, I think the prior patch (which was released in 1.4) should be unsetting $_SESSION['phpCAS']['user'] not the whole phpCAS array. In particular, this allows keeping the once-per-session gateway behavior. If an attempted gateway login fails and the user stays anonymous, the expected behavior for me with "once per session" would be to give up on gateway logins, not re-try every page request. Presumably any site with a gateway login also has an explicit login, which will still work because with $_SESSION['phpCAS']['user'] unset, isSessionAuthenticated fails and a forced login is attempted.

I believe $user = drupal_anonymous_user(); is not needed for these other instances because the user has not been overridden. If somebody could check my logic here I'd appreciate it.

EDIT: please disregard attached patch, fixed patch is below phpcas-user-unsets-1259212.patch

Fixing typo in previous patch.

Looks like this issue was never closed.