В настоящее время у меня есть сайт, который позволяет пользователям использовать пользовательские домены (т.е. вместо mysite.com/myaccount у них может быть myaccount.com). Они просто меняют A-запись своего домена, а затем мы используем виртуальный хост с подстановочными знаками на Apache, чтобы перехватывать запросы от пользовательских доменов. Настройка в основном такая, как показано ниже. Первый виртуальный хост перехватывает запросы mysite.com/myaccount, а второй будет использоваться для myaccount.com. Как видите, у них одинаковый путь и php cookie_domain.
Я заметил странное поведение в строке ниже "#The line below me"
. Когда они активны, пользовательские домены получают новый session_id при каждой загрузке страницы (это не то же самое, что и сеанс обычного домена). Однако, когда я комментирую эту строку, пользователь сохраняет один и тот же session_id при каждой загрузке страницы, но этот session_id не совпадает с тем, который они видели бы на сайте не-пользовательского домена, несмотря на то, что он полностью находится на одном сервере.
Существует своего рода обходной путь «взлома», включающий перенаправление пользователя на mysite.com/myaccount, получение идентификатора сеанса, перенаправление обратно на myaccount.com, а затем использование этого идентификатора на myaccount.com. Но это может стать немного запутанным (например, если пользователь выходит из mysite.com/myaccount, откуда myaccount.com узнает?).
Как бы то ни было, я использую базу данных для управления сеансами (т.е. чтобы не было проблем с нахождением на разных серверах и т. Д., Но это не имеет значения, поскольку мы в любом случае используем только один сервер для обработки всех запросов в настоящее время).
Я почти уверен, что это связано с какой-то защитой браузера CSRF, но не должно ли быть достаточно умным, чтобы знать, что он находится на том же сервере?
Примечание: это поддомены, это целые отдельные домены (но на одном сервере).
<VirtualHost *:80>
DocumentRoot "/opt/local/www/mysite.com"
ServerName mysite.local
ErrorLog "/opt/local/apache2/logs/mysite.com-error.log"
CustomLog "/opt/local/apache2/logs/mysite.com-access.log" common
<Directory "/opt/local/www/mysite.com">
AllowOverride All
#php_value session.save_path "/opt/local/www/mysite.com/sessions"
php_value session.cookie_domain "mysite.local"
php_value auto_prepend_file "/opt/local/www/mysite.com/core.php"
</Directory>
</VirtualHost>
#Wildcard (custom domain) vhost
<VirtualHost *:80>
DocumentRoot "/opt/local/www/mysite.com"
ServerName default
ServerAlias *
ErrorLog "/opt/local/apache2/logs/mysite.com-error.log"
CustomLog "/opt/local/apache2/logs/mysite.com-access.log" common
<Directory "/opt/local/www/mysite.com">
AllowOverride All
#php_value session.save_path "/opt/local/www/mysite.com/sessions"
# The line below me
php_value session.cookie_domain "mysite.local"
php_value auto_prepend_file "/opt/local/www/mysite.com/core.php"
</Directory>
</VirtualHost>
Конечно, вы могли бы сделать это довольно легко, передав SID между доменами?
Ключевым моментом является перенос сеанса - как вы его выполняете, зависит от вас.
Либо через GET с использованием SID, либо на уровне приложения. Если у вас есть таблица БД с комбинированным хешированным идентификатором (IP + UserAgent + OS и т. Д.) И соответствующим SID. Тогда вы можете «обнаружить» пользователя - сопоставить идентификатор и установить соответствующий сеанс.
Однако, если он не выполняется должным образом, вы можете либо перехватить сеанс, либо полностью его потерять.
В качестве альтернативы более приятным способом было бы использовать сторонний сайт / службу для аутентификации (OpenID / Google / Facebook / Twitter и т. Д.). Затем вы можете использовать это для подсчета с соответствующим сеансом на стороне сервера.