Доступ к cookie зависит от домена сервера, который пытается прочитать запрос, и, возможно, от домена, указанного в cookie. Таким образом, предполагая, что домены совпадают (например, www.example.com и www.example.com в блоге и в приложении Rails), либо должны иметь доступ к cookie, установленному другим.
Если это не так (например, blog.example.com, www.example.com), вам необходимо убедиться, что файл cookie установлен в любом месте, он установлен для всего домена (например, .example.com
). Но это не помогает: хотя Rails может удалять cookie WP и наоборот, метод их создания (и использования) должен быть взаимно понят.
Итак, здесь есть поворот, поскольку это сессионный cookie; в этом случае cookie (к которому у любого приложения должно быть доступ) устанавливает значение, которое используется и интерпретируется на стороне сервера, где управляются сеансы. WordPress и Rails используют разные методы и ищут разные файлы cookie.
Решение (идея) состоит в том, чтобы одна или другая подсистема перехватывала входящие запросы (скорее всего, WP, и, возможно, через какой-то .htaccess
RewriteRule, предполагая, что вы используете Apache) и создавала промежуточный cookie, который другой мог бы убедитесь, что это достаточное доказательство того, что пользователь вошел в систему правильно. PHP для этого довольно хорош и легко расширяется - вам просто нужно создать токен, который будет общим секретом для двух приложений (одно из значений в wp-config.php
, такое как LOGGED_IN_KEY
, может быть хорошим вариантом).
Возможно, решением было бы взять общедоступное значение из файла cookie WP для имени пользователя, добавить значение общего секретного ключа и (в обеих системах) создать хеш MD5 для хранения в файле cookie. В этом случае аутентификация Rails будет подчиняться WP, поэтому вам необходимо убедиться, что Rails знает, как делегировать такие вещи, как забытый пароль, измененный пароль и т. Д., В механизмы WP.
Очевидно, я думаю вслух, но, возможно, это путь для рассмотрения.
В любом случае, это предпочтительнее, если обе системы знают, как доверять аутентификации другого.