Forum Webscript.Ru
Программирование => Perl => Тема начата: bik от 01 Декабря 2001, 00:48:11
-
сабж
-
Если ты имееш в виду сессии в ПХП, то посмотри здесь
http://www.php.net/manual/en/ref.session.php
Если же тебе интересно что такое сессии вообще, то мне лень обьяснять.
-
сабж
-
А в чем проблема?
сабж
интересно,как это они могут заменить кукисы?(как-то на Форуме читал)
-
А они не заменяют. Куки дополняют "джентельменский набор" сессии. То есть сеанс проверяется сразу по нескольким параметрам, в том числе и куки...
-
А мне кажется, что таки могут заменить куки :)
Куки - они для хранения переменных какихто (изначально),
но никто не запрещает эти переменные и на сервере хранить. Тем
более если они нужны только на одну сессию (есть такие).
Так для этого случая можно следить за человеком, передавая
Session-Id через http://host//dir/page.html например
и из этого числа уже строить запросы и узнавать все нужные
переменные.
Т.е если user отключит куки, то это одно из решений
-
А мне кажется, что таки могут заменить куки
Это физически невозможно. Дайте определение слову "сессия"!
Итак, сессия - это .....
-
Имхо - это время начаавшееся с захода посетителя на сайт и закончившееся его уходом, включающее в себя все его ходилки бродилки по сайту, в том числе какие то авторизации на нужных страницах и т.д. и т.п. Короче всё что делал посетить на сайте в этот промежуток времени каким то образом фиксируется сервером. В зависимости от изменчивости шагов юзверя меняется и сессионная запись...
-
И по какому принципу отслеживается пользователь (вернее броузер пользователя)?
-
В зависимости от изменчивости шагов юзверя меняется и сессионная запись...
Все не так просто, как кажется...
Сессия это несколько сеансов которые производятся в ограниченный промежуток времени, на протяжении которого юзверь взаимодействует с сервером. А куки, в данном случае помогают получать вторичную информацию о клиенте.
Хотя в некоторых задачах можно и опустить эту возможность...
-
Хотя в некоторых задачах можно и опустить эту возможность...
Например... ?
-
NeoNox, а по -моему мы об одном и том же только с разных точек зрения ;-Р :)
Лично НАСУ - СПАСИБО! :)))))
-
мы об одном и том же только с разных точек зрения
Только вот человеку доходчиво не ответили. Я тут вас растрясяю на ответы, а вы игнорируете. По идее если знаете хорошую статейку, то отошлите туда. Не знаете отвечайте на вопросы, типа "как? почему? зачем?..."
-
Только вот человеку доходчиво не ответили.
Так вопрос был:интересно,как это они могут заменить кукисы?(
И ответ был получен.
По идее если знаете хорошую статейку, то отошлите туда.
У меня печатное издание и на английском.
Аааа нашел еще... Брошюрка "MySQL и Perl". Сейчас отсканю и выложу.
-
Так вопрос был:
Вопрос был: "Что такое сессии".
И, судя по всему, не только имелось ввиду взаимодействие с базами... Вот.
-
ОфициЯльные ответы:
Сессия (session) - просмотр пользователем группы страниц сайта. Сессия считается завершенной, если от пользователя не было обращений в течение 15 минут.
Сессии - это механизм, который позволит вам создавать и использовать переменные, сохраняющие свое значение в течение всего времени работы пользователя с вашим сайтом. При этом у каждого пользователя вашего сайта эти переменные будут собственными, т.е. их область видимости (variable scope) распространяется на все время нахождения на сайте конкретного пользователя, причем для каждого захода пользователя на ваш сайт эти переменные будут различными. Говоря проще, эти переменные принадлежат конкретной сессии работы конкретного пользователя с вашим сайтом (отсюда и название механизма - сессии).
А вообще - вот тут есть http://www.providers.ru/articles/php/sessions.html
Может сгодится...
lodevar прости меня за излишний флейм :)
-
Так есть ли ресурс где можно прочитать про сессии на Перле?
Очень необходимо!
Заранее спасибо.
-
Вот видите. Народ интересуется не столько призрачными теоритическими сведениями, а конкретной программной реализацией.
-
Сеансы работы пользователей
Протокол НТТР изначально проектировался без поддержки механизма информации о состоянии сеансов работы пользователя. Индивидуальные запросы не связаны друг с другом, и НТТР-сервер не располагает средствами распознавания конечных пользователей между сеансами. Поэтому требуется определить способ идентификации пользователя, связать данные предыдущих и текущего сеансов работы пользователя.
ВНИМАНИЕ
Под сеансом понимается запрос пользователем одного документа с НТТР-сервера.
Существуют несколько способов организации сеансов, все они построены на наличии одной или нескольких переменных, которые ассоциируются с конкретным пользователем и устанавливают соответствие при каждом сеансе.
Данные сеанса могут храниться кик на стороне пользователя, так и на стороне сервера, в каждом методе хранения есть свои достоинства и недостатки.
ПРИМЕЧАНИЕ
При проектировании управляющего приложения для Интернет-каталога использовалась методика хранения информации на стороне клиента, при этом для сохранения конфиденциальности передаваемой информации и данных авторизации использовался защищенный протокол передачи данных 551.
В случае хранения данных на стороне пользователя всю необходимую информацию программа получает из строки запроса, предварительно подготовив сеансовые данные в предыдущем сеансе. Этот вариант плохо применим, если требуется использовать большое количество сеансовых переменных или необходимо обеспечить уровень безопасности без применения специальных мер. Положительной стороной этого метода является простота использования при минимальном числе используемых перемениых.
Хранение данных на стороне пользователя требует постоянных проверок на допустимость и соответствие данных, так как сеансовые переменные могут быть произвольно изменены пользователем.
ВНИМАНИЕ
Хранение сеансовых переменных на стороне сервера позволяет использовать все необходимые настройки с использованием сеансовых переменных, уникальных
для каждого пользователя. Однако для хранения пользовательской информации на стороне сервера необходима база данных. Это может быть и реляционная база данных, например МуSQL и обычный текстовый файл, в любом случае настройки пользователя или другая специфическая информация должны надежно сохраняться на сервере между сеансами пользователя.
ПРИМЕЧАНИЕ Возможности реляционной базы данных позволяют проводить намного более сложные манипуляции с данными, чем в текстовых базах данных.
Вместо хранения всей информации на стороне пользователя используется идентификатор сеанса, индивидуальный для каждого пользователя, с помощью которого данные из базы данных ассоциируются с конкретным пользователем во время каждого сеанса.
Как уже отмечалось выше, в НТТР отсутствуют стандартные механизмы идентификации пользователя, единственным постоянным элементом па протяжении сессии остается 1Р-адрес удаленного пользователя.
ВНИМАНИЕ
Сессия состоит из нескольких сеансов, производимых в ограниченный промежуток времени, на протяжении которых пользователь взаимодействует с сервером.
Но IР-адрес не является уникальным для каждого пользователя. Например в случае, когда используются прокси-серверы, IР-адрес пользователя будет определяться как адрес прокси-сервера. Если в одно и то же время на сервере, идентифицирующем пользователей по IР-адресу, будут находиться несколько пользователей, использующих один и тот же прокси-сервер, то такие пользователи будут идентифицироватся как один, поскольку имеют одинаковый IР-адрес.
Для того чтобы разделить пользователей, использующих один и тот же IР-адрес, требуется применить дополнительный механизм идентификации. Он заключается в создании уникального идентификатора сессии для каждого из пользователей и передаче его между сеансами.
Передача идентификатора сессии между сеансами может происходить как передача параметров строки запроса, каждая ссылка и форма па странице должны иметь этот параметр. Недостаток этого способа идентификации состоит в том, что при большом числе пользователей и генерируемых для каждого пользователя страниц загрузка сервера значительно повышается за счет обработки каждой ссылки и формы страницы.
ВНИМАНИЕ
Идентификатор сессии должен быть случайным для каждой новой сессии пользователя, это позволит избежать подбора идентификатора и подмены пользователя.
Другой способ состоит в использовании механизма Сооkies. Преимущества последнего очевидны — нет необходимости дополнять каждую ссылку и форму страницы параметром сессии, это снижает нагрузку и позволяет сохранять некоторые параметры между сессиями пользователя, вести статистику посещаемости конкретного пользователя и на основе его предпочтений предоставлять персонализированную информацию сразу, без проведения дополнительной авторизации. Однако, как и у всех методов идентификации, в данном случае есть свои минусы. Поддержка Соокies может быть отключена в большинстве используемых браузеров. Статистика свидетельствует, что на данный момент поддержку Сооkies отключают порядка 0,5 % пользователей Интернета, поэтому если Интернет-приложение должно обрабатывать всех пользователей, следует предусмотреть возможность обработки и таких запросов.
-
Сессия считается завершенной, если от пользователя не было обращений в течение 15 минут.
А почему именно 15?
У меня магазин на 10 настроен :(
И что теперь делать? :)
-
А можно ли обеспечить сессию без использования cookies и query string? Причем учесть возможность работы пользователся через проксю и использование одного ай-пи разными пользователями.
-
А можно ли обеспечить сессию без использования cookies и query string?
Честно говоря, я не обошел эту проблему...
У меня при каждом действии, пользователь с отключенными куками должен подтверждать свою личность.
Кстати на этом форуме тоже самое. Нет куков-нет автоматического распознавания.
-
Apache::ASP 2.0.7
Apache::ASP - это порт ASP (Active Server Pages) для веб-сервера Apache c perl-ом в качестве языка написания скриптов. ASP - это платформа для создания веб-приложений, которая используется в Microsoft NT/IIS серверах. Apache::ASP позволит разработчикам создавать динамические веб страницы с возможностью контроля над сессиями и расширяемые Perl-кодом. Этот модуль имеет ряд дополнительных функциональных возможностей: библиотеку тэгов XМL, визуализация (rendering) XSLT, новые события не входящие в оригинальное API ASP.
И ещё вот тут - http://www.xpoint.ru/archive/topic7/2/442.html?print
-
Ну вот. Можно сказать, что вытянул я от вас ответ.
Всем спасибо. :)
-
Можно сказать, что вытянул я от вас ответ.
Ага, вытянул и в кусты... :)
А тема на самом деле оч. интересная. Действительно нужно будет модули на CPAN прощупать. Давно уже туда не залазил :(
-
Интересно, что происходит? Забавно...
http://forums.webscript.ru/showthread.php?s=&postid=14609#post14609
-
NeoNox просто видимо всех потянуло на подвиги ;)
-
Итак, сессия - это .....
Сессия это методика ленивых програмеров, с помощью которых они отслеживают
одного пользователя (одно окно броузера, возможно с разветвлениями).
Ленивым програмерам это надо для того, чтобы каждому пользователю выдавать
данные предназначенные только для него одного персонально, особо не мучаясь.
Поскольку HTTP/1.0 не делает каких либо различий между запросами (+ в рекомендации
советовалось, чтобы по каждому URL выдавалось только один и тот же результат невзирая
на запрашивающего, кроме механизма куков), то этот механизм (различий) ввели искуственно
с помощью сессий.
Существующие механизмы аутентификации посредством HTTP заголовков (а не формочек) и
передачи переменных (Всех!!!) в каждом запросе к серверу (и на картинки тоже) перестали
програмеров удовлетворять. 1) несекурно 2) много лишних данных гоняется туда-назад.
3) пользователи пугаются и путаются видя стандартный запрос login/pass а не формочку.
Посему вместо этого каждый запрос _авторизируют_ (всмысле аля пароль спрашивают) по
этому номеру сессии (+IP и др). Это конечно тоже можно взломать... но удобство/секурность
тут выше (соотношение).
Этот механизм чем-то эстафетную палочку напоминает... А то что оно дествует
определенное время - это такой хак, снова от лени и недоверия к посетителю (конечно
обоснованное недоверие :)
Т.е имеем дефакто исправление стандарта HTTP.
Вот :-)
Как жаль, что все, сказанное в форумах уходит вникуда.....
-
Как жаль, что все, сказанное в форумах уходит вникуда.....
Не-ет, не уйдет :)! Может в ближайшем будущем FAQ сделаем по всмеу форуму.
-
Твое "может" звучит очень обнадеживающе :)))))))))
Тут говорили , что Wiki - более правильный способ собирать знания, чем форум
или список рассылки.... Может его поставить?
-
Может его поставить?
Кому нужно, и в форуме найдут. А кому не нужно и так по сто раз спрашивать будут, без поиска...
-
Протокол НТТР изначально проектировался без поддержки механизма информации о состоянии сеансов работы пользователя.
Ессно - там использовался более правильный механизм - индентификации
пользователя независимо от времени его работы с сервером ;)
Само понятие сеансов тогда просто небыло никому нужно,
поскольку существовала стандартная аутонтификация пользователя,
все знали, что даже clear-text пароли никто ловить не будет и
каждый броузер использовался одним человеком (всмысле ушел - закрыл
за собой).
А можно ли обеспечить сессию без использования cookies и query string?
Да конечно! :)
через URL вида http://host/632543245287687/history/2001.html
Читай про "mod_rewrite" например или напиши скриптик PHP, который
будет весь сервер отдавать сам и сам парсить такие URL-ки ;)
-
Да конечно!
через URL вида http://host/632543245287687/history/2001.html
Query string и то, что ты написал примерно одно и тоже.
А без этого как? Можно?
-
Аа... ты бы и сказал - через URL
QUERY_STRING - это все что после знака "?"
Можно через POST теоретически.... оно с URL никак не связано.
Можно через аутонтификацию стандартную
http://83457349857:SFSDFDS@server/dir/file.html - это надо только 1н раз указать для сервера
(чтобы человек туда кликнул) А потом броузер сам будет слать заголовок Authorization:
83457349857:SFSDFDS - тоже случайно генерится. Из PHP брать как $PHP_USER, $PHP_PASSWORD
Еще способы ? :)
-
Спасибо всем за ответы!
А нельзя ли еще конкретный пример(на Перле)?
-
use Session.pm
на cpan.org пока к сожалению нет... но в инете найти можно... если хочешь могу выслать очень удобный модуль...
-
Вот этот?
http://search.cpan.org/~rsoliv/Session-0.01/Session.pm
Это просто ОО обертка к Apache::Session.
-
нет... там привязка с БД есть ... на perl.ru(пока он был жив) долго обсуждали этот модуль... :)
-
commander ну ты бы почитал что такое Apache::Session. Уверяю, найдеш массу интересного.
-
NeoNox
Почитал... действительно много интересного...
-
Ну насчет того что номер сесии генериться случайно конечно все понимают что псевдослучано (это просто оговорочка для точности)!
У меня другая проблема: мне надо знать когда сессия закончилась! Буквально мне надо отследить сколько человек в данную минуту на сайте! Поможете?
-
Puma
сложно определить кол-во открытых сессий на данный момент?
-
commander
А как это сделать?
-
Puma
документация решает... :)
-
commander
Как определить количество открытых сессий на данный момент?
-
Не могли бы вы написать код реализующий эти сессии?!
-
cессии на perle
cgi::session и cgi::ksession
второй мне больше нравится
http://www.webdocs.ru/articles/article144/ (http://www.webdocs.ru/articles/article144/)
-
Блин а не проще свою, и смому систему ссесий написать....
Это ведь не так ужь и сложно....
В любом случае эта система ссесий хранит идентификатор ее либо в куках либо как параметр в адресе....
что мешает самому написать функцию которая после авторизации создает ключь ссесии... и таким-же образом хранит его у юзверя?
Это буквально строк 20-30
-
А что если смотреть перменные окружения, которые остаются неизменными для каждого конкретного браузера при неоднократном заходе на сайт?
Например, возьмем переменные окружения:
HTTP_ACCEPT_ENCODING
HTTP_CONNECTION
REQUEST_METHOD
HTTP_ACCEPT
HTTP_ACCEPT_CHARSET
QUERY_STRING
REMOTE_PORT
HTTP_USER_AGENT
HTTP_CACHE_CONTROL
HTTP_ACCEPT_LANGUAGE
HTTP_COOKIE
REMOTE_ADDR
HTTP_KEEP_ALIVE
SERVER_PROTOCOL
HTTP_X_FORWARDED_FOR
GATEWAY_INTERFACE
DOCUMENT_ROOT
HTTP_VIA
HTTP_HOST
оставим только те которые неизменны на период сессии, к примеру(чем больше тем лучше):
HTTP_VIA
SERVER_PROTOCOL
HTTP_X_FORWARDED_FOR
GATEWAY_INTERFACE
REMOTE_ADDR
(еще можно какие нибудь, чем больше тем лучше)
Вскрипте получаем все эти данные, на основе какого либо алгоритма получаем уникальный ключ, этот ключ и бдует идентификатором сессии.
Данная система не будет работать только если взять два компьютера, поставить одинаковые ОС и браузеры, под ними заходить на сайт через elit proxy (прокси которые ни в одном из заголовков не остовляют следов о том что это прокси). Но наверное таких практически нет.
-
xames
А не легче сгенерировать пару чисел + текущая дата + веселый алгоритмик
-
При работе с сессиями у меня возник вопрос.
Допутим есть две страницы. На первой создается сессия (используется файл), в эту сессию заносятся какие-то переменные. Далее по URL передается id этой сессия на вторую страницу.
А как потом эти данные получить из сессии получить на второй странице? Документацию читал - не въехал.
-
Далее по URL передается id этой сессия на вторую страницу
Вот по этому ID ты можешь получить нечто свое:
(используется файл), в эту сессию заносятся какие-то переменные
Если ты используешь для каждого пользователя свой фаил, то ID - может быть именем фаила, только тут надо быть сторожным! Фильтровать имя фаила!
Если ты используешь 1 фаил с строками... то ID может быть 1 Элементом в образных столбцах...
ID:Login ... Name:
Но я не рекомендую использовать для таких дел простые текстовые Фаилы! Столько гемора в лицо получишь....
-
Nikolai Z., спасибо за ответ, но он для меня неисчерпывающий.
Когда юзер логинется, то сначала он аунтифицируется, если
ауентификация прошла успешно, то его логин и пароль заносится в
сессию. ID сессии передал, теперь как из нее выдрать нужные мне
параметры. Например в ней храниться логин и пароль.
Какие конкретно методы/операторы нужно применить? Интересует непосредственно код. Спасибо.
-
Vankovski
Какой модуль перла ты юзаешь?
(Всмысле какой модуль у тебя работает с сессиями?)
Или ты сам писал?
-
CGI::Session
-
perldoc CGI::Sessio не помогает?
-
Нет, не догнал. Просто я раньше занимался с PHP и там с сессиями вопросов не возникало. А совсем недавно перешел на перл и на этом вопросе стопорнулся.
-
это означает чтение документации.
-
arto, спасибо, документацию читал и не раз. Не знаю, не получается и всё. Получается, что я тугой. Не мог ли ты мне лично объяснить, как работать с одной и той же сессией на разних страницах? Буду признателен.
-
передавать на них один и тот-же сессионный идентификатор.
-
Так, хорошо. Передаю, получаю, всё хорошо. А как потом с переменными, которые сидят в сессии работать?
-
# perldoc CGI::Session
...
# storing data in the session
$session->param(\'f_name\', \'Sherzod\');
# or
$session->param(-name=>\'l_name\', -value=>\'Ruzmetov\');
# retrieving data
my $f_name = $session->param(\'f_name\');
# or
my $l_name = $session->param(-name=>\'l_name\');
...
-
# retrieving data
my $f_name = $session->param(\'f_name\');
переменная $session на новой странице как объявляется?
-
такое впечатление, что вы функционально неграмотный.
у меня нет времени пересказывать вам документацию.
а в связи с тем, что вы не знаете как передавать переменную между запросами,
у меня есть подозрение, что вы не программист.
# perldoc CGI::Session | grep -B0 -A18 "^T"
TO LEARN MORE
Current manual is optimized to be used as a quick reference. To learn
more both about the philosophy and CGI::Session programming style, con-
sider the following:
╥ CGI::Session::Tutorial - extended CGI::Session manual. Also
includes library architecture and driver specifications.
╥ We also provide mailing lists for CGI::Session users. To subscribe
to the list or browse the archives visit https://lists.source-
forge.net/lists/listinfo/cgi-session-user
╥ RFC 2965 - "HTTP State Management Mechanism" found at
http://ftp://ftp.isi.edu/in-notes/rfc2965.txt
╥ CGI - standard CGI library
╥ Apache::Session - another fine alternative to CGI::Session.
-
Ок, спасибо.
-
хы долго думал, стоит ли таки вставить свое слово среди монстров ). больше всего я согласен с вот этим высказыванием
NeoNox:
Протокол НТТР изначально проектировался без поддержки механизма информации о состоянии сеансов работы пользователя. Индивидуальные запросы не связаны друг с другом, и НТТР-сервер не располагает средствами распознавания конечных пользователей между сеансами. Поэтому требуется определить способ идентификации пользователя, связать данные предыдущих и текущего сеансов работы пользователя.
А сессии нам как раз нужны для того чтобы изолировать сеанс пользователя.
И при таком раскладе единственно адыкватный выход - передавать броузеру идентификатор, а данные сеанса хранить на сервере. Чем в принципе и пользуются все решения как php так и perl думаю, хотя не знаком, так и ASP.NET
Единственная, мне кажется, в таком случае уязвимость - возможность подключиться к сеансу пользователя сдублировав его запрос. Но ведь всегда при необходимости можно пойти по дороге шифрования трафика. Спасибо, надеюсь ниче глупого не сказал. все таки первый раз здесь