Передача данных через сеансы

Question

Я не позволяю пользователю редактировать некоторые уникальные идентификаторы, когда я пропускаю его через $_POST, поэтому вместо этого я использую $_SESSION, потому что, насколько я знаю, сеанс не может быть отредактирован.

Это хорошее и безопасное решение? Конечно, я отключаю его после прочтения.

Я хочу быть уверен, поэтому я и спрашиваю.

Код, где я это делаю:

if(!isset($_POST['save'])) {
     $posts = $_POST['special_ids'];
     [..]
     $_SESSION['posts'] = $posts;
     echo "<input type="hidden" name="save" value="1"/><input type="submit" value="Submit!"/>";
     [..]
} elseif(isset($_REQUEST['save'])) {
     //then I'm reading the $posts
     $posts = array($_SESSION['posts']);
     [...] //doing what I need with it.
     unset($_SESSION['posts']);
}

Answer 1

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

Но для большинства приложений это будет рабочее решение.

Answer 2

Что такое данные, которые вы передаете?

В общем, сессия должна использоваться ТОЛЬКО для данных, которые должны "плавать" неопределенно долго.Его не следует использовать как «простой» способ передачи данных с одного экрана на другой.

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

Но если у вас есть данные, которые вы хотите передать с одного экрана на другой, сеанс действительно очень плохместо, чтобы сохранить его.Это особенно верно, если данные контролируют ход программы.Это так по всем причинам, по которым глобальные данные опасны, а затем и по некоторым причинам.

Во-первых, в веб-приложении вы не контролируете, что пользователь будет делать дальше.Он может нажать кнопку «Отправить» или нажать кнопку «Назад» в браузере, или он может ввести URL-адрес какой-то совершенно другой страницы в вашем приложении.Вы говорите, что очистите данные сеанса после его использования, но как вы узнаете, что даже попадете на экран, где вы их очищаете?У вас нет способа заставить это произойти.Предположим, вы намереваетесь: пользователь открывает экран A и нажимает кнопку «Отправить».Вы сохраняете что-то, что он ввел в сеанс, и затем отображаете экран B. Когда пользователь нажимает кнопку «Отправить», данные, введенные на B, плюс данные сеанса обрабатываются экраном C. Теперь вместо этого пользователь открывает экран A и нажимает кнопку «Отправить», затем, когда отображается экран B.он вводит URL-адрес экрана D. Через полчаса после посещения многих других страниц он вводит URL-адрес экрана C. Данные сеанса все еще там.Что должно произойти?Это становится еще хуже, если ваша программа проверяет наличие данных сеанса и дает другое отображение в зависимости от того, есть оно или нет.Например, если вы скажете, что отображаете экран A, собираете данные сеанса и затем переходите к B. Но ваша программа делает это, говоря, что когда отображается программа A, если данные сеанса присутствуют, это должно означать, что мы уже были здесь,перейти к B, в противном случае остаться на A. Я видел много программ, которые работают так.Затем, если пользователь нажимает браузер назад или вводит URL, эти данные сеанса остаются позади, и в следующий раз, когда он пытается попасть на экран A, он волшебным и таинственным образом переносится на экран B, ничего не вводя.

Во-вторых, это создает кошмар обслуживания.Через шесть месяцев вы вернетесь, чтобы поддержать эту программу.Вы видите программу, собирающую данные из переменной сеанса.Как оно туда попало?В какой программе это происходит и при каких обстоятельствах?Кто еще это читает?Когда?Когда вы передаете значение подпрограмме в качестве параметра, вы можете легко увидеть, что именно передано, когда и как.Но когда вы используете глобальные данные, такие как переменные сеанса, это все загадка.

Глобальные данные могут показаться простым выходом из сложных сценариев передачи данных.Но это ловушка.

Ну, я не знаю точно, какие именно данные вам нужно передать или как они будут использоваться, поэтому вышеприведенное может относиться или не относиться к вашему делу.

Пояснение в ответ Мэтту

Данные сеанса следует использовать для данных, связанных с SESSION, в отличие от данных, связанных с одной транзакцией, т.е.одиночная поездка в оба конца на сервер.Например, если у вас есть данные о пользователе, например номер счета или часовой пояс, в котором он находится, разумно сохранить данные сеанса.Но данные о конкретной транзакции, например, какая запись обновляется или сообщение об ошибке отправляется обратно, не должны храниться в данных сеанса.

Если необходимо обязательно очистить переменную сеанса сразу после использования, так какв противном случае следующая транзакция будет обрабатываться неправильно, тогда это не должно быть в данных сеанса.Потому что где-то между трудностью и невозможностью гарантировать, что данные будут очищены.

Мало того, что возможны "другие маршруты", но их невозможно контролировать.Вы не знаете, какой URL-адрес пользователь может ввести в браузер.В принципе, я полагаю, что вы могли бы заставить каждую страницу вашего приложения проверять каждую переменную сеанса, которую вы когда-либо устанавливали, каким-то образом выяснить, какие из них не следует устанавливать при переходе на этот экран, и очистить их.Затем каждый раз, когда вы создаете новую переменную сеанса, вы должны обновлять каждый экран, чтобы добавить его в список.Хорошо, это может быть обычная функция, поэтому вам не обязательно обновлять сто экранов каждый раз, когда добавляется новая переменная сеанса.Но вам все равно придется помнить, чтобы обновить эту функцию и правильно проверить все переменные сеанса.Зачем создавать головную боль обслуживания?Только не делайте этого.

Даже если вы можете заставить это работать, у вас все еще есть глобальная проблема с данными.Глобальные данные плохие.

Answer 3

Если вы определяете значения на сервере и не хотите, чтобы конечный пользователь мог их редактировать, определенно безопаснее использовать $ _SESSION, а не отправлять их клиенту и возвращать их снова, так как да, они мог быть подделан.

За исключением уязвимостей сервера, клиент не может напрямую изменять свои значения сеанса.