Проблема с кодировкой получаемых, а не отправляемых данных. Если я отправляю данные назад в браузер из таким заголовком, они отображаются корректно, JS их парсит, но json_decode в php выдаёт ошибку.
Пытался использовать mb_convert_encoding между каждой парой кодировок из следующего списка в обе стороны. Не помогло.
$encodings = ['UTF-8', 'UTF-16', 'UTF-16LE', 'UTF-16BE', 'UCS-2', 'UCS-2LE', 'UCS-2BE', 'ISO-8859-1', 'ISO-8859-5', 'CP1251', 'CP1252', 'KOI8-R', 'KOI8-U'];
teke teke, да именно так. Солить, как я уже понял, бессмысленно, а инвалидировать может понадобиться, например, если пользователь забыл поставить "чужой компьютер" и выити или украли ноутбук, на котором совершен вход на сайт. В таком случае кнопка "инвалидировать все сессии, кроме текущей", подобная аналогичной Вконтакте, может быть очень кстати. Хотя для опасных действий всё равно нужно подтверждение паролем, есть и безопасные, но неприятные при использовании злоумышленником возможности.
RidgeA, чтобы инвалидировать сессионный ключ достаточно удалить сессию из БД. Если нужно инвалидировать все сессии - truncate table sessions. Соль в этом случае не нужна и не поможет, так как предполагается уникальной для каждого ключа, как и в случае с паролями. Кроме того, не вижу смысла хранить невалидные сессии в БД. Или я Вас неправильно понял?
sim3x: А если сделать достаточно пользователей БД и просто не давать возможность записи туда, куда не надо? Ведь, насколько я понимаю, для получения доступа к админке нужна запись или в таблицу авторизационных данных, или в таблицу сессий, иначе только SQL-инъекцией отделаться не получится, я прав? Или чтение таблицы сессий и брутфорс хеша сессионного ключа (длиной, например, 256 бит) для подстановки в куки - тоже вполне реалистичный вариант?
А вообще это только одно из преимуществ, которые я вижу, и мне интересно узнать, какие ещё преимущества в обеих схемах и когда какую стоит применять.
Если уязвимость к SQL-инъекции находится в коде, не связанном со входом или регистрацией, запрос будет исполняться от имени пользователя БД, не имеющего доступа к авторизационным данным даже на чтение.
chupasaurus: Enterprise-диски имеют совсем другие сроки жизни, чем потребительские, к которым относится мой, и вероятность сбоя контроллера и невозможности получить содержимое после исчерпания ресурса у них ниже (да, я делаю бекапы, но они всё же всегда немного устаревшие). Про KISS я слышал и применяю его там, где требуется возвращения к чему-то несколько раз, и, следовательно, излишняя сложность будет отбирать время. А возвращаться к /tmp мне ни разу не приходилось - настроил и работает.
Да, я понимаю, что этот случай попахивает паранойей, но я видел и смерть SSD, и немало случаев потери данных.
Это не от прочитанных сказок, 2 случая износа SSD я знаю из собственного опыта. С тем, что переносить системный /tmp к пользователю - плохая идея, согласен, но насчет идиотизма - не все знают linux идеально с пеленок.
