search

psignoret / aad-sso-wordpress

Single Sign-on with Azure Active Directory (for WordPress)
Other
270 stars 78 forks source link

Getting error "Session does not contain antiforgery ID" #262

Closed admin-eschaeffer58 closed 1 year ago

admin-eschaeffer58 commented 1 year ago

We have been using this plugin for years and at some point in the last week, we started to get the ANTI_FORGERY error where there was no ID present. I tried completely deleting the plugin and reinstalling it with no change.

We have another "stage" instance that is on the same version of WP and the plugin that is not seeing the issue. Both Prod and stage instances are connected to the same azure AD via different registered apps with the exact same settings (other that client id/secret). It's driving me mad and now our org can't login at all. I have seen several bugs open on this with no resolution.

admin-eschaeffer58 commented 1 year ago

I found in the code where the error was coming from and put a print_r($_SESSION) in the conditional, that triggers the error and it appears that no session data is being returned. I get an empty array output.

Array ( )

admin-eschaeffer58 commented 1 year ago

Ok, so ended up figuring the issue out. Turns out the session path for the php instance on this cpanel server was invalid. Once I set a valid path, it fixed the issue.

psignoret commented 1 year ago

Thanks for reporting, and thanks for following up with the issue on your side and how you solved it. Indeed, this issue is always something to do with sessions, but the root cause is rarely the same, and is usually dependent on the infrastructure WordPress is installed on.

I'll use the information you shared to improve the troubleshooting options available, and try to see if there isn't a better way to achieve the same capability without relying on PHP sessions.

bradkovach commented 1 year ago

Is it possible to detect invalid PHP configurations before letting people engage wordpress login bypass? I'm just thinking that becoming more fail safe would be a valuable improvement.

On Sun, Feb 19, 2023 at 3:47 AM Philippe Signoret @.***> wrote:

Thanks for reporting, and thanks for following up with the issue on your side and how you solved it. Indeed, this issue is always something to do with sessions, but the root cause is rarely the same, and is usually dependent on the infrastructure WordPress is installed on.

I'll use the information you shared to improve the troubleshooting options available, and try to see if there isn't a better way to achieve the same capability without relying on PHP sessions.

— Reply to this email directly, view it on GitHub https://github.com/psignoret/aad-sso-wordpress/issues/262#issuecomment-1435954112, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAPS3WIRKUGV34MWM7FWW33WYH24DANCNFSM6AAAAAAVAWXT5M . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Brad Kovach

psignoret commented 1 year ago

Yeah, I was thinking of testing PHP sessions at config time (show warnings and allow saving but not enabling) and at runtime (show useful error instead of redirecting to a sign-in which is guaranteed to fail).