Вход в систему: фоновые детали

Это полностью зависит от реализации веб-сайта. Даже использование cookie не обязательно, но очень распространено.

В большинстве случаев однако что-то вроде этого происходит:

• Вы отправляете в своем имени пользователя и пароле с помощью HTML-формы.
• Сервер ищет соответствующего пользователя (использующий базу данных)
• Сервер проверяет, соответствует ли пароль паролю, который хранится в базе данных вместе с пользователем.
• Если пароль будет правильным, то сервер сохранит, какой пользователь в настоящее время активен на сессии. Идентификатор этой сессии хранится в cookie, фактические данные этой сессии (текущий пользователь) хранятся на сервере под этим идентификатором.

Теперь Вы зарегистрированы. Вы останетесь, вошел в систему во время оставшейся части сессии:

• Когда Вы запросите другую страницу с сервера, Вы отправите cookie с идентификатором сессии.
• Сервер загружает сессию с помощью этого идентификатора. На этой сессии хранится текущий пользователь, таким образом, сервер знает, какой пользователь зарегистрирован.

Это - довольно общий вопрос. То, что Вы делаете по всем, устанавливает некоторые учетные данные с самим сайтом. Если мы берем простую версию, Вы вводите имя пользователя и пароль; это означает, что Вы идентифицируете себя к веб-сайту и затем показываете ему секрет Вы и доля веб-сайта, что никто больше не знает (мы надеемся). Это устанавливает Вас как подлинно человек с тем именем пользователя, и таким образом, мы говорим, что Вы аутентифицировали себя.

После того как Вы сделали так, существуют некоторые проектные решения, которые должен сделать дизайнер сайта. большинство людей не хочет входить в систему для каждой страницы, таким образом, веб-сайт хочет хранить немного информации, учетные данные, на Вашем конце. Это означает, что может сказать, что это - все еще Вы. Часто, как Вы говорите, это - "cookie", который является ничем больше, которое крошечный текстовый файл назвал с URL веб-сайта. Этот файл хранится браузером.

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

Под покрытиями при установлении безопасного соединения веб-сайт отправляет браузеру блок отформатированных данных, названных x509 сертификатом. Это - другая форма аутентификации; сертификат будет подписан выпускающим (центр сертификации или "CA"), и браузер может использовать хранившие данные о CA, чтобы гарантировать, что сертификат подлинен.

Очень просто объясненный, то, что происходит, упоминается ниже:

Что входит?

• Имя пользователя
• Пароль

Что происходит внутри?

1. Пароль преобразовывается в свой хеш
2. Хеш (пароль) по сравнению с Таблицей базы данных или Службой каталогов (если кто-то не будет вниз справедливо глуп, сайт не сохранит Ваш пароль в открытом тексте),
3. Если Аутентифицируется, маркер состояния хранится на Сессии и/или cookie.
   • Этот маркер может просто содержать состояние, Метки времени Входа в систему, Ваш идентификатор пользователя, userType (если таковые имеются), и др.
   • Этот маркер читается и проверяется на каждой странице, к которой Вы получаете доступ, если та страница требует, чтобы Вы были зарегистрированы с как определенный тип пользователя.
4. Если аутентификация перестала работать, Вы перенаправляетесь к странице, отображающей ошибку, прося, чтобы Вы повторно вошли в систему.

Что выходит

1. Вы перенаправляетесь Ваша персональная страница страницы / профиля, к которой Вы получали доступ, к которому проверяет Вас с помощью маркера.
2. Кроме того, Цифровой сертификат может появиться в изображение при доступе к банковскому сайту или другому критически безопасному сайту

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

Помните, что сам HTTP является протоколом без сохранения информации о состоянии. Стандарт HTTP не содержит метода для Запросов HTTP, чтобы сохранить или сохранить любое состояние между отдельными Запросами HTTP. Таким образом состояние обычно сохраняется полностью на сервере, и Вам просто нужен метод для клиента для идентификации, какой сессии текущий Запрос HTTP принадлежит.

Этими двумя распространенными способами это сделано:

• Используйте cookie (например, Tomcat Apache использует JSESSIONID cookie) для хранения некоторого хешированного аутентификационного маркера, который будет успешно искать веб-сессию, или
• перепишите URL так, чтобы каждому запросу добавили идентификатор сессии в конец запроса. Все еще с помощью Tomcat Apache в качестве примера, если куки отключены затем, URL будет переписан для окончания строкой как";jsessionid=....". Таким образом, каждый запрос, каждый HTTP ДОБИРАЕТСЯ, и POST (и остальные) закончится этой строкой.

Таким образом по каждому запросу клиент делает, идентификатор сессии предоставляется веб-серверу, позволяя сохраненное состояние для этого клиента быстро искаться, позволяя HTTP действовать как протокол состояний.

Какая информация отправляется на сервер, когда Вы входите в систему? Безотносительно информации Вы обеспечили на форме входа в систему. Некоторые веб-серверы также отслеживают адрес TCP/IP, из которого прибыл запрос избежать нападений перехвата сеанса. Это обычно - вся информация, которая необходима серверу.

Если Вы не позволяете Вашему браузеру сохранять cookie, то необходимо будет войти в систему веб-сервера каждый раз, когда Вы открываете свой браузер и первоначально открываете веб-страницу сервера. Однако, если Вы позволяете Вашему браузеру сохранять cookie, затем много серверов позволяют Вам опцию сохранения cookie (то есть, не просто с помощью сеансовых куки) так, чтобы каждый раз Вы перешли к веб-странице сервера, сохраненный cookie идентифицирует Вас так, Вы не должны повторно входить в систему. Здесь, cookie сохранит достаточно информации - часто в зашифрованном виде, который только сервер может понять - для идентификации Вас. В этом случае Cookie не является простым идентификатором сессии.

