API-запрос блокировки политики того же источника на удаленном

Question

Вот почему я в замешательстве. Я пытаюсь сделать POST-запрос к https://api.smarkets.com/v3/sessions. Маршрут заключается в создании токена сеанса для последующих запросов к API.

Если я делаю этот запрос на моей локальной машине, он работает нормально. Я получаю ответ 2xx. Однако, если я попробую на удаленном компьютере ( Окно DO, которое я запускал вчера вечером ), я получу ответ «503 Сервис временно недоступен».

Я попытался войти через браузер и Я получил тот же ответ. Я поднял этот вопрос на Smarkets , и они ускользнули от того факта, что это может быть связано с политикой того же происхождения, навязанной Smarkets.

Через некоторое время мне удалось войти через Chrome путем отключения политики того же происхождения. Запрос API все еще не выполнен.

Из моих ограниченных знаний политики одного и того же происхождения (, пожалуйста, исправьте меня, если я ошибаюсь ), он указывает, какие ресурсы могут быть возвращены из определенных происхождение. Похоже на вопросы CORS. Зачем мне явно отключать веб-безопасность на удаленном браузере, чтобы он входил на smarkets.com, но мой браузер на моем локальном компьютере может нормально входить в систему без изменений?

Вопрос, который я выделил выше, показывает, что методы, которые я пытался заставить это работать. Независимо от того, какие заголовки запроса я пытаюсь установить, заголовки ответа всегда одинаковы с X-Frame-Options заголовком ответа, всегда установленным на SAMEORIGIN, что, опять же из того, что я понимаю , позволяет отправлять только ресурсы того же происхождения отправитель. Т.е. ресурсы, отправленные с smarkets.com, доступны только по запросам smarkets.com.

Моя текущая попытка запроса ( с httpie):

http POST https://api.smarkets.com/v3/sessions/ 'Access-Control-Request-Headers: Content-Type, Accept, Host, Origin' 'Access-Control-Request-Methods: POST, OPTIONS' 'Origin: https://smarkets.com' username=<username> password=<password> --print=Hh

Заголовки запроса и ответа:

Я действительно ищу;

• Ясность в том, что то же самое -оригинальная политика навязывает
• Почему этот запрос успешно выполняется на моем локальном компьютере, а не на удаленном блоке DO
• Как я могу получить этот запрос для выполнения?

Пользователь в Smarkets кажется, что это проблема того же происхождения, но это может быть не так.

РЕДАКТИРОВАТЬ:

Это не проблема брандмауэра, так как я отключил встроенную Ubuntu. в брандмауэре. Я делаю другие запросы через http (s) из того же источника, поэтому я не могу понять, что отличается от этого

РЕДАКТИРОВАТЬ 2:

Ниже Пример успешного заголовка запроса / ответа:

Я могу совершать другие вызовы API из одного и того же окна в разные источники, в том числе:

• https://api.betdaq.com
• https://api.betfair.com
• https://api.matchbook.com

Я не добавил никаких конфигураций специально для каких-либо происхождений на коробке так что я действительно не уверен, что это за проблема. Я добавил все возможные заголовки запросов CORS, о ​​которых я могу думать, но до сих пор не повезло.

РЕДАКТИРОВАТЬ 3:

К сожалению, это было исправлено, поскольку поставщики Черные списки API IP-адресов DigitalOcean по умолчанию ...

Answer 1

Cors - это и сервер, и клиент. Сервер определяет политику, клиент МОЖЕТ применять ее. Например, браузеры применяют его, потому что это более безопасно (не вдаваясь в детали). Поэтому отключение политики того же источника в вашем браузере или использование ненадежного браузера - это проблема безопасности.

Опять же, клиент МОЖЕТ применять политику. Насколько я знаю, большинство http-клиентов из командной строки не применяют его. Это может объяснить, почему ваш http ie запрос не завершился неудачей.

С точки зрения браузера вы не можете решить проблему. Опять же, именно сервер определяет политику. Что вы можете сделать, это создать прокси-сервер. Вы можете указать свою собственную политику в отношении Cors. Браузер делает запрос к вашему прокси-серверу. Ваш прокси-сервер передает запрос фактическому серверу.

Answer 2

Cors - более или менее всегда вещь на стороне сервера. Если поставщик выставляет некоторые API-интерфейсы на попадание, он должен убедиться, что cors отключен. Кроме разговоров с ними об этом, вы действительно ничего не можете сделать с вашей стороны. Отключение cors из chrome - плохая идея.