Я использую что-то вроде этого в файле .htaccess, чтобы ограничить доступ к сайту:
AuthUserFile /some/directory/.passwd
AuthGroupFile /dev/null
AuthName EnterPassword
AuthType Basic
require valid-user
Это нормально работает, но пользователя просят аутентифицироваться каждый раз, когда изменяется субдомен, например user1.mywebsite.com, user2.mywebsite.com или просто mywebsite.com
Есть ли способ сообщить Apache2, что когда пользователь аутентифицируется в одном поддомене, он должен также предоставить ему доступ ко всем остальным?
Это невозможно сделать с помощью базовых спецификаций HTTP. Области bob.example.com и elisa.example.com - это две разные области защиты, и почти каждый браузер будет рассматривать их как две отдельные, разные области, которым должны быть предоставлены разные учетные данные для аутентификации.
Но выход есть - HTTP-дайджест auth. Это позволяет вам указать все домены, которые являются URL-адресами в области защиты. Однако он не позволяет использовать поддомены с подстановочными знаками, поэтому после десятка доменов он получает настоящий PITA. Пример config.
<Location />
AuthType Digest
AuthName "teh realm"
AuthDigestAlgorithm MD5
AuthDigestDomain / http://domain.com/ http://subdomain.domain.com/
AuthDigestQop auth
AuthDigestProvider file
AuthUserFile /etc/apache2/.htpasswd-digest
</Location>
IMO, ваш единственный выбор - написать собственный аутентификатор FastCGI, который использует файлы cookie, которые разрешают поддомены с подстановочными знаками. Если у вас мало доменов, проще использовать дайджест.
Невозможно; вы можете использовать один файл .htaccess для предоставления доступа ко всему в вашем дереве каталогов с теми же учетными данными, но аутентификация требуется для каждого уникального поддомена.
Как указывает Бенни, для этого вам понадобится аутентификация на основе сеанса в той или иной форме.
Все ли поддомены обслуживаются из подпапок одного корневого каталога? Если это так, то казалось бы, что включение этой аутентификации в .htaccess основного корневого документа может уменьшить повторную аутентификацию.
В качестве альтернативы (хотя для вашего пользователя может потребоваться некоторая разработка) вы можете попробовать аутентификацию на основе сеанса.