Я намагаюся створити лямбда-службу на AWS і отримати доступ до неї ззовні через шлюз API без автентифікації та обмежень.
Щоб полегшити ситуацію, я встановив, що шлюз наразі є макет.
У методі Get API API для авторизації встановлено значення, Noneа ключ API - not required.
Коли я спробую це, я отримую {"message":"Forbidden"}
(те саме повідомлення, якщо я підключаю його до власне лямбда-сервісу).
Будь-яка порада, як зробити це доступним?
[solved]до свого запитання. Дякую!
Відповіді:
Якщо ви встановите для параметра "Необхідний ключ API" значення true, перевірте нижче.
На інформаційній панелі шлюзу API виберіть Ресурси, клацніть Дії та виберіть Розгортання API. До вашого першого розгортання єдиною відповіддю, яку ви отримаєте, є {"message":"Forbidden"}.
Якщо ви використовуєте власне доменне ім’я та забудете вибрати інтерактивну проміжку призначення, ви отримаєте Forbiddenповідомлення.
Просто перейдіть Custom Domain Namesі натиснітьEdit вашого домену на ньому, а потім виберіть етап під Base Path Mappings.
Вам потрібно розгорнути свій api на сцені та використовувати url сцени, перейти до Ресурсів, клацнути Дії та вибрати Розгорнути API
Тепер, якщо ви отримуєте помилку
{"message": "Заборонено"}.
Будь ласка, перевірте наступні кроки
1) Якщо ви ввімкнете копіювання ключа api і передасте свій ключ поштарці
2) Тепер ви все ще отримуєте ту саму помилку, означає, що вам потрібно буде створити план використання
3) встановити ліміт і призначити план своєму API
У мене була подібна проблема, і у мене було таке:
Я також не встановлював авторизації та обмежень, щоб спростити ситуацію.
Я зміг усунути проблему, додавши відображення базового шляху для кожного з моїх етапів (розробник, інтерактивний, продуктовий).
Якщо ви встановили для ключа API API значення true, вам потрібно передати ключ api як заголовок.
Ключ API передається як поле заголовка 'x-api-key'. Навіть після додавання цього поля в заголовок ця проблема може виникнути. У цьому випадку, будь ласка, підтвердьте нижче пункти
Можливо, я запізнився, але одна з причин, через яку шлюз API видає "заборонене" повідомлення, полягає в тому, що ви передаєте дані в тілі запиту на операцію GET. Для вирішення проблеми або зробіть свій ресурс POST, або ви не передасте дані в тіло запиту.
GraphQL Query- що повернуло 403 заборонену помилку. Зміна типу запиту з GraphQL Queryна No Bodyзробило трюк!
Це може бути далеко не очевидно, але ще однією причиною появи помилки "Заборонено" під час використання шлюзу API AWS може бути виклик неправильної URL-адреси, яка не відповідає жодному розгорнутому методу API. Це може статися, якщо ви насправді натискаєте неправильну URL-адресу (наприклад, замість того, щоб дзвонити https://9999xx9x99.execute-api.us-east-1.amazonaws.com/dev/users( devстадія примітки раніше users), яку ви телефонували https://9999xx9x99.execute-api.us-east-1.amazonaws.com/users(без стадії). Ви очікували б отримати 404, але отримаєте 403.
ДО: після того, як ви здійсните розгортання для https://9999xx9x99.execute-api.us-east-1.amazonaws.com/dev/usersвиклику https://9999xx9x99.execute-api.us-east-1.amazonaws.com/user(тут зверніть увагу на форму однини іменника), ви також отримаєте ... 403, але з повідомленням "Відсутній маркер автентифікації"!
Якщо Authorizationі API KEY Requiredобидва встановлені істина для даного методу, то переконаєтеся , що ви такі заголовки при відправці запиту:
Я використовую POSTMANдля тестування API, яке є досить надійним, і тоді це досить приємно.
Примітка: Не додавайте заголовок клавіші x-api, якщо ви встановили API KEY REQUIREDяк FALSE. І якщо ви встановили AUTHORIZATIONяк FALSE, тоді не додайте заголовок Authorization.
Єдина інша причина, з якою я зіткнувся, але не бачу, що тут згадується, це буквально те, що ви намагалися зв’язатися з API занадто швидко після публікації. Я натиснув "Публікувати" і побачив доменне ім'я "ваш API доступний", і негайно скопіював і вставив його в Postman, щоб перевірити це.
Я отримую заборонене повідомлення. Нічого не міняйте. Перевірте всі налаштування, щоб переконатися, що я нічого не зробив - все правильно. Начебто вириваю моє волосся.
Поверніться через кілька хвилин, щоб спробувати, бо я впевнений, що все роблю правильно - це працює.
DNS людина. Яким би швидким не був Інтернет - це не миттєво :)
Я отримав цю помилку від служби nginx fargate, намагаючись отримати доступ до приватного API у шлюзі API. Мені потрібно було додати політику до політики ресурсів у моєму api, як це
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:us-east-1:<AccountID>:<RestApiID>/*",
"Condition": {
"StringEquals": {
"aws:sourceVpce": "<VPC Endpoint ID for execute-api>"
}
}
}
]
}
Є кілька речей, які потрібно зробити, коли ми отримуємо {message: заборонено} у шлюзі API:
CORS увімкнено?
Ключ API увімкнено?
Якщо ви все ще стикаєтесь із проблемами, повідомте мене, щоб я чи хтось із наших хмарних гуру @levarne міг допомогти.
Я міг натрапити на вирішення цієї проблеми. У мене була та сама проблема зараз на MacOS. Я спробував очистити свій DNS, і тоді це спрацювало!
Спробуйте це в терміналі:
Mac OS X Yosemite і пізніших версій
sudo killall -HUP mDNSResponder
Mac OS X Yosemite v10.10 - v10.10.3
sudo discoveryutil mdnsflushcache
Mac OS X Mavericks, Гірський Лев та Лев
sudo killall -HUP mDNSResponder
Mac OS X Snow Leopard
sudo dscacheutil -flushcache
Локальний брандмауер / антивірус або NGIPS ( Cisco Bluecoat ). Останнє було моїм випадком, коли я навіть не отримував журнали в CloudWatch зі свого API. Це дозволило розміщення мого веб-сайту, розміщеного на домені верхнього рівня, але блокувало apiпіддомен 403 , не маючи основного вмісту на вкладці інструментів розробника мережі.
Я потрапив {"message":"Forbidden"}в API, для EndpointConfiguration встановлений PRIVATE, і VpcEndpoint, створений для нього в приватних підмережах Vpc (це міжсервісний API)
Причиною цього {"message":"Forbidden"}стало те, що у мене склалося враження, що я повинен використовувати одну з URL-адрес VpcEndpoint. Використовувана URL-адреса все ще є тією, що пов'язана зі стадією (у консолі ApiGateway). Це є:
https://${RestApiId}.execute-api.${Region}.amazonaws.com/${StageName}
Ми зіткнулися з цією проблемою у своєму виробництві, коли використовували Kong як наш шлюз API. Наші запити передавались, коли їх ініціював Postman, але не вдалося виконати 403, коли було ініційовано через Код. Увімкнено плагін Bot у Kong, який дозволяв лише запити, ініційовані з браузера або мобільної програми на основі значення заголовка агента користувача. Наші запити, ініційовані за допомогою клієнта Http, не вдалося. Як тільки ми вимкнули плагін бота, помилка не сталася. Тепер він дозволяє запит, якщо агентом користувача є Apache-HttpClient / 4.5.2 (Java / 1.8.0_91).
Лише примітка щодо подібного випадку, з яким я зіткнувся з редактором Swagger:
403 Forbiddenразом з {"message":"Forbidden"}тілом.curl команда з редактора Swagger виглядала так:
curl -X GET "https://xxx52xxxx9.execute-api.eu-central-1.amazonaws.com//Prod/users" -H "accept: application/json"
(зверніть увагу на дубль //раніше Prod).
І та сама curlкоманда без //роботи через командний рядок!
Фокус, який спрацював, полягає в тому, щоб замінити цю serverструктуру, повернуту в згенерованому шлюзом API:
servers:
- url: "https://xxx52xxxx9.execute-api.eu-central-1.amazonaws.com/{basePath}"
variables:
basePath:
default: "/Prod"
З повним urlбез variables:
servers:
- url: "https://xxx52xxxx9.execute-api.eu-central-1.amazonaws.com/Prod"
Примітно, що видалення косої риски з default: "/Prod"не допомогло.
У моєму випадку ключ api не був увімкнений. Переконайтесь, що API встановлено як Увімкнено.
Як згадують @ gary69 та @Adriaan Pelzer
https://stackoverflow.com/a/52727654/809043
https://stackoverflow.com/a/55136675/809043
Ви можете отримати повідомлення {"message": "Forbidden"} під час запиту на приватний API.
Отже, якщо у вас є установка, де весь трафік повинен проходити ретельну кінцеву точку API, яка потім спрямовує трафік до шлюзу API, тоді можуть бути використані такі параметри.
APIGatewayVPCEndpoint:
Type: 'AWS::EC2::VPCEndpoint'
Properties:
PolicyDocument: '{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow",
"Principal": "*",
"Action":["execute-api:Invoke"],
"Resource":["arn:aws:execute-api:eu-north-1:000000000000:*/*"]
}]
}'
...
VpcEndpointType: Interface
PrivateDnsEnabled: true
Якщо увімкнено PrivateDnsEnabled, кінцева точка в Шлюзі API повинна мати тип Private, і потрібно додати політику.
ApiGatewayRest:
Type: AWS::ApiGateway::RestApi
Properties:
Description: A mocked API
Name: Mocked API
EndpointConfiguration:
Types:
- PRIVATE
Policy: '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": "*",
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:eu-north-1:000000000000:*/*/*/*"
}]
}'
Ця тема форуму допомогла мені з’ясувати деякі деталі
У мене була подібна проблема. Виявилося, що мій сертифікат у менеджері сертифікатів не був створений у регіоні Північна Вірджинія (США -схід-1 ), тому я не міг позначити власний домен як оптимізований Edge. Мені довелося вибрати регіональний.
Коли я повторно імпортував сертифікат, використовуючи регіон Північної Вірджинії, і знову створив власний домен, але цього разу з оптимізованою Edge конфігурацією кінцевої точки, він працював бездоганно.