Могу ли я реализовать систему аутентификации веб-пользователей на Python без POST?

Вы можете использовать HTTP-аутентификацию, если она поддерживается.

Вам нужно будет добавить SSL, так как все методы, POST, GET и HTTP Auth (ну, кроме аутентификации Digest HHTP) отправляют открытый текст.

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

Что касается примеров, что вы используете? В Python есть много вариантов, например, модуль cgi или какой-либо фреймворк, например Django, CherryPy и т. д.

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

В некоторых смыслах нет реальной разницы в безопасности между запросами GET и POST, поскольку они оба передаются в виде открытого текста, в других смыслах и на практике ... GET намного легче перехватить, и он находится во всех журналах большинства людей и ваших история веб-браузера. :)

(Или, как было предложено другими плакатами, используйте совершенно другой метод, например HTTP-аутентификацию, дайджест-аутентификацию или какую-либо схему аутентификации более высокого уровня, такую ​​как AD, LDAP, kerberos или shib. Однако я вроде бы предположил, что если бы у вас не было POST, вы бы не их тоже нет.)

С помощью небольшого количества JavaScript вы можете получить у клиента хэширование введенного пароля и генерируемого сервером одноразового номера и использовать его в HTTP GET.

Безопасный вход в систему очень субъективен. Полный «безопасность» не так легко достичь (если это вообще возможно ... спорно). Однако вы можете приблизиться.

Если POST не подходит, возможно, вы можете использовать метод безопасности каталога, такой как .htaccess или проверка подлинности Windows, в зависимости от того, в какой системе вы находитесь.

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

Чтобы использовать POST в качестве метода отправки учетных данных для входа, вам нужно просто использовать HTML-форму с методом = "post" и получать информацию, скажем, со страницы PHP или ASP, используя метод $ _POST ['varname']. в PHP или метод request.form ("varname") в ASP. Например, на странице PHP или ASP вы можете выполнить поиск в базе данных пользователей, чтобы узнать, существует ли эта комбинация имени пользователя и пароля, и, если да, перенаправить их на соответствующую страницу.

В качестве справки используйте http://www.w3schools.com/ASP/showasp.asp?filename=demo_simpleform для части HTML / ASP.

Хороший выбор: HTTP-дайджест-аутентификация

Сложнее снять хорошо, но вариант: Хеширование на стороне клиента с помощью Javascript

Javascript - лучший вариант в этом случае.

Вместе с запросом имени пользователя и пароля он отправляет уникальную случайную строку. Затем вы можете использовать библиотеку javascript md5 для генерации хешированного пароля, комбинируя случайную строку и пароль [pwhash = md5 (randomstring + password)]. Затем javascript создает экземпляр вызова http: //SERVER/login.cgi? username = TheUsername & random = RANDOMSTRING & pwhash = 0123456789abcdef0123456789abcdef

Затем сервер должен сделать две вещи: Проверьте, использовалась ли ранее случайная строка, и, если она есть, отклоните запрос. (очень важно для безопасности)

Найдите пароль в виде открытого текста для имени пользователя и выполните md5 (случайная строка + пароль). Если это соответствует тому, что пользователь указал в URL-адресе как pwhash, значит, вы знаете, что это пользователь.

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

Я также рекомендую помещать «Pragma: no-cache» и «Cache-Control: no-cache» в верхней части заголовков, возвращаемых сценарием CGI, просто чтобы аутентифицированный сеанс не сохранялся в веб-кеше браузера или вашего интернет-провайдера. .

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