| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Perl: разработка для Web > Авторизация и сессия |
| Автор: Мартын Яуза 5.5.2003, 18:56 |
| Проблема такая. Надо что бы админы. Т.е. те кому я дам пароли(каждому свой) заходили в админ-зону. Я скачал скрипт постинга новостей и изучил его, с целью получить ответ, как лучше сделать систему авторизации. Тут встретились следующие проблемы. Там правда был только один пасс. как бы для одного админа, но это не важно. Короче, если пасс верный происходит следующее : open (AUTH, ">Data/auth.pl"); print AUTH '$auth = 1;'; print AUTH "1;"; close AUTH; Создается файл и туда пишется $auth=1; А потом зачем то еще одна единица. Вопрос: Зачем еще одна единица? И во время сессии этот файл остается неизменным, а лишь перед каждым действием проверяется, что $auth=1. Но раз так, то любой посторонний во время сессии админа, когда файл auth существует, может подать запрос примерно такой: act=admin&code=show Программа проверяет auth.pl, возвращается истина и посторонний получает доступ к центру администрации. Не лучше ли во время сессии просто держать переменную авторизации в самой программе? В том скрипте, когда нажимаем кнопку ВЫХОД из центра администрации, то файл auth.pl удаляется, соответственно переменные авторизации очищаются. Но что если кто то не нажмет на кнопку ВЫХОД, а просто закроет браузер? Переменные остаются и любой желающий спокойно получает доступ к администрации. По этому у меня следующие вопросы: 1) Как лучше вести сессию? Держать ли переменную авторизации во время сессии в программе или же как то еще? 2) Как лучше осуществить выход из сессии? Помоему если держать переменную в программе, то всё будет как надо. Если есть кое что по лучше напишите. |
| Автор: HalkaR 5.5.2003, 21:09 |
| Лично я, коли надо делать чтолибо подобное делаю самое простое и дурацкое, что возможно в скрипте делаю скрытую форму в которую заносится введенный при авторизации пароль и предаю их как параметр и каждый раз проверяю. |
| Автор: acp 5.5.2003, 21:17 | ||
Кхе-кхе... Мда...  Самое лучшее: 1. URL rewriting. Это когда к ссылкам прибавляется уникальный сгенерированный идентификатор сессии. 2. Cookies. Идентификатор хранится там. В обоих случаях нужны идентификаторы. Их можно хранить на сервере либо в виде файлов, либо в БД. И будет существовать парсер, который будет при вызове какого-либо скрипта проверять, существуют ли устаревшие идентификаторы. |
| Автор: Мартын 6.5.2003, 09:29 |
| Что за идентификаторы? я новичок просто. Можно по подробнее? |
| Автор: acp 6.5.2003, 11:13 | ||
Ну, для каждого пользователя, при авторизации, т.е. когда он вводит логин/пароль скрипт генерирует некий уникальный идентификатор и передаёт его пользователю указанными выше способами. А идентификатор, что-то типа
Конечно, такой способ не идеален, т.к. может зациклиться надолго. |
| Автор: Unregistered 6.5.2003, 12:47 |
| Проще- воспользоваться стандартным средством apacha - .htaccess. Куки хранятся на стороне клиента - их легко подделать. Через "скрытые формочки" передавать данные заморочно, т.к. все переходы придется организовывать через кнопку Submit Есть вариант такой. После успешной регистрации - генерится некое загадочное число (цифр 12), чей состав подчинен опред.правилам. И это число подставляешь во все ссылки генерированной страницы (print "<a href=newpage.pl?uid=$number>..</a>) И при запуске каждого скрипта проверяеш валидность переданной переменной "uid". |
| Автор: acp 6.5.2003, 14:08 |
| А это "некоторое загадочное число", разве не идентификатор сессии? :-) |
| Автор: Мартын 6.5.2003, 18:29 |
| На сколько я понял всё выглядит так: Сессия начинается с выдачи сгенерированного идентификатора. Он добавляется в каждую ссылку. Но как проверить, что именно ЭТОТ идентификатор - то что надо? Может создать файл, куда сунется тот самый идентификатор. И при запросе он будет сверяться с тем, что пытается послать юзер из своего браузера. Если они идентичны - то всё ОК. НО если файл был создан более 5 минут назад, то надо пройти авторизацию заново. Такой вариант сойдет за безопасный? |
| Автор: acp 6.5.2003, 18:40 | ||
Если к этим файлам нет доступа из сети, если этот уникальный идентификатор сессии достаточно длинный (!) и рандомный, то да. |
| Автор: Мартын 7.5.2003, 11:44 |
| В таком случае какие права доступа лучше всего поставить на этот пятиминутный файл? |
| Автор: Guest_test 7.5.2003, 12:38 |
| Данные о разрешенных пользователях должны хранится или в БД или в файле находящемся за пределами http-зоны (т.е. чтобы нельзя было его прочитать из броузера) Права на чтение для apache (или nobody) cgi Скрипт берет введенные в формочку login/password - сверяет с этим файлом, и если OK - генерит идентификатор который добавляет ко всем ссылкам. При загрузке ссылки проверяет наличие корректного идентификатора. идентификатор: Придумываешь некое число, напр. 5057. Далее придумываешь правила его зашифровки: Напр. над переданном идентификотором (123456732569) производятся следующие действия - берется 2 цифра складывается с 8-й, а 3-я * 9-ю полученные результаты объединяешь -добавляешь еще что-нибудь - и получаешь 5057. Значит усе корректно. |
| Автор: Мартын 7.5.2003, 23:22 |
| Но тогда идентификатор всегда один и тот же. И если он будет в каждой ссылке, то соответственно и в кукисах. А если кукисы каким то загадочным образом попадут на чужой комп... |
| Автор: secandr 27.6.2003, 22:52 |
| Можно сделать следующее: сессию выдовать при входе, например - время с начала эпохи. Я ещё вычитал асц коды букв логина, рандом,.... $ses=time; Затем переменная сессии записывается в файл в виде: 12345~45678~436657 Потом читаешь этот файл в $str @uin=split(/~/,$str); foreach $t(@uin) { проверка на устаревание идентификатора, из не устаревших генирируешь @out проверка на совпадение. } Сохраняешь в файл @out в файл. В более сложном варианте в файле можно хранить имя-номер_сессии-время_последнего_обращения. |
| Автор: NightGoblin 7.7.2003, 07:09 | ||
| Хм... Можно сделать логины и пароли, если админов много. Но если речь идет о чем-нибудь достаточно простом, типа администрирования небольшого сайта, просто сделать файл вне каталога с публичными документами (права хоть 0666), в который будут писаться строчки типа: n7GwoMfbzRH06Ce:1057550523 где до двоеточия располагается ключ, предоставляющий права админа, а после - время окончания действия в формате UNIX (в Perl текущее время в этом формате получается с помощью функции time() ). Каждый раз, если в GET или POST запросе присутствует id=(что-то), то читается файл, ключи проверяются на устарение, устаревшие удаляются, данный id сравнивается со всеми ключами, и, если совпадает, клиенту предоставляется доступ, а время окончания действия обновляется по принципу текущее время плюс некое время t, за которое админ должен произвести следующий запрос. Да, а если нужны отдельные аккаунты для каждого админа, то создается просто еще один файл там же, в котором все это хранится, а в файле с текущими ключами к каждой строчке добавляется еще одна часть с логином админа. Можно, конечно, включить в дело SQL, но стоит ли оно того?... ЗЫ: А функция для генерации ключей может быть, например, такой:
Хотя, конечно, можно было бы сделать и оптимальнее, но это всего лишь один из вариантов |