Авторизация через HTTPS, работа с закрытым разделом сайта через HTTPS

Аватар пользователя igorpol3 igorpol3 8 мая 2012 в 20:15

Доброго времени суток, коллеги.

Следуя принципу "Бесплатно взял - бесплатно отдай", решил поделиться. Возможно, кому-то окажется полезным.

Итак, стояла следующая задача:
1. Часть разделов сайта на Drupal 7 должна быть доступна только авторизованным пользователям.
2. Соответственно, сама авторизация (ввод логина/пароля) должна проходить через HTTPS, иначе какой в ней толк?
3. После авторизации пользователи должны работать с материалами в закрытом разделе сайта тоже через HTTPS.

Задачу решил так.

1. Убрал вывод блока авторизации со всех страниц сайта, разрешил его через настройки блоков только в одной ноде, в основной части материала типа Basic Page (синоним страницы: "user-login"). В самой страничке только пара фраз текста, типа "Для входа на сайт введите свои регистрационное имя и пароль...". Вид странички см. в прикрепленном скрине.
2. В одном из блоков (в подвале) сделал меню с единственной ссылкой "Вход для пользователей", указывающей на страницу "user-login". В настройках отображения блока поставил "только для анонимных пользователей". Таким образом, если вход не выполнен - ссылка есть. Залогинился - исчезла.
3. Настроил Apache для работы с SSL. Останавливаться на процессе не буду, в сети море ссылок на подобные темы. Тем более, что на хосте пользую Zentyal, там все в разы проще, все делается через web-интерфейс.
4. Разрешил Drupal'у работу с HTTPS. Для этого добавил в /sites/.../settings.php следующий код: "$conf['https'] = TRUE;" (без кавычек, разумеется).
5. Установил модуль "Secure Login", который автоматом перенаправляет пользователя по протоколу HTTPS, если видит, что на странице форма авторизации. Собственно, ради этого и убрал форму авторизации со всех страниц. Иначе модуль добрую половину страниц сайта перенаправлял бы через HTTPS. Ничего страшного, конечно, но для обычных посетителей запрос браузера на тему того, что нужно бы принять сертификат - лишняя морока.
6. Поставил модуль "Auth SSL Redirect", который, типа, должен автоматом перекидывать всех авторизованных пользователей на HTTPS.
7. Однако, после успешной авторизации на странице "user-login" форма ввода пароля исчезала, оставляя за собой только глупую надпись в начале статической страницы. Конечно, можно было бы и поэлегантней решение найти, но у меня железный принцип: "лучше убить полчаса на поиск подходящего решения, чем сутки на поиск лучшего". А посему просто добавил в модуле Rules обработку события, реагирующего на успешную авторизацию. Теперь, после авторизации правило обработки события перенаправляло пользователя на главную страницу сайта.

Вуаля.

В заключение хочу сказать: Drupal - система невероятно гибкая и, конечно, существуют другие решения, но это отыскалось за каких-то 30 минут и пока вполне устраивает.
Рад, если кому-то пригодится.

Засим кланяюсь.

ВложениеРазмер
Иконка изображения stranica_avtorizacii.png73.33 КБ

Комментарии

Аватар пользователя igorpol3 igorpol3 9 мая 2012 в 8:12

Сертификат самоподписанный, выдал сам себе через службу CA Zentyal-сервера. Удобная штука.

Аватар пользователя igorpol3 igorpol3 9 мая 2012 в 12:02

Ругаются, как это обычно и бывает со всеми самоподписанными сертификатами. Но свое дело делают, трафик шифруют. Большего и не требуется.
Чтобы не ругались, необходимо установить в системе свой корневой сертификат, и тогда браузер будет ему доверять. Для этого можно разослать его своим пользователям или опубликовать на сайте с соответствующими инструкциями.

Если возиться неохота, можно купить сертификат у одного из удостоверяющих центров, лучше всего - у того, корневой сертификат которого уже включен в систему. Да много способов.

Главное - защитить пару авторизации логин-пароль от прослушки , для чего обязательно пускать по закрытому протоколу процесс авторизации. Моя схема это делает.

Аватар пользователя Antoniy Antoniy 9 мая 2012 в 12:05

igorpol3 wrote:
Главное - защитить пару авторизации логин-пароль от прослушки

И регистрацию новых пользователей

