The situation is such

there are two sites (domain.com, a.domain.com), with a single database, and so on.

If you log in and log out of the main domain, cookies are created and deleted for all domains.

If you log in with a.domain.com, then cookies are created for all domains, but they are not deleted. If you exit from the main domain, cookies remain on A :(

How to overcome it?

When you exit, I indicate that you need to leave all subdomains, putting a dot in front of the domain: .domain.com

public static function authorize($user) { if (self::isAuthorize()) { return; } $_SESSION[self::KEY_TOKEN] = $user->token; $_SESSION[self::KEY_ID] = $user->id; setcookie(self::KEY_TOKEN, $user->token, time() + 3600 * 24 * 365, '/', 'domain.com', self::isHttps(), self::HTTP_ONLY); setcookie(self::KEY_ID, $user->id, time() + 3600 * 24 * 365, '/', 'domain.com', self::isHttps(), self::HTTP_ONLY); } # выходим с авторизации public static function exit() { unset($_SESSION[self::KEY_TOKEN]); unset($_SESSION[self::KEY_ID]); setcookie(self::KEY_TOKEN, null, null, '/', '.domain.com', self::isHttps(), self::HTTP_ONLY); setcookie(self::KEY_ID, null, null, '/', '.domain.com', self::isHttps(), self::HTTP_ONLY); }
  • Of course, as an option, it is possible to put links to entry and exit on domain A on domain.com and then redirect back to A. site. - Alexander
  • I tried to reproduce using a test case - this behavior is not observed. And what are the values ​​of self::isHttps() and self::HTTP_ONLY ? And if you try to put cookies on the domain .domain.com ? - Artem Korsunov 2:49 pm
  • @ Alexander перенаправлять обратно на сайт А and catch an endless redirect - the logic will be very shaky in this case. - Goncharov Alexander

1 answer 1

Why do you bet on domain.com and shoot with .domain.com ? PHP sends this to the Set-Cookie header as is, and browsers may not understand. The second point - try the last two parameters self::isHttps(), self::HTTP_ONLY to remove: for the experiment (they are usually left by default).

One more thing - try to remove cookies, putting down the present time in the past instead of null :

 setcookie(self::KEY_TOKEN, '', time() - 86400, '/', 'domain.com');//например так

Otherwise, they say, not all browsers will understand that this is a reset - again. And there are no errors, a cookie from a subdomain that lives in the space of the main domain: this is normal, but vice versa: the security policy will not miss.

  • "Why do you bet on domain.com and shoot with .domain.com?" The problem is that if you set a cookie for .domain.com, then when you authorize with A.domain.com, cookies are created for * .a.domain.com and then the output, even from the main domain, is not deleted :( I bow to the decision create a single authorization form, as on many, like mail, gmail, yandex, create an auth.domain.com domain and send in / out requests there, creating and deleting cookies for domain.com. - Alexander
  • "And there are no errors, a cookie from a subdomain that lives in the main domain space: this is normal, but vice versa: the security policy will not miss." THEN you can log in with another account :( the cookie is not overwritten and the old one does not crash. And this is bad. - Alexander
  • @ Alexander do not rush to solve difficult simple problems. With a subdomain, you can put cookies in a common space (in the domain): many people use this, there are no problems. So put the cookie in the domain space - on 'domain.com'. The point in the domain of cookies is generally controversial, see what they write on PHP net php.net/manual/ru/function.setcookie.php Старые браузеры, следующие устаревшему документу » RFC 2109, могут требовать . перед доменом, чтобы включались все поддомены. Старые браузеры, следующие устаревшему документу » RFC 2109, могут требовать . перед доменом, чтобы включались все поддомены. . If the question is in authorization, it is better to use the session, just change the domain - php.net/manual/ru/function.session-set-cookie-params.php - Goncharov Alexander