Как Perl обрабатывает сеансы иначе, чем PHP?

Question

Я пытаюсь клонировать коммерческую систему управления студентами, написанную на Perl. Я хочу использовать PHP, поскольку у меня нет опыта работы в Perl.
Теперь я пытаюсь настроить систему входа, которая должна быть (должна быть?) Выполнена с помощью PHPSESSID, не так ли? Теперь, на PHP, я мог передавать идентификатор сеанса через GET, POST и COOKIE.

Веб-сайт Perl не добавляет параметры URL (GET) и не сохраняет файлы cookie на моем компьютере (COOKIE). Также нет формы, которая могла бы содержать скрытое поле (это будет POST в PHP, не так ли?)

Может ли кто-нибудь сказать мне, как Perl запоминает зарегистрированного пользователя?

Answer 1

Perl использует гораздо более «инструментарий» для построения веб-приложений, чем PHP, поскольку Perl не был специально разработан для работы в Интернете. Таким образом, он не имеет встроенного способа управления сеансами веб-приложений; скорее, есть много модулей на CPAN, которые осуществляют управление сеансами разными способами.

Если вы должны были идентифицировать рассматриваемую систему управления студентами и предоставить URL-адрес, мы могли бы посмотреть на него со стороны и определить, что он делает, но, действительно, я задаюсь вопросом, действительно ли вам нужно использовать такую ​​же систему управления сеансом, что и существующее приложение, если вы не хотите внедрять единый вход между исходной версией и вашим клоном [1]. Сосредоточьтесь на клонировании видимого пользователем интерфейса и функциональности, а не на деталях реализации.

[1] ... что было бы бесполезно, если вы также не планируете подключаться к своей базе данных сеансов на заднем конце, так как никто не узнает идентификаторы сеанса другого, если они не используют эти данные.

Answer 2

Для полноты информации существуют ДРУГИЕ, нестандартные способы хранения/передачи информации о сеансе, чем 3 метода, которые вы указали (хотя я серьезно сомневаюсь любой из них используется в ваших СМС). Среди них:

• Отправка данных куки в рамках DOM (например, в HTML) и имея на страницах доступа JavaScript его из DOM

• Или просто хранить cookied данные как данные в JavaScript в первое место.

• AJAX звонки. Например. логика с поддержкой сеанса обрабатывается в URL-адресах AJAX, а не в основных URL-адресах. Да, я знаю, что это абсолютно болтливо. Но выполнимо.

• Не храните файл cookie в основной базе файлов cookie (так что вы не можете найти его, используя стандартные методы просмотра файлов cookie). Более подробную информацию о том, как это сделано, пожалуйста Google «evercookie» для очень крутой метод упорно хранящей информацию печенья с использованием до 10 резервных вариантов хранения - один хороший интро http://blog.depthsecurity.com/2010/09/super-persistent-cookies-evercookie.html

Все, что сказал, я полностью согласен с ответом Дейва - просто используйте механизм передовых методов PHP для реализации функций вместо клонирования, возможно, perl-специфичной и, возможно, странной реализации в webapp.