fix: Wire up Device Storage Method session setting to SDK configuration#947
fix: Wire up Device Storage Method session setting to SDK configuration#947
Conversation
…tion The "Device Storage Method" setting in the plugin UI (Advanced > Sessions) allows choosing between "Encrypted Cookies" and "PHP Native Sessions (Recommended)", but importConfiguration() never reads this option. The SDK always defaults to CookieStore regardless of the setting. This causes large encrypted session cookies (chunked across auth0_session_0, _1, _2, etc.) that can exceed nginx's default 8KB header buffer limit, resulting in "400 Bad Request: Request Header Or Cookie Too Large" errors. Changes: - Read the sessions.method option in importConfiguration() and set a SessionStore on the SdkConfiguration when PHP sessions are selected - Guard the setState() call in onShutdown() with an instanceof check, since setState() is CookieStore-specific and causes a fatal error when SessionStore is used
| } | ||
|
|
||
| if ('sessions' === $this->getOptionString('sessions', 'method')) { | ||
| $sdkConfiguration->setSessionStorage(new SessionStore($sdkConfiguration, $sdkConfiguration->getSessionStorageId())); |
There was a problem hiding this comment.
SessionStore also doesn't call session_write_close() anywhere, and WordPress doesn't either. PHP sessions lock the session file for the entire request, so concurrent AJAX requests from the same user will queue up and wait for each other instead of running in parallel. Might cause noticeable slowness in the admin.
| ); | ||
| } | ||
|
|
||
| if ('sessions' === $this->getOptionString('sessions', 'method')) { |
There was a problem hiding this comment.
Have we checked how this behaves on managed WordPress hosts (WP Engine, Kinsta, Pantheon etc.) SessionStore calls session_start() internally, and a lot of these hosts strip or ignore PHP session cookies at the CDN/server level. That would make SessionStore silently non-functional.
| $store->setState(true); | ||
| } | ||
|
|
||
| wp_set_auth_cookie(get_current_user_id(), true); |
There was a problem hiding this comment.
The instanceof guard above fixes the fatal, but this line still breaks rolling sessions for both storage methods. This needs the fix from #948 (passing the existing token) to actually work.
2 participants
Summary
The Device Storage Method setting in the plugin UI (Advanced > Sessions) allows administrators to choose between "Encrypted Cookies" and "PHP Native Sessions (Recommended)". However,
importConfiguration()inPlugin.phpnever reads this option - the SDK always defaults toCookieStoreregardless of the selected setting.This PR fixes two related bugs:
Plugin.php: Read thesessions.methodoption and configure aSessionStoreon theSdkConfigurationwhen "PHP Native Sessions" is selectedAuthentication.php: Guard thesetState()call inonShutdown()with aninstanceof CookieStorecheck, sincesetState()isCookieStore-specific and causes a fatal error (Call to undefined method Auth0\SDK\Store\SessionStore::setState()) whenSessionStoreis in useContext
When the plugin uses
CookieStore(the effective default regardless of UI setting), the entire user session - ID token, access token, refresh token, and user profile - is serialized and encrypted into cookies. These get chunked across multiple cookies (auth0_session_0,auth0_session_1,auth0_session_2, etc.) which, combined with standard WordPress auth cookies, can exceed nginx/server default header buffer limits (typically 8KB), resulting in:Switching to PHP Native Sessions (as the UI already advertises) stores session data server-side and only sends a small session ID cookie, completely avoiding this issue.
Changes
src/Plugin.phpuse Auth0\SDK\Store\SessionStoreimportSdkConfiguration, check ifsessions.methodis'sessions'and callsetSessionStorage()with a newSessionStoreinstancesrc/Actions/Authentication.php@var CookieStoretype annotation + uncheckedsetState()call with a properinstanceof CookieStoreguardTest plan
auth0_session_*cookies are setsetState()setState()still functions correctly