Аватар пользователя igorpol3 igorpol3 9 мая 2012 в 12:17

Ну это естественно. Правда, в моем случае саморегистрация запрещена, доступ к системе выдается по запросу, после получения логина/пароля при первом входе пользователь сам меняет пароль.

Аватар пользователя Antoniy Antoniy 9 мая 2012 в 13:35

Интересно, при публичном ресурсе с публичной регистрацией, на сколько это защитит от проблем типа "ваш профиль взломан" типа как в ВК и т. п.?

Еще бы навешивать https на формы заказа, сделанные модулем Webform, для анонимов. Не стояла такая задача?

Аватар пользователя igorpol3 igorpol3 9 мая 2012 в 13:45

Стояла и частично выполнена. Все ссылки, которые ведут на формы, принудительно перекрашиваются на https. Также достаточно несложно организовать проверку на входе в страницу формы, по какому протоколу осуществлен вход. Если по незащищенному - то отлуп, если по закрытому - велком. Но эту часть я пока отложил.

Что до публичных ресурсов, то тут механизмы шифрования и их недостатки играют роль второстепенную, как мне кажется. На первый план выходят "легкие" пароли пользователей, недостаточная защищенность баз данных и технология, позволяющая допускать к работе недостаточно выверенный персонал (а также позволяющая недобросовестному персоналу обширный доступ к данным). Впрочем, я не эксперт.

Аватар пользователя Antoniy Antoniy 9 мая 2012 в 13:48

igorpol3 wrote:
На первый план выходят "легкие" пароли пользователей

Может модуль есть, который не позволяет ставить легкие пароли. Измерение пароля "слабый, средний, сильный" уже есть в коробке.

Аватар пользователя igorpol3 igorpol3 10 мая 2012 в 19:39

Нас забанят за спам Smile
Мы как-то постепенно вылезли за границы обсуждения моего, в общем-то, тривиального решения.

Аватар пользователя Antoniy Antoniy 10 мая 2012 в 19:45

Где же тут спам?

Тема обсуждения расширяется по направлению информационная безопасность в Друпал. Уверен, не только нам будет полезно.

Вот еще интернет-магазины. Когда анонимус нажимает "оформить заказ" его должно отправлять в https. Он там конфиденциальное данные вводит: как минимум, свой адрес доставки (в большинстве случаев это адрес проживания).

Аватар пользователя igorpol3 igorpol3 11 мая 2012 в 20:42

Модуль Secure Login, как мне кажется, как для того, о чем вы говорите. Его можно настраивать и принудительно указывать формы и страницы, которые он будет перехватывать. С его помощью можно избавиться, по крайней мере, от очень неприятной вещи - от атак присоединением посередине (Session hijacking).

Аватар пользователя Abdula Abdula 13 ноября 2012 в 20:41

А кстати, как относятся поисковики при такой работе Друпала?
Они ведь не понимают и обходят стороной сайты с https.
То есть в смысле рейтинга такие сайты пролетают?

Аватар пользователя igorpol3 igorpol3 15 ноября 2012 в 10:14

Это закрытый раздел сайта, который не должен быть виден никому, кроме авторизованых пользователей,поэтому никак не относятся. Им просто закрыт туда доступ. В том числе через настройки robots.txt. Но если будет такое желание, можно настроить поиск и по https. Делается через установку и настройку модулей от соответствующих поисковиков. Например, от Яндекса идет вот этот: http://drupal.org/project/yandex_metrics
Для гугла есть свой модуль. Разумеется, придется настроить карту сайта.

Аватар пользователя Abdula Abdula 16 ноября 2012 в 2:22

Еще вопрос по Secure Login - этот который вот этот, от некоего avf ? http://drupal.org/project/securelogin
Тогда получается, что в нем для 6-й версии до сих пор нет нормального релиза, только девелопы.
Вы какой конкретно ставили?

Аватар пользователя Abdula Abdula 17 ноября 2012 в 4:21

Афтор топика что-то приумолк, не спешит делится опытом. Что ж, продолжу я.
Выполнил вышеуказаныне п.п. 3, 4, 5, 6 в следующем объеме:

3. Настроил Apache для работы с SSL.
4. Разрешил Drupal'у работу с HTTPS. Для этого добавил в конфиг /sites/.../settings.php следующий код: $conf['https'] = TRUE;
5. Скачал на странице http://drupal.org/project/securelogin и установил модуль securelogin-6.x-1.x-dev.tar.gz
Обращу внимание, что хотя для 6-го Друпала для этого модуля существует только девелоперская сборка, но проблем при ее установке замечено не было.

