Access denied when user logs in for first time or after cache cleared.

The 1.x branch is dead, no longer supported. Use the 2.x branch instead.

Please test the new branch somewhere if you can (not on your production system), as we'd like to move everyone over to it. Reopen this ticket in that branch if it's still a problem.

Thanks for looking into this! Setting to active as there's no patch yet that "needs work".

@kjmeath: Thanks for figuring this out! If you'd like to try to put a patch together yourself, there are instructions over at Patches. If not, someone will roll one up eventually. ;)

that works if there are two components in the current path but not otherwise. from how i read the Drupal arg() function, i think it should work as well, and cover all cases, to instead do the following:

UPDATED: it also needs to handle other query arguments (eg "/my/path?page=3")

          $options = array();
          $query = $_GET;
          unset($query['q']);
          if ($query) {
            $options['query'] = $query;
          }
          drupal_goto($_GET['q'], $options);

however, i was not able to recreate this problem. (i had thought i was seeing it but it turned out i had unrelated issues.)

i tried removing "View published content" permission from anonymous users, and displaying the /saml_login link on the Access Denied page. when an anonymous user clicks on that link, they end up back on the original page without any errors, without making this change. maybe there's another specific scenario that causes this problem.

I've attached a patch that forces a redirect after the call to user_login_finalize and leverages the Drupal API to do the above.

For what it's worth, this did seem to solve my related problem when I was trying to redirect users to their profile edit screen after logging in (user/uid/edit) and they would get access denied until the next page load.

Hmm I get the idea, but I don't think this is the correct approach to the problem. I've had this on another project and for us specifically the drupal_goto approach doesnt even work, because I got an infinite redirect. It likely had something to do with the redirection I had set up to saml_login, but at least its a valid use case where this fix doesnt apply.

The main issue is that the user session is retained from between the user first touches the site (at that point as anon user) until he gets a full drupal user. If initally there was an error displayed, he'll get that when logging in.

A different approach would be to simply remove the error messages at user_login_finalize(), using drupal_get_messages('error', TRUE);. I've just tested this, and worked for me. The issue with this solution is that it will remove _every_ error message, so potentially useful ones as well. This authentication flow can be hooked into using Rules, I'd be inclined to say that if someone does not want the error to show, they will need to implement a rules call that is triggered on simplesamlphp_auth_rules_event_login and clears the message queue.