LINUX.ORG.RU

perl session


0

0

HI ALL .

есть форма login/pass вызывающяя скрипт который проверяет login/pass и если все ок создает сессию CGI::Session . теперь есть несколько других скриптов в которых надо сделать проверку что их запускает именно авторизованый пользователь , как правильнее передавать / проверять информацию о сессии/cookie в этих скриптах ?

★★

Re: perl session

Мля пол часа писал потов все случайно прибил !!!

Так:

1) После авторизации сделай какойто ses_id. 2) Запоомни его гдето (БД,file) (можно додуматся до алгоритма с использыванием времени тогда запоминать не нужно) но так имхо не надежно.

3) Зашифруй это чемто 4) передавай со всеми кликами этот шифрованый ses_id

Перед тем как дать страницу делай decrypt($ses_id) И проверяй стоит ли эту страницу давать

paranormal ★★
()

Re: perl session

сделал так :

есть скрипт login.cgi который проверяет user/pass и если все ок , то создает сессию в /tmp/cgisess_..... и затем делает redirect на другой cgi скрипт при этом передавая в querry_string CGISESSID 


в далбнейшем я проверяю совпдает ли CGISESSID из querry_string с файлом сессии в /tmp/ 

my $sid = $q->param('sid');

if (!-e '/tmp/cgisess_' . "$sid") {
        print $q->header();
        print "NAHUI\n";
        exit(0);
}

сойдет ли такая проверка ? какие минусы есть у нее ? 

j262 ★★
() автор топика
Ответ на: Re: perl session от j262

Re: perl session



print "NAHUI\n";

Мы с тобой случайно не в одной канторе работаем ???

Может ты через стену сидишь, Дим а если клиент увидит ?
Прикалываюсь. :-)

Минус: пользователь однажды залогинившись останется залогиненым навечно.

Минус: не отдавай sesid в открытом виде (теоретически юзер может его увидеть и догфадаться как этот ses_id сформировался.

paranormal ★★
()
Ответ на: Re: perl session от paranormal

Re: perl session

> 3) Зашифруй это чемто > 4) передавай со всеми кликами этот шифрованый ses_id > Перед тем как дать страницу делай decrypt($ses_id)

Вы индийские визири, любители велоспорта, штоле?

Идентификатор сессии не шифруется, это обычное большое случайное значение и весь механизм "классических" HTTP-сессий работает на том, что в сроки жизни сессии ее идентификатор сложно подобрать. И этим CGI::Session и занимается.

Простая схема, просто проверяющая залогинен или нет: throw NotAuthorizedException unless $session->param('logged_in'); на нужных страницах. Ну и ставить logged_in в сессии при входе и убирать при выходе.

Схема, когда на страницах разные права:

* При авторизации: $session->param('username', $username);

* При проверке: throw NotAuthorizedException unless check_permissions('some_permission', $session->param('username');. Ну и реализовать sub check_permissions($$) { my ($what, $who) = @_; ... }

* При выходе: $session->clear('username');

Это все при условии что все скрипты на Perl и могут пользоваться CGI::Session. Если же скрипты разные и во всех их CGI::Session не применим - можно сделать внутренний сервис авторизации. Т.е. пусть некий скрипт A это Perl'овый скрипт с CGI::Session и там пользователь, в частности, логинится. А некоторый скрипт B - вообще на Python, но ему надо знать об авторизации в A. Тогда B берет переданный session ID, делает внутренний запрос к A и спрашивает - свой это или нет. A отвечает, B создает свою сессию (чтобы не пинать A каждый раз) и все довольны. Ну и при логауте в A тот делает внутренний запрос к B и просит его убить свою сессию.

Если скрипты, например, на разных машинах и ломиться к A с вопросами "свой-чужой" нежелательно используйте подписи. Тогда A и B должны иметь некий общий секрет (строку случайных символов), и A при переходе к B должен передавать в параметрах подписанное значение. Т.е.:

my $data = join ':', $username, time, $something_else_worth_sending; $data = $data . ':' . hmac_sha1_hex($data, $secret_key);

B берет начало переданной ему строки, выполняет такую же операцию (hmac_sha1_hex($data, $secret_key)) и проверяет совпадают ли подписи. Если да - данным можно верить (если не случится что хитрые китайцы переработают много метана, получат много матана и поломают SHA1, конечно), если нет - die "На йух, в жаркие страны."; Ну а считая что часы на серверах синхронизированы и проверяя время в переданном сообщении мы можем и защититься и от replay-атак, когда кто-то узнает (скажем, из кэша браузера) старый токен авторизации, когда-то выданный A, и идет с ним к B.

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

Ну или если B много и разных, то тогда уже идет курение в сторону криптографии с открытым ключом, с собственным Certificate Authority, блэкджеком и шлюхами.

ЗЫ. Хэширование != Шифрование.

anonymous
()
Ответ на: Re: perl session от anonymous

Re: perl session

tnx . я уже разобрался , все описано в man CGI::Session 
анализирую querry_string и проверяю expired сессия или нет 
вначале только что-то затупил ....

j262 ★★
() автор топика

Re: perl session

Не проще ли в cookies сохранять ses_id, и на основе этого пускать. Также сделать таймаут куки на мин 15.

iron ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.