6. Скачал на странице http://drupal.org/project/auth_ssl_redirect и установил модуль Auth SSL Redirect: auth_ssl_redirect-6.x-1.2.tar.gz

При включении модулей в работу оба вздыбились и честно предупредили, что а агрессивном режиме кеширования работать не будут.

Результат: при входе на сайт в режиме HTTPS и последующей авторизации остаемся в этом режиме.
Но стоит сунуться в друпальскую админку (где как раз и нужна повышенная защищенность) - тут же вываливаемся в обычный HTTP.

В общем, разработчики Друпала сделали все возможное, чтобы нагадить режиму HTTPS - даже использование двух спецмодулей не помогли ему надежно удержаться в защищенном режиме.

PS. Судя по сайту, афтор топика для своего проекта использовал 7-й Друпал. Вначале тоже его установил, но из-за жутких тормозов пришлось снова откатиться на 6-й.

Аватар пользователя Abdula Abdula 18 ноября 2012 в 0:43

Кроме того, оказалось, что если заходить просто по HTTP, то после авторизациии в нем и остаешься.
Получается, что ни один из модулей SecureLogin и Auth SSL Redirect не срабатывает.
Зато нашелся еще один модуль - Secure Pages http://drupal.org/project/securepages , который тоже якобы обеспечивает работу в https.

Что-то модулей становится больше и больше, а толку по прежнему нет. Лучше бы встроили https прямо в ядро Друпала - было бы куда меньше мороки с ним.

Аватар пользователя igorpol3 igorpol3 10 ноября 2015 в 11:48

Отвечаю оптом.

Про работу модуля на Drupal-6 мне ничего неизвестно, я работаю с седьмой версией. В семерке все нормально. Добавлю, что я не научно-исследовательский институт, целью протестировать все и вся не задавался. У меня была задача, я ее решил, после поделился, как именно.

Далее. Используя оба модуля, можно закрыть любую страницу. Это к вопросу админки и прочего. Так что если нужно закрыть что-то от прослушки, проблем быть не должно.

Честно говоря, я вообще не понял, что тут обсуждать. Задача тривиальная. И решена тривиальным способом.

Ну, предположим, вам нужно, чтобы какие-то ноды были доступны только авторизованым пользователям. Ну что, это как два пальца, что назыввается. В настройках ноды ставите в списке доступа "Только авторизованным пользователям". Далее через Secure Login (см. вложение) указываете, что форма авторизации должна идти через HTTPS. Далее включаете модуль SSL-редиректа Auth SSL Redirect, который перенаправляет всех авторизованных пользователей принудительно на HTTPS. Вот и все.

Если не нравится Auth SSL Redirect, можно решить задачу кучей способов маленькой вставкой на PHP. Просто определять в начале страницы, по какому протоколу был произведен вход, и если не по закрытому, делать перенаправление. Чего проще-то?

Аватар пользователя Abdula Abdula 16 декабря 2012 в 23:56

В-общем, надоело мне долбаться с этими SSL-модулями для 6-й версии, и замутил это дело по-другому, проще - сконфигурировал Nginx на общее перенаправление всех http на httpS.
И все было бы прекрасно, но обнаружился один косячок в Друпале. Оказалось, что:
- весь текстовый контент перенаправляется на httpS
- изображение логотипа тоже - https://mysite.info/sites/default/files/logo_type.png
- а вот изображения аватаров и смайликов каким-то непонятным образом игнорируют это общее перенаправление - они по прежнему идут по http:-
http://mysite.info/sites/default/files/pictures/avatar.gif
http://mysite.info/sites/default/files/smiley/Roving/smile.png

Почему это так происходит и как победить?

Аватар пользователя Abdula Abdula 17 декабря 2012 в 20:19

Не знаете? Хорошо, спрошу по другому, по-проще:

- почему наш любимый Друпал формирует относительные ссылки на логотип, и абсолютные - на аватары и смайлики?

Т.е. изображение логотипа как /sites/default/files/logo_type.png
- а аватаров и смайликов как http://mysite.info/sites/default/files/pictures/avatar.gif
и http://mysite.info/sites/default/files/smiley/Roving/smile.png