Обеспечение DB и данных сессии по PHP совместно использованный хост
Ваши ключи словаря не могут быть списками †. Вы, вероятно, хотите строки, а не списки с одним элементом.
то есть. 'Jane' вместо ['Jane'].
Вы можете использовать словарь-понимание; итерация со второго подсписка и далее. Мы также используем списки для преобразования оценок в целые числа.
{name:[int(score) for score in scores] for name,*scores in student_grades[1:]}
, что дает:
{
"Jane": [
100,
90,
80
],
"John": [
88,
99,
111
],
"David": [
45,
56,
67
]
}
† Причина, по которой вы не можете иметь списки в качестве ключей для словарей, потому что они не не могут быть обработаны . Словарь - это, по сути, хеш-таблица, в которой элементы хранятся в ячейках памяти, связанных с их хэшами, так что вы можете быстро «искать» элемент в словаре. Однако это работает только в том случае, если каждый ключ может быть хеширован , а список - нет. Почему не может это? Потому что хеш должен учитывать все составляющие элемента объекта и не должен изменяться. Однако элементы списка могут измениться, потому что это изменяемая структура данных (в отличие от неизменяемой строки или кортежа и т. Д.), Следовательно, он не может надежно вычислять тот же хэш, поэтому не может / не может реализовать эту функциональность.
5 ответов
Пока Ваш код работает как общий интернет-пользователь, что-либо сохраненное на сервере будет уязвимым. Любой другой пользователь мог записать Сценарий PHP для исследования любого читаемого файла на сервере, включая данные и код PHP.
Если Ваш поставщик услуг хостинга позволит его, работая как PHP, поскольку CGI при другом пользователе поможет, но я ожидаю, что будет значительный хит производительности, поскольку каждый запрос потребует, чтобы был создан новый процесс. (Вы могли посмотреть на FCGI как на лучше работающую альтернативу.)
Другой подход должен был бы установить cookie на основе чего-то, что пользователь обеспечивает, и используйте это для шифрования данных сессии. Например, когда пользователь входит в систему, возьмите хеш их имени пользователя, пароль (как просто предоставлено ими) и текущее время, зашифруйте данные сессии с хешем, установите cookie, содержащий хеш. По следующему запросу Вы вернете cookie, который можно затем использовать для дешифрования данных сессии. Обратите внимание однако, что это только защитит текущие данные сессии; Ваша пользовательская таблица, другие данные и код все еще будут уязвимы.
В этой ситуации необходимо решить, является ли компромисс низкой стоимости общего хостинга приемлемым рассмотрением уменьшенной безопасности, которую это обеспечивает. Это будет зависеть от Вашего приложения, и может случиться так, что вместо того, чтобы пытаться придумать комплекс (и возможно даже не очень эффективный) способ добавить безопасность, Вы более обеспечены просто принятие риска.
Я не просматриваю безопасность как все или ничего. Существуют шаги, которые можно сделать. Дайте веб-пользователю дб только полномочия, в которых это нуждается. Пароли хранилища как хеши. Используйте открытый вход в систему, таким образом, пользователи обеспечивают свои учетные данные по SSL.
PHP на cgi может быть медленнее, и некоторые хосты не могут просто хотеть поддерживать больше чем одну среду.
Вы, возможно, должны придерживаться своего хоста по некоторым причинам, но обычно существуют так многие доступные, которого это - хорошее напоминание для людей, чтобы сравнить функциональность и безопасность, а также стоить. Я заметил многие компании, начинающие предложить хостинг виртуальной машины - почти безопасность уровня выделенного сервера с точки зрения изоляции Вашего кода от других пользователей - в том, что является мне разумной стоимостью.
Общий хост не является никаким способом выполнить веб-сайт, если Вы сознательны о конфиденциальности и безопасности Ваших данных из сайтов, с которыми Вы совместно используете сервер. Что-либо доступное для Вашего веб-приложения является справедливой игрой для других; это только будет вопрос времени, прежде чем они смогут получить доступ к нему (предположение, что у них действительно есть стимул сделать это Вам).
"можно поместить переменные соединения с БД в файл ниже веб-корня. это, по крайней мере, защитит его от веб-доступа. если Вы собираетесь использовать основанные на файле сессии также, можно установить путь сессии в каталоге пользователя и снова вне веб-корня".
У меня нет учетной записи, таким образом, я не могу downvote это.. но серьезно это даже не относится к вопросу.
Понятное дело Вы храните материал вне webroot. Это идет для любого сценария хостинга и не характерно для общего хостинга. Мы не говорим о защите от посторонних здесь. Мы говорим о защите от других приложений на той же машине.
К OP я думаю PHP, поскольку CGI является большей частью безопасного решения, поскольку Вы уже предложили себя. Но поскольку кто-то еще сказал, что существует производительность, пораженная этим.
Что-то, на что Вы могли бы посмотреть, перемещает Ваши сессии и дб к MySQL и использует safe_mode и/или open_basedir.
Я решил бы проблему с изменением infrasturcture вместо кода один. Рассмотрите обновление до сервера VPS. В наше время можно получить их очень недорогой. Я видел, что VPS's запускается 10$/mo.