У меня есть REST API в Play 2.7.4. Существует SPA, вызывающий этот API как бэкэнд, и есть еще одна третья сторона, которая является для меня agnosti c, может быть API или, в худшем случае, некоторые сценарии с curl, но в любом случае они также вызывают некоторые конечные точки. Я использую глобальный фильтр CSRF, и некоторые PUT блокируются из-за CSRF.
Согласно документации
Чтобы обеспечить простую защиту для запросов, не связанных с браузером, Play проверяет запросы с помощью Приготовьте ie или заголовки авторизации по умолчанию. Вы можете настроить play.filters.csrf.header.protectHeaders, чтобы определить заголовки, которые должны присутствовать для выполнения проверки CSRF. Если вы делаете запросы с помощью AJAX, вы можете разместить токен CSRF на странице HTML, а затем добавить его в запрос с помощью заголовка Csrf-Token.
Что не понятно для меня - это поток, или, другими словами, где эта третья сторона собирается найти созданный мной токен csrf. Я не вижу этого ни в одном возвращаемом заголовке. Я мог бы добавить заголовок в свой GET с токеном CSRF, но я считаю, что это уже должно происходить. Если я использую токен из GET и добавляю его в заголовок для выполнения PUT, я получаю несоответствие токенов.
Если я попытаюсь использовать файлы cookie, я увижу заголовок Set-Cook ie с csrf cook ie в моем запросе GET, но затем, когда я пытаюсь использовать это в PUT, я получаю
p.filters.CSRF - [CSRF] Check failed because application/json for request
Вероятно, я просто не понимаю, как работает защита CSRF. И, насколько я понял, мой API все еще уязвим для него, потому что я использую как файлы cookie, так и заголовок авторизации, поэтому его отключение не является вариантом