Regression: GET /me returns 401 when user is authenticated via 'dbAuth' middleware

[NorthFred]

Regression issue found in PHP API v.2.14.19 and not reproducible in at least 2.14.10.

An existing project which uses the 'dbAuth' authentication middleware now reports a 401 with error code 1011 when a user is logged in and makes a request to the '/me' endpoint. Issue was observed when upgrading to API v.2.14.19. Previously, GET /me would return a 200 for logged-in users.

[mevdschee]

I checked the code path and I see no obvious problems. Can you reproduce this with only the dbAuth middleware loaded?

[mevdschee]

@NorthFred Can you help me with some reproduction steps?

[mevdschee]

Did you set one or both of these?

"dbAuth.usersTable": The table that is used to store the users in ("users")
"dbAuth.loginTable": The table or view that is used to retrieve the users info for login ("users")

I've fixed a bug there recently.

[NorthFred]

@mevdschee I have retested this with API v.2.14.19 and the error is reproducible when I serve the front-end of the application locally. This is NOT reproducible with a live production version of the UI client.

I realized now that in the old version 2.14.10, I had made a small modification to this block of code (added an extra condition for same site requests):

        public function process(ServerRequestInterface $request, RequestHandlerInterface $next): ResponseInterface
        {
            if (session_status() == PHP_SESSION_NONE) {
                if (!headers_sent()) {
                    $sessionName = $this->getProperty('sessionName', '');
                    if ($sessionName) {
                        session_name($sessionName);
                    }
	            // Custom condition added below:
	            if (isset($body->allowSameSite)) {
		            session_set_cookie_params(['samesite' => 'None', 'secure' => true]);
	            }
                    // End custom condition
                    session_start();
                }
            }

Whereas in version 2.14.19, I see that same block has been updated as follows:

        public function process(ServerRequestInterface $request, RequestHandlerInterface $next): ResponseInterface
        {
            if (session_status() == PHP_SESSION_NONE) {
                if (!headers_sent()) {
                    $sessionName = $this->getProperty('sessionName', '');
                    if ($sessionName) {
                        session_name($sessionName);
                    }
                    if (!ini_get('session.cookie_samesite')) {
                        ini_set('session.cookie_samesite', 'Lax');
                    }
                    if (!ini_get('session.cookie_httponly')) {
                        ini_set('session.cookie_httponly', 1);
                    }
                    if (!ini_get('session.cookie_secure') && isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] != 'off') {
                        ini_set('session.cookie_secure', 1);
                    }
                    session_start();
                }
            }

[mevdschee]

Ah.. thank you! You are reporting the same issue as is reported in #953. Can you help me how to decide between 'Lax' and 'None'? What are the conditions that apply for the 'None' case? Should the server be on localhost?

[NorthFred]

@mevdschee For my use case, the condition was added to fix issues with localhost only. I'm afraid I'm not able to comment further on this :/

[mevdschee]

I think a cookie should either be set to secure and samesite lax or not secure and samesite none.

[nik2208]

there should be some avoid_cors_issues_on_localhost opition to set session_set_cookie_params(['samesite' => 'None', 'secure' => true]); for development purposes