Существует два основных способа выполнить аутентификацию в сети и несколько менее популярных путей, о которых также стоит знать.

Первой является Аутентификация HTTP, как определено RFC 2617. Когда Вы запрашиваете защищенную страницу, сервер отвечает a 401 код состояния, сигнализируя, что Нельзя получить доступ к ресурсу. В дополнение к этому это также отправляет a WWW-Authenticate заголовок, который сообщает браузеру о том, как он хочет, чтобы Вы авторизовали себя. Браузер видит этот код состояния и заголовок, и предлагает Вам Ваши детали аутентификации. При вводе их браузер готовит их согласно определенной схеме аутентификации сервер, указанный, и запрашивает страницу снова, включая Authorization заголовок с подготовленными деталями. Сервер проверяет эти детали по своей пользовательской базе данных, и любой отвечает другим 401 (неправильные детали), или защищенная страница с сопровождением 200 код состояния для указания на успех.

Аутентификация HTTP является одной из тех древних опций, которые браузеры не реализовали хорошо для начала и действительно никогда не улучшались. Из-за этого это стало намного более популярным для веб-разработчиков для реализации аутентификации самих с помощью cookie для сохранения состояния. В этом случае пользователю дарят стандартную HTML-форму. Когда пользователь вводит их учетные данные в поля и отправляет форму, браузер кодирует его и отправляет его на сервер таким же образом, это кодирует любую нормальную HTML-форму. Сервер проверяет учетные данные, и если они законны, устанавливает cookie со случайным образом сгенерированным Идентификационным номером, наряду с соответствующей записью базы данных/файловой системы, которая распознает что Идентификационный номер как принадлежащий конкретному пользователю.

С этого момента каждый запрос, который браузер выполняет к серверу, включает этот cookie Идентификационного номера как HTTP-заголовок. Сервер распознает cookie, ищет Идентификационный номер и знает, какой пользователь Вы. Когда Вы принимаете решение выйти из системы, сервер отправляет ответ, прося, чтобы Ваш браузер забыл Идентификационный номер, в которой точке Вы - просто другой анонимный пользователь.

Менее наиболее часто используемая опция является использованием клиентских сертификатов SSL. Многие люди знакомы с идеей использовать SSL для идентификации сервера. Криптографическая пара ключей сгенерирована, подписывается доверяемыми полномочиями и используется, чтобы доказать, что отправляемые данные произошли с владельцем пары ключей. О чем не знают многие люди, хотя, то, что то же может использоваться клиентом для удостоверения его личности к серверу. Это менее удобно, однако, поскольку необходимо носить сертификат с собой, если Вы хотите использовать его больше чем на одной машине.

Существуют изменения и менее известные опции, доступные, конечно, но это самые видные.

Как другие упомянули, процедуры входа в систему варьируются в зависимости от реализации, но основной случай (простая аутентификация веб-приложения) использует что-то как следующий псевдокод:

function login(username, password) {
    user = db->get_user(username)

    if (user == false) {
        report_error("Unknown username")
        exit
    }

    if (user->password != hash(password)) {
        report_error("Incorrect password")
        exit
    }

    // User authenticated, set session cookie
    session->set_data('current_user', user->username)
}

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

function login(username, password, remember_me) {
    user = db->get_user(username)

    if (user == false) {
        report_error("Unknown username")
        exit
    }

    if (user->password != hash(password)) {
        report_error("Incorrect password")
        exit
    }

    // User authenticated, set session cookie
    session->set_data('current_user', user->username)

    if (remember_me == true) {
        cookie_token = random_string(50)
        set_cookie('autologin_cookie', cookie_token, ONE_MONTH)
        // Finally, save a hash of the random token in the user table
        db->update_user(user, 'autologin_token', hash(cookie_token))
    }
}

Плюс функция для выполнения автоматического входа в систему, если существует существующий cookie:

function cookie_login() {
    cookie = get_cookie('autologin_cookie')

    if (cookie == false) {
        return false
    }

    // Only for demonstration; cookie should always include username as well
    user = db->get_user_by_cookie(cookie)

    if (user == false) {
        // Corrupt cookie data or deleted user
        return false
    }

    // User authenticated, set session cookie
    session->set_data('current_user', user->username)
    return true
}

Примечание: Вышеупомянутое не является подходом 'лучших практик', и это не очень безопасно. В производственном коде Вы всегда включали бы идентификатор пользователя в cookie-данные, использовать несколько уровней регулировки, хранить данные на неудавшихся и успешных логинах, и т.д. Все это было снято для создания базовой структуры из аутентификации простой следовать.

Так или иначе я надеюсь, что это - то, что Вы искали, koldfyre. Я не знаю Ваше образование, но если Вы не уверены в том, как сессии и работа cookie, необходимо читать на них отдельно, и если Вы нуждаетесь в более тщательно продуманных деталях, просто спрашиваете.

P.S.: можно также хотеть проверить вопрос "Полное руководство К Аутентификации Веб-сайта" для подходов лучшей практики

Посмотрите, немного трудно дать Вам намного больше информации, которую Вы уже имеете здесь; я не уверен, почему Вы хотите установить щедрость на нем. Cookie является просто определенной именованной информацией, и можно поместить что-либо, что Вы любите в нем. Для сессии Вы хотели бы некоторый идентификатор сессии. Существуют конвенции для этого, или можно сделать это сами. Независимо от того, что Вы делаете при установке cookie Вы оставляете немного лжи данных на браузере человека, который более или менее похож на это:

mydomain.com:
    mystuff: this is my stuff, by golly.

Когда Вы возвращаетесь, Вы получаете cookie и возвращаете это.

Если Вы хотите видеть все подробности того протокола, взглянуть на статью Wikipedia.