Как лучше получить Steamloginsecure имея логин, пароль и рефреш токен?
По вводным: я делал программу, которая работала с запросами стим. Но обнаружилось, что для разных разделов сайта в куках используются разный steamLoginSecure. Также я обнаружил, что при авторизации в стим через set-cookie устанавливаются эти steamloginsecure под разные разделы.
По вводным: еще видел, что кто-то писал такое:
Сейчас ситуация такая: "Даешь стиму логин и зашифрованный пароль (если нужно то потом еще даешь стим гуард), тебе стим даст рефреш токен. С рефреш токеном снова идешь к стиму и он даст жсон со списком. В этом списке будут элементы следующего вида: юрл и 2 токена. Выбираешь для чего тебе нужна кука (там будут стор, стимкоммунити, стим.тв и тд) и идешь туда (с токенами), тебе в ответ придет кука steamLoginSecure. Ну вот если кратко как получить рефреш токен и как его использовать для получения куки". Но тут не совсем понятно на какой именно url отправлять запросы, с какими параметрами.
Подскажите, как можно получить это значение
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Пока нет других ответов. Будьте первым, кто поможет автору.
Ответить на вопрос
Работать со Steam через ручное получение steamLoginSecure - плохая идея, если речь не про вашу собственную сессию и не про официально разрешённую интеграцию. Эта cookie фактически относится к авторизованной веб-сессии. Её хранение, передача и подстановка в разные разделы сайта легко приводит к проблемам безопасности: утечке аккаунта, банам, 2FA-проверкам и нестабильной авторизации.
Если задача легитимная, сначала проверьте, можно ли решить её через официальный Steam Web API, OpenID или OAuth-подобный сценарий входа. Для большинства публичных данных и действий с профилем не нужно вручную добывать cookies.
Если вы автоматизируете свой аккаунт для внутренних задач, учитывайте:
Правильнее построить отдельный слой авторизации: хранить секреты в защищённом хранилище, не логировать cookies, обновлять сессию штатным способом и обрабатывать 401/403 как нормальный сценарий, а не пытаться “вытащить ещё одну cookie”.
Безопасный минимум: не писать cookie в логи; не коммитить cookie в репозиторий; шифровать хранилище; разделять аккаунты; использовать официальный API там, где он есть.
Если конкретный раздел Steam требует отдельную cookie, это значит, что он завязан на веб-сессию конкретного домена. Универсального steamLoginSecure “для всего сайта” может не быть. Поэтому архитектурно лучше уходить от парсинга авторизованных страниц к официальным методам, где это возможно.