Мне нужно построить свою собственную систему для части проекта компьютерной безопасности без использования сеансов php (только файлы cookie), и я просто потерял. Все учебники, которые я нашел, используют сеансы (по уважительной причине), поэтому мне было интересно, знает ли кто-нибудь о том, как свернуть свой собственный учебник по аутентификации пользователя php.
Учебник по аутентификации пользователей PHP без сессий
- очевидный вопрос: почему не сеансы? 13.02.2012
- Профессор написал в предписании не использовать их. На самом деле это задание связано с реализацией моих собственных функций безопасности, и сеанс чтения waht ive позаботится об этом во многом. 13.02.2012
- Вы бы сделали это точно так же, по сути. Вы просто сохраните состояние в файле cookie вместо сеанса. Попробуйте поискать в Google, как вообще использовать файлы cookie в PHP. Возвращайтесь, если вы не можете заставить их работать. Кроме того, кто в мире сказал вам, что сессия заботится о функциях безопасности, которых нет у файлов cookie? Если только ваша младшая сестра не проникает в компьютер, чтобы прочитать файлы cookie вашего браузера, они не сильно отличаются с точки зрения безопасности. Сеансы требуют, чтобы файлы cookie были включены для работы. 13.02.2012
- Не могу придумать никаких руководств, поэтому я не буду публиковать ответ. Вы можете довольно легко свернуть свои собственные сеансы, сохранив идентификатор сеанса в файле cookie пользователя и имея некоторый файл или хранилище базы данных, на которое вы можете ссылаться по их идентификатору сеанса (однако не могу комментировать безопасность этого подхода). Например.
$session = DB::getSession($_COOKIE['sid']);
13.02.2012 - Профессор просто потребовал, чтобы вы не использовали встроенные сеансы PHP, или он вообще имел в виду какие-либо сеансы? 13.02.2012
- Другой возможностью может быть использование какой-либо криптографии для «подписания» файла cookie пользователя таким образом, чтобы вы могли проверить его подлинность, но не могли быть легко продублированы третьими лицами (хотя это по-прежнему оставляет вас уязвимым для прослушивания файлов cookie). Подходящим может быть асимметричный алгоритм, такой как RSA. 13.02.2012
- @Dagon Вы здесь дурак: большинство сеансов ВСЕ ЕЩЕ используют файлы cookie для отправки и хранения идентификатора сеанса. Профессор целенаправленно просит его попытаться заново изобрести сессию. Я совершенно уверен, что профессор не хочет, чтобы его творение использовалось в «реальном мире», но возможность самостоятельного решения реальных проблем чрезвычайно ценна. Тот факт, что это уже сделано, не уменьшает ценности. 13.02.2012
- возможно, но у меня есть большая проблема с тем, как практические предметы преподаются практически без учета того, как они будут использоваться в реальном мире. 13.02.2012
- @LeviMorrison Назовите меня сумасшедшим, но я не вижу смысла учить студента абстрактно думать о практической, реальной проблеме программирования. Вот для чего нужны ваши уроки математики. Научите решать проблемы там. Ваши занятия по COMPSCI должны научить вас, как лучше всего правильно решить проблему в реальном мире. Кроме того, действительно ли PHP является лучшим языком для обучения решению проблем? Ээээ... наверное нет. 13.02.2012
- @Dagon Присоединяйтесь ко мне в чате: chat.stackoverflow.com/rooms/11/php 13.02.2012
- @rdlowrey Присоединяйтесь ко мне в чате: chat.stackoverflow.com/rooms/11/php 13.02.2012
Ответы:
Вы могли бы в основном реализовать что-то вроде сеанса, такого как вы.
Сюда будут входить следующие задачи:
- генерировать случайный идентификатор сеанса для новых пользователей (или при входе в систему - в зависимости от точного использования...)
- сохранить его в куки
- сохраняйте дополнительную информацию о сеансе где-нибудь на сервере вместе с идентификатором сеанса (например, в таблице базы данных)
- при последующих обращениях к странице проверяйте идентификатор сеанса в файле cookie по сравнению с данными на веб-сервере, чтобы идентифицировать пользователей и предоставить доступ
Однако следует отметить, что решение, основанное только на файлах cookie, никогда не бывает таким хорошим. Например, если у клиента не включены файлы cookie, он вообще не будет работать. Возможным решением для этого является отправка идентификатора сеанса в качестве параметра GET с каждой внутренней ссылкой, если файлы cookie не включены.
Сеансы облегчат задачу. Как говорится, где ты застрял, приятель?
Чтобы начать использовать файлы cookie в PHP, проверьте это: http://www.w3schools.com/php/php_cookies.asp
Вы могли бы либо
- реализовать свою собственную обработку сеанса, как предлагает s1lence (что может быть именно тем, что профессор хочет, чтобы вы сделали) или
- реализовать свою собственную обработку сеанса, добавив идентификатор сеанса в QueryString (чтобы он работал для браузеров без файлов cookie) или
- вы можете сохранить пару пользователь/пароль в файлах cookie (что заставит вас повторно аутентифицировать пользователя для каждого запроса)
Я бы не рекомендовал последнее, но если все дело в том, чтобы избежать механизма сеанса, я думаю, это вариант. И последнее замечание: если это не имеет никакого отношения к пониманию того, почему сессия важна, вам действительно следует подвергнуть сомнению задачу вашего учителя.. ;)
Вы не должны использовать куки для такой системы, потому что куки хранятся на стороне клиента. И изменить его может любой. Сессии хранятся на стороне сервера, и только вы можете изменить их (также другие пользователи системы могут изменить их, если у них есть доступ к каталогу или доступ к БД, если вы храните сеансы в БД). Если вам очень нужно использовать куки, вы можете зашифровать логин/пароль, можете писать в куки, но использование сессий более безопасно.
$_SESSION
данные должны быть проверены на стороне клиента. Сценарий, который вы представляете, не более сложен для злоумышленника, чем доступ к файлу cookie идентификатора сеанса. Кроме того, предполагается плохой внутренний дизайн приложения и проверка данных: ошибка, на которую не влияет использование сеансов по сравнению с файлами cookie. Так что да, если вы не собираетесь должным образом защищать свое приложение, возможно, сеансы на 1% безопаснее, чем файлы cookie. 13.02.2012