Есть ли вероятность того, что кешированный файл может прийти быстрее не кешированного
Тут имеется в виду кэш браузера. Сеть всегда будет медленнее диска, вопрос только на сколько. Я готов поспорить что кэш всегда будет минимум в 3 раза быстрее не кэша.
Не знаю как себя поведет мобильный браузер. Но опять же, можем отфильтровать по юзер агенту только те устройства, где известно что этот трюк работает.
Если соберетесь реализовывать эту идею, напишите потом здесь, если не трудно. Очень интересно узнать что получилось :)
Antonio Solo, мне показалось, что нет. Больше подходит для целенаправленного взлома. Слишком много отличий на каждой машине. Но пока это только предположение.
xomachine, на первый вопрос - нет, как минимум потому что если всесто ассемблерного кода честно прочитать одно значение массива, то хорошо видно какой блок попал в кэш.
На второй вопрос - не знаю. Этот код фактически повторяет то что написано а статьях по уязвимости. Собственно скорее всего там и есть ошибка. Ну и отсюда и вопрос - что я делаю не так?
Если я правильно понял код, тут мы перебираем все возможные варианты перестановок и на каждом шаге просто проверяем уникальность комбинации. Вариант не плох, но на достаточно большом массиве сломается. Поправьте меня, если ошибаюсь.
Mariik: Погодите, у вас subscriber это "[Object]". Если использовать console.log, то при большой вложенности он не показывает объекты, а сокращает их. Попробуйте вывести в консоль "data[0].post.subscriber".
Вам нужно уточнить свой вопрос. Если msg просто текст, то имя пользователя негде взять. И почему вы говорите именно о EJS? Если это не принципиально, то хватит и обычной конкатенации строк.
Николай, Илья, могу ошибаться, но загружать в воркере особого смысла нет. Операция загрузки всё равно будет происходить асинхронно и воркер большую часть времени просто будет простаивать.