Sp1keazyYT, тогда еще раз повторю - НИКАК нельзя такое реализовать не имея логин/пароль от аккаунта. Я вам опять же в прошлом вопросе про это написал, а вы мне ответили - "ну мне и надо для своего аккаунта"
Sp1keazyYT, как я уже написал вам в предыдущем вопросе - в первую очередь вам нужна полноценная авторизация в Steam и получения куков. Только после этого вы сможете что-то сделать с лотами на торговой площадке. Про OpenID вообще забудьте, зачем он вам? Если это ваш аккаунт, то вы и так по дефолту имеете информацию о нем.
Вот это рабочая библиотека для авторизации. Это библиотека для получения кода мобильной аутентификации на основе секретного ключа. Вот статья как получить секретный ключ. Для авторизации этого будет достаточно.
Такие данные вы сможете получить только после полноценной авторизации и получения куков. С помощью OpenID такие данные не получить. Соответственно вы можете такое реализовать только если у вас будет логин/пароль + данные двухфакторной аутентификации от аккаунта.
Sp1keazyYT, никак вы не получите куки Steam через OpenID. Вы вообще ничего кроме SteamID64 и базовых данных из профиля пользователя не получите при такой авторизации.
Денис, лучше сразу перейдите на PDO или какие-нибудь библиотеки для работы с БД (например SafeMySQL неплоха и ничего лишнего). Во-первых это безопаснее и позволяет избежать SQL-инъекций. Во-вторых благодаря плейсхолдерам не будет лишних проблем с экранированием данных в запросе.
Не совсем понятно, что вы имеете ввиду. У вас в переменной response ответ промиса, соответственно и все данные полученные в AJAX-запросе. Что вам еще нужно?
Только если обфусцировать код, но это совсем не панацея, это лишь усложняет восприятие и расшифровку кода, не более. Полностью скрыть код и данные, которые обрабатываются на стороне клиента, никак не получится. Но для чего вам скрывать данные полученные AJAXом и почему они становятся конфиденциальными если вы их отдаете клиенту? Может быть вы просто не совсем правильно понимаете чего вы хотите добиться?
lil_web, ну так а каким образом к странице получит доступ злоумышленник не зная пароля и не имея куков администратора? В чем конкретно заключается найденная вами уязвимость?
Откуда у вас берется эта строка с таким экранированием? Судя по всему это JSON и все можно сделать гораздо удобнее, чем заменять экранированные символы :)
А вот почему в консоли саблайма new Date выдает не корректное значение Hours
Точно по той же причине выдает дату в UTC, что и например Firefox выдает в своей консоле дату тоже по UTC. Все зависит от того как движок обрабатывает экземпляр объекта даты.
а вот метод getHours этого же обьекта выдает нормальное значение Hours?
Так я об этом и написал как раз, что все методы работы с датой будут отдавать значение в текущем часовом поясе клиента. Кроме методов, которые должны отдавать время по UTC. Это так по стандарту прописано и все JS-жвижки его соблюдают. То есть суть простая. Когда вы создаете новый экземпляр объекта даты вы же не будете выводить его в чистом виде на страницу, потому что это еще не обработанные данные. Вы будете работать с методами объекта, чтобы вывести время в нужном вам виде/формате. Вот эти методы будут выводить вам корректное время, приводя его к часовому поясу клиента, а сам объект даты будет по дефолту хранить текущее время в UTC. А то, что Chrome в консоле выводит дату в вашем часом поясе, то это просто в самом Chrome так сделано, но внутри объекта дата в любом случае хранится в UTC даже в Chrome.
Асинхронная функция возвращает то значения, которое вы укажете, как и обычная функция. Отличий в возврате значений между ними нет. Если вы будете возвращать промис, то будет промис, если просто какую-нибудь строку, будет строка.
Разные браузерные движки видимо просто по разному отображают дату. Например Chrome отображает по текущему часовому поясу, а Firefox по UTC, как и вашем случае. Вообще время по дефолту всегда считается по UTC, а все остальное это лишь представление времени к текущей конфигурации пользователя. В принципе не имеет значения как браузер отображает дату непосредственно при вызове экземпляра объекта даты, потому что все методы работы с датой в дальнейшем будут отдавать ее по текущему часовому поясу, если это не методы получения даты по UTC.