что такое сессия в браузере
Сессии. Подробное описание работы и объяснение механизма.
Подробно расписывать нужду в таком механизме я не буду. Это такие хрестоматийнык случаи, как корзина покупок в е-магазине, авторизация, а так же, и не совсем тривиальные проблемы, такие, например, как защита интерактивных частей сайта от спама.
В принципе, довольно несложно сделать собственный аналог сессий, не такой функциональный, как встроенный в PHP, но похожий по сути. На куках и базе данных.
При запросе скрипта смотрим, пришла ли кука с определенным именем. Если куки нет, то ставим ее и записываем в базу новую строку с данными пользователя. Если кука есть, то читаем из базы данные. Еще одним запросом удаляем из базы старые записи и вот у нас готов механизм сессий. Совсем несложно. Но есть некоторые нюансы, которые делают предпочтительным использование именно встроенного механизма сессий.
Если включена только первая, то при старте сессии (при каждом вызове session_start() ) клиенту устанавливается кука. Браузер исправно при каждом следующем запросе эту куку возвращает и PHP имеет идентификатор сессии. Проблемы начинаются, если браузер куки не возвращает. В этом случае, не получая куки с идентификатором, PHP будет все время стартовать новую сессию, и механизм работать не будет.
По умолчанию в последних версиях PHP включены обе опции. Как PHP поступает в этом случае? Кука выставляется всегда. А ссылки автодополняются только если РНР не обнаружил куку с идентификатором сессии. Когда пользователь в првый раз за этот сеанс заходит на сайт, ему ставится кука, и дополняются ссылки. При следующем запросе, если куки поддерживаются, PHP видит куку и перестает дополнять ссылки. Если куки не работают, то PHP продолжает исправно добавлять ид к ссылкам, и сессия не теряется.
Пользователи, у которых работают куки, увидят длинную ссылку с ид только один раз.
Следует помнить, что пхп лочит файл сессии. То есть, если один ваш скрипт стартует сессию и долго выполняется, а другой пытается в это время стартовать её с тем же идентификатором, то он зависнет. Поэтому в долго выполняющихся скриптах следует стартовать сессию только тогда, когда она нужна, и тут же закрывать её, с помощью session_write_close()
HTTP сессия. Session. Состояние сеанса. Работа с сессиями в ASP.NET MVC
Давайте рассмотрим такое понятие как сессия (HTTP-сессия, Session). Или по-другому, сеанс пользователя. Почему важно понимать механизм работы сессий. И посмотрим, как можно работать с состояниями сеансов на платформе ASP.NET.
Прежде чем мы дадим определение термину «сессия», давайте немного рассмотрим предысторию, зачем вообще возникла потребность в сессиях, рассмотрим одну особенность протокола HTTP.
Одной из основных особенностей протокола HTTP является то, что он не обязывает сервер сохранять информацию о клиенте между запросами, то есть идентифицировать клиента. Это так называемый stateless-протокол. Связь между клиентом и сервером заканчивается как только завершается обработка текущего запроса. Каждый новый запрос к серверу подразумевается как абсолютно уникальный и независимый, даже если он был отправлен повторно от одного и того же источника.
Что, если оставить stateless-природу протокола HTTP и не идентифицировать пользователя? Без состояний сеанса можно легко обойтись, если на вашем сайте представлена статичная (обезличенная) информация, например, новостная статья, состоящая из текста и изображений. В таком контексте совершенно необязательно ассоциировать несколько запросов с одним пользователем. Ведь содержание статьи никак не изменится, будь то десять запросов с одного устройства, либо десять запросов от разных людей с разных устройств.
Но как только мы собираемся передать персональную информацию на сервер, нам необходимо каким-то образом сделать так, чтобы сервер ассоциировал все наши запросы именно с нами, и в будущем верно определял все исходящие от нас запросы. Если этого не сделать, то с каждым новым запросом мы будем вынуждены повторно передавать необходимые персональные данные. Например, логин для входа в личный кабинет на сайте, или такую информацию как имя, адрес доставки, при совершении покупки в интернет-магазине.
Вот как раз в таких ситуациях, когда требуется персонализировать запросы от одного клиента, мы будем использовать сессии.
Когда клиент впервые передает персональные данные в запросе, на сервере создается новая сессия для этого клиента. В период времени жизни сессии все запросы от этого клиента будут однозначно распознаны и связаны с ним. По истечении этого времени связь с клиентом будет потеряна, и очередной запрос от него будет обрабатываться как абсолютно уникальный, никак не связанный с предыдущими.
Например, при совершении покупки в онлайн магазине персональная информация пользователя сохраняется в сессии, пока он путешествует по сайту. Это выбранные товары в корзине, адрес доставки, контактные данные и так далее.
Теперь давайте посмотрим, как это мы можем реализовать технически. Вообще существует несколько техник управления сессиями клиента, их количество и способ реализации во многом зависит от веб-платформы или технологии, что работает на сервере. В этом уроке мы рассмотрим следующие:
Попробуем их реализовать, используя платформу ASP.NET. Давайте кратко рассмотрим первые два механизма, и особое внимание уделим третьему, как более надежному, удобному и безопасному.
Скрытые поля на HTML-форме (hidden form fields)
Суть данного подхода состоит в том, что мы обеспечиваем навигацию по сайту при помощи стандартных html-форм. И при каждом следующем запросе мы сохраняем данные из предыдущего в скрытых полях на форме. Например:
Давайте рассмотрим особенности такого подхода. Плюсов практически нет, разве что реализовать данную технику можно очень быстро. Но опять же и другие подходы тоже можно реализовать очень быстро. А вот минусы есть, и довольно существенные:
Куки (cookies)
В данном подходе мы не храним сессионные данные непосредственно на форме, вместо этого используется стандартный механизм работы cookies между клиентом и сервером. В cookies и хранятся все пользовательские данные.
При выборе этого подхода опять же главной остается проблема безопасности наших данных, которые мы передаем на сервер – их легко подменить или украсть, они лежат в открытом виде. Также, если в настройках приватности браузера клиента отключен прием куки с сайтов, то такой вариант ведения сессии вовсе не будет работать.
Серверный механизм управления сессией (Session, SessionState)
Разберем, как работает механизм сессии со стороны сервера и со стороны клиента.
При стандартных настройках работы состояния сеанса для отслеживания серии запросов от одного клиента используется т.н. сессионная куки (session cookie). Алгоритм следующий:
В этом участке кода мы записываем в состояние сеанса имя пользователя. Это имя мы забираем с html-формы, которую он нам отправил. Дополнительно через свойства мы узнаем, создана ли эта сессия только что, то есть в рамках текущего запроса (если да, то и значение свойства IsNewSession будет равняться true), и уникальный идентификатор сессии. Этот идентификатор после обработки запроса будет автоматически записан в сессионную куки (если еще нет) и отправлен в ответе клиенту.
В браузере клиента можно наблюдать соответствующую куки и идентификатор его сессии:
В процессе следующего запроса от этого клиента давайте прочитаем его ранее сохраненное имя из сессии. Также принудительно завершим сессию. Работа с этим клиентом закончена, например, все данные обработаны и товар отправлен.
Как видно, работать с сессиями очень просто и удобно. Большинство процессов, связанных с обработкой сессии, происходит автоматически в фоновом режиме. Естественно, разработчик может вмешаться на любой стадии обработки сессии и внести свои коррективы.
В конфигурации выше мы указали, что таймаут сессии будет 40 минут, сессионные данные пользователя будут храниться в оперативной памяти, будут использоваться сессионные куки, также поменяли стандартное название такой куки на собственное.
Кэш, куки и сессия браузера: применение в сфере тестирования ПО
С понятиями кэш, куки и сессия в браузере должен ознакомится каждый QA-инженер, который предоставляет услуги по тестированию веб-продуктов.
Очень часто, при «столкновении» с данными терминами, возникает много вопросов.
Чтобы максимально раскрыть каждое из данных понятий, узнать их области применения и алгоритм использования (исходя из применяемого браузера), рассмотрим каждое более детально.
Сookies (куки) – определенное количество информации, создающееся сервером после того, как пользователь посетил страницу, и которое остается на ПК пользователя как отдельный текстовый документ.
В основном, куки хранят идентификационную информацию, данные о пользователе, о характеристиках и настройках, которые были выбраны в процессе взаимодействия со страницей, а также другие подобные данные, относящиеся к служебным.
Если куки поддерживаются браузером, то при каждом следующем запросе весь объем информации транспортируется от пользователя на сервер. Какая польза для сайта от этих данных?
Как правило, идентификационная информация используется сервером, чтобы:
Если рассматривать куки с технической точки зрения, то это текстовые документы небольших размеров. Максимальный объем куки-файла – 4096 байт.
Что находится в документе куки:
Сессия
Веб-сервера имеют одну важную особенность, которая кроется в том, что они не могут распознавать откуда каждый раз поступают запросы (с одного и того же браузера или с разных).
Это происходит потому, что HTTP протокол «не разрешает» прослеживать ход этих состояний и, соответственно, поддерживать беспрерывную связь с посетителем.
Каждый запрос проходит обработку отдельно, без малейшей связи с прошедшими.
Данную проблему позволяет решить сессия браузера (сеанс) – механизм отслеживания запросов от одного браузера, способный сберечь некоторые переменные в процессе переходов между страницами веб-продукта.
Со стартом сессии, на сервере создается документ, где находятся данные о клиенте, его манипуляциях и событиях, произошедших в пределах одной сессии. Это может быть просматривание сайта, действия с составляющими деталями страниц, произведение транзакций и прочее.
Пока сеанс длится, новый начаться не может.
Предыдущая сессия закончится только в том случае, когда будет реализовано одно из условий (зависит от настроек):
Всем прекрасно известно, что для высокого качества работы в интернете, сайт должен быстро загружаться.
Увеличенное время ожидания отклика страницы может привести к тому, что посетитель просто закроет ее и перейдет на другую, более оптимизированную. Поэтому, в интересах разработчика, не допускать подобного.
Вся сложность ситуации в том, что сервер, при каждом обновлении страницы, транспортирует браузеру достаточно большой объем информации. Естественно, это негативно влияет на скорость работы сайта. Для решения этой проблемы и оптимизации веб-программ, создали кэш.
Например, ваша сеть интернет работает медленнее, нежели компьютер. С помощью кэша, браузер локально сохраняет определенную часть данных на ПК клиента.
Как результат, в повторной загрузке идентичной информации нет необходимости, требуемые данные просто грузятся из памяти ПК без подключения к сети.
Естественно, загрузка страницы, при таком раскладе, происходит значительно быстрее.
Что, в основном, хранится в кэше? Обычно страницы одного сайта имеют однотипный дизайн, в следствие этому, есть элементы сайта, которые дублируются на разных страницах.
Чтобы при каждом переходе не передавать одинаковый снимок, он локально загружается в файлы кэша и при обновлениях уже грузится с жесткого диска пользователя, а не через сервер.
Кроме логотипов, кэшироваться могут текстовые сообщения, видео-файлы, звук.
Кэш браузера ограничен в размере. Его максимальный объем настраивается. Когда хранилище кэша заполнено, то те данные, которые дольше всего не были в использовании, удаляются, тем самым освобождая пространство новым частям.
После того, как мы разграничили термины «сессия», «кэш» и «куки», перейдем к непосредственному процессу их применения.
В целом, обычному пользователю вполне хватить умений включить или выключить, отредактировать или удалить куки, произвести очистку кэша и суметь обнаружить данные документы на своем ПК.
Как выполнить очистку кэша на компьютере?
В первую очередь, нужно учитывать, какой браузер используется для работы.
Важно помнить, что кэш одного и того же веб-продукта, у разных браузеров, находится в различных файлах директории C:\Users\Admin\AppData\Local\.
Если такую папку вы не можете найти на своем ПК, следует просто в параметрах активировать демонстрацию скрытых файлов.
Каждый браузер в этой директории формирует свою файловую папку, где и находится кэш.
Представим наиболее распространенные браузеры:
Обнулить всю информацию из сайта, очистить кэш и куки можно непосредственно в браузере.
Для этого создана специальная функция, активацию которую можно выполнить в настройках.
Алгоритм у каждого из браузеров отличается, поэтому, рассмотрим подробнее процесс очистки кэша в них:
Также, существует еще один способ почистить кэш браузера, не используя его настройки. Это горячие клавиши: Ctrl+Shift+Del – для большого количества браузеров и –⌥(Option)+⌘(Command)+E для Safari на Mac.
Как найти куки на разных браузерах?
К примеру, чтобы обнаружить куки в Chrome, следует выполнить такой алгоритм действий:
Если говорить об Internet Explorer 11, то там путь выполнения немного другой: «Меню браузера» — «Свойства браузера» — «Конфиденциальность» — Сайты/Дополнительно. Здесь возможна работа с файлами куки для выбранных веб-сайтов.
Для просмотра значения сохраненных настроек определенного сайта, необходимо прибегнуть к средствам разработчика (клавиша F12). В пункте «Сеть» поданы списки запросов, а в «Файлы куки» — их данные.
Создание веб-продукта – очень динамичный процесс. Иногда, редактирование сайта осуществляется по несколько раз за день.
Любому тестировщику нельзя забывать о том, что перед выполнением непосредственной проверки продукта необходимо произвести очистку кэша.
Если не выполнить данное условие, большая вероятность того, что страница будет грузится из кэша и внедренных обновлений просто не будет видно.
Процедура сеанса подразумевает собой идентификацию браузера и обработку запросов в течение одного сеанса.
При этом, используются переменные из прошлых запросов. В основном, все данные о сессии находятся на сервере и скрыты от пользователя.
Когда QA-инженер знает сроки окончания сессии и может предвидеть поведение сайта при ее завершении, он легко напишет несколько сценариев для тестирования.
Очень часто, чтобы сайт работал корректно, нужно включить куки. При таком раскладе, проверку работы продукта можно осуществлять двумя способами: с включенными и отключенными куки.
Третий вариант проверки – редактирование куки вручную, с использованием как валидной, так и невалидной информации.
В файлах куки хранятся конфиденциальные данные пользователя для авторизации.
Применив определенный инструментарий для изменения этих данных, тестировщик может узнать, можно ли открыть доступ к аккаунту другого посетителя, отредактировав куки. Такой вид деятельности относят к тестированию безопасности.
При первом знакомстве с кэшем, сессий браузера и куки, все это кажется сложным и запутанным, но изучив терминологию и опробовав полученные знания в практической деятельности, убеждаешься, что здесь нет ничего тяжелого.
HTTP сессия
Так как HTTP — это клиент-серверный протокол, HTTP сессия состоит из трёх фаз:
Начиная с версии HTTP/1.1, после третьей фазы соединение не закрывается, так как клиенту позволяется инициировать другой запрос. То есть, вторая и третья фазы могут повторяться.
Установка соединения
Так как HTTP это клиент-серверный протокол, соединение всегда устанавливается клиентом. Открыть соединение в HTTP — значит установить соединение через соответствующий транспорт, обычно TCP.
В случае с TCP, в качестве порта HTTP сервера по умолчанию на компьютере используется порт 80, хотя другие также часто используются, например 8000 или 8080. URL загружаемой страницы содержит доменное имя и порт, который можно и не указывать если он соответствует порту по умолчанию.
Отправка запроса клиента
Когда соединение установлено user-agent может послать запрос. (user-agent это обычно веб браузер, но может им не быть) Клиентский запрос это текстовые директивы, разделённые между собой при помощи CRLF (переноса строки). Сам запрос включает в себя три блока:
Примеры запросов
Получаем главную страницу developer.mozilla.org, http://developer.mozilla.org/, и говорим серверу, что user-agent предпочитает страницу на французском, если это возможно:
Обращаем внимание на пустую строку в конце, которая отделяет блок данных от блока заголовков. Так как в запросе отсутствует Content-Length: HTTP заголовок, блок с данными пуст и сервер может начать обработку запроса, как только получит пустую строку, означающую конец заголовков.
Отправляем результат сабмита формы:
Методы запроса
HTTP определяет набор методов запроса с указанием желаемого действие на ресурсе. Хотя они также могут быть и существительными, эти запросы методы иногда называют HTTP-командами. Наиболее распространённые запросы GET и POST :
Структура ответа от сервера
После того как присоединённый агент отправил свой запрос, веб сервер обрабатывает его и отправляет ответ. По аналогии с клиентским запросом, ответ сервера — это текстовые директивы разделённые между собой CRLF, сгруппированные в три разных блока:
Примеры ответов
Успешное получение веб страницы:
Сообщение о том, что запрашиваемый ресурс был перемещён:
Сообщение о том, что запрашиваемый ресурс не существует:
Коды статусов ответа
HTTP-коды ответов показывают, выполнен ли успешно определённый HTTP-запрос. Ответы сгруппированы в пять классов: информационные ответы, успешные ответы, редиректы, ошибки клиента и ошибки сервера.
Сессии, Куки и Аутентификация
Введение
Понятие «Сессий» основано на том, что состояние пользователя каким-то образом сохраняется, когда он переходит с одной страницы на другую. Вспомните, что HTTP не сохраняет состояний, поэтому только браузер или ваше приложение может «запомнить» то, что нужно запомнить.
Пункты для размышления
Постарайтесь ответить на предложенные вопросы. После выполнения задания попробуйте ответить на них ещё раз
Куки, Сессии и Флэши
С каждым новым запросом к серверу браузер отправляет все куки, и вы можете получить к ним доступ в своих котроллерах и представлениях (views) как к обычному хэшу. Вы также можете увидеть их срок действия, к примеру, используя такой синтаксис cookies[:name] = < value: "cookies YUM", expires: Time.now + 3600>.
Сессии
Чтобы идентифицировать сессию юзера, Rails хранит в браузере пользователя специальную безопасную и защищенную от изменений куку, которая содержит весь хэш сессии (поищите ее в инструментах разработчика в браузере, в разделе «Ресурсы»), и она перестает действовать, когда браузер закрывается. Когда бы пользователь ни сделал запрос к вашему приложению, этот запрос автоматически включает куку сессии (как и остальные куки), и вы можете использовать ее, чтобы отслеживать, залогинен ли пользователь. Это все может сейчас казаться абстрактным, но очень скоро вы увидите как это работает на практике.
Rails дает вам доступ к хэшу ‘сессии’ практически так же, как и к хэшу ‘куков’. Используйте переменную session в своих представлениях или контроллерах, вот так:
Зачем нужны и куки и сессии? Они похожи, но это не одно и то же. session это весь хэш, который хранится в безопасной куке сессии, который действует до момента закрытия браузера. Если вы посмотрите в инструментах разработчика, то срок действия («expiration») этой куки обозначен как «сессия». Каждое значение хэша cookies сохраненяется в отдельной куке.
Итак, куки и сессии это что-то вроде временных таблиц в базе данных, в которых вы можете хранить данные, уникальные для конкретного пользователя, и которые будут храниться пока вы их не удалите вручную, или пока не закончится их срок действия, или до окончания сессии (в зависимости от того, как вы это определите).
Несколько дополнительных замечаний к теме куки и сессии
4kb). Этого достаточно для любых «обычных» целей, однако не нужно пытаться заменить этим хранилищем базу данных.
Флэши
Если вы хотите показать сообщение «Спасибо за подписку!» в браузере пользователя, после того, как запустили экшен #create (которое обычно использует redirect_to для отправки пользователя на совершенно новую страницу в случае успеха), как вы отправите это сообщение об успешной подписке? Вы не можете использовать локальную переменную (instance variable), потому что редирект вынуждает браузер выдать совершенно новый HTTP запрос, и все переменные теряются.
Здесь вам на помощь приходит флэш! Используйте для сохранения flash[:success] (можете назвать как угодно) и эти данные будут доступны вашему представлению до следующего запроса. Как только представление откроет хэш, Rails сотрет данные, то есть они не будут показаны при переходе пользователя на новую страницу. Это очень ловко и удобно.
Фильтры контроллеров
Прежде, чем мы начнем говорить об аутентификации, необходимо расссмотреть фильтры контроллеров. Суть этих фильтров в том, чтобы запускать некий код в какой-то конкретный момент, к примеру до того, как отработает любой другой код. Это важно, потому что, к примеру если пользователь хочет запустить действие, на которое у него нет прав, вам нужно пресечь этот запрос на корню и вернуть соответствующую ошибку/редирект, до того, как пользователь совершит любое другое действие. Проще говоря, вы «отфильтровываете» неправомерные запросы.
Мы делаем это, используя фильтр «before», который принимает в качестве аргумента имя метода, который мы хотим запустить:
Лучше прятать фильтрующие методы в ‘private’, так чтобы они были доступны только из своего контроллера.
Аутентификация
Аутентификация Basic и Digest
Если вам нужен простой и небезопасный способ аутентификации, то можно использовать аутентификацию HTTP Basic. Мы не будем здесь рассматривать ее подробно, но в общем она подразумевает ввод имени пользователя и пароля в простую форму и отправку их (в незашифрованном виде) через сеть. Для этого используется метод #http_basic_authenticate_with (примеры смотрите в разделе дополнительные ресурсы), и этот же метод ограничивает доступ к определенным контроллерам для неаутентифицированных пользователей.
Проблема с этими способами заключается в том, что имена и пароли в явном виде находятся в контроллере (или где-то еще), так что это можно использовать только как временное решение.
Создаем свою аутентификацию
Если вы хотите, чтобы пользователи могли залогиниться на сайте, придется выполнить еще несколько действий. Мы не будет расписывать их подробно, потому что вы сможете все это проделать на практике. Однако некоторые принципы знать полезно. То, о чем мы будем говорить дальше, может показаться немного непонятным и отвлеченным от реальных примеров, однако это на самом деле всего лишь краткое описание тех штук, которые вы скоро будете внедрять в своем проекте.
Во-первых, мы не храним пароли в базе данных в виде текста. Делая так, мы просто напрашиваемся на неприятности (спорим, вы тоже читали новости о взломанных сайтах и утекших паролях?). Вместо этого, мы храним зашифрованную версию пароля («password digest»).
Когда пользователь вводит свой пароль в форму входа, вместо того, чтобы сравнить ее с текстом пароля напрямую, вы шифруете пароль. Затем вы сравниваете хэшированную версию пароля с хешированным паролем, хранящимся в базе. Если они совпадают, у вас появляется залогиненный пользователь.
Если ваш пользователь хочет, что его «запомнили» (вы, наверное, тысячу раз видели чекбокс «запомнить меня» в форме входа на сайт), вам нужен способ запомнить его на более долгое время, чем длится сессия браузера. Чтобы это сделать, вам нужно будет создать еще один столбец в таблице Users, где будет храниться зашифрованный remember_token (вообще вы можете назвать его как угодно). Вы будете использовать его, чтобы сохранить рандомную строку для этого пользователя, которая будет в дальнейшем использована для его идентификации.
Вы будете отдавать незашифрованный токен в браузер пользователя в качестве постоянной куки (используя cookies.permanent[:remember_token] ). Эта кука будет отправляться с каждым новым запросом, так что вы сможете сверить ее с зашифрованным образцом в базе данных, чтобы проверить, кем является пользователь, когда он сделает запрос. Это более явная и длительная версия того, что Rails делает с сессиями. Принято делать сброс токена каждый раз, когда пользователь выходит с сайта и логинится заново.
Обычно полезно иметь несколько методов-хелперов для решения обычных задач: залогинить пользователя, проверить, залогинен ли он, или сравнить залогиненного пользователя с другим пользователем (это пригождается, когда текущий пользователь смотрит страницу другого пользователя, и не должен видеть ссылки на «редактирование»). Эти штуки сделают вашу жизнь легче, потому что вы сможете повторно использовать их в фильтрах контроллерах, вьюхах или даже в своих тестах.
Общее пошаговое описание:
Devise
Несмотря на это, в итоге вы будете использовать его в большинстве своих проектов, после того как освоите самостоятельно создание аутентификации. Использовать Devise несравнимо лучше, чем строить аутентификацию своими руками, потому что он решает множество проблем и закрывает потенциальные лазейки в безопасности, о которых вы даже бы и не подумали. Devise позволяет вам взаимодействовать с более продвинутыми системами аутентификации при работе с API, такими как OAuth. Поэтому, чуть позже он будет очень для вас полезен.
Вкратце, Devise предоставляет вам набор форм для регистрации и входа на сайт, а также методы для их внедрения. Он состоит из 10 модулей (и вы можете выбрать, какие именно будете использовать). Вы устанавливаете гем ‘devise’ и запускаете установщик, чтобы перенести файлы в свое приложение. Вам также нужно будет запустить миграцию базы данных, чтобы добавить дополнительные поля в свою таблицу Users.
Конфигурация будет зависеть от ваших предпочтений. Хотите ли вы, чтобы пользователи подтверждали регистрацию по e-mail (модуль Confirmable )? Хотите ли позволить пользователю сбросить пароль (модуль Recoverable )?
Изучение гема Devise выходит за рамки этого урока, но вы совершенно точно будете использовать его к концу курса. Просто читайте документацию. Документация Devise впечатляет, она доступна на Github. Мы приводим ссылку, чтобы вы взглянули на нее, почитали, и сохранили где-то в подкорке до той поры, когда начнете использовать этот гем.
Ваши задания
Заключение
Дополнительные ресурсы
Этот раздел содержит полезные ссылки на дополнительные материалы. Это не обязательно, так что расценивайте их как нечто полезное, если вы хотите поглубже погрузиться в тему