Здравствуйте и спасибо за помощь,
Я использую php-sdk для метода вызова лямбды aws БЕЗ использования API.
Я следую за документами по этому https://docs.aws.amazon.com/aws-sdk-php/v2/api/class-Aws.Lambda.LambdaClient.html#_invoke
Что странно, так это то, что я использую класс SNS со своим внешним файлом учетных данных, расположенным в ~ / .aws / credentials и ~ / .aws / config, и он работает нормально, поэтому я не думаю, что это проблема с учетными данными, хотя я могу ошибаться ,
Мой код:
$client = LambdaClient::factory([
'version' => 'latest',
'key' => $f_key,
'secret' => $f_secret,
'region' => 'us-east-1'
]);
$result = $client->invoke(array(
'FunctionName' => 'MY_FUNC',
// NOT SET AWS SAYS IT DEFAULTS
// 'InvocationType' => 'string',
// 'LogType' => 'string',
// 'Qualifier' => 'string',
'ClientContext' => '
'ClientContext' => '{
"id": 1006410,
"title": "LAMBDA TEST"}',
',
'Payload' => 'mixed type: string|resource|\Guzzle\Http\EntityBodyInterface',
));
Ошибка, которую я получаю:
PHP Fatal error: Uncaught exception 'Aws\Lambda\Exception\LambdaException' with message 'Error executing "Invoke" on "https://lambda.us-east-1.amazonaws.com/2015-03-31/ARN_REMOVED/invocations"; AWS HTTP error: Client error: `POST https://lambda.us-east-1.amazonaws.com/2015-03-31/functions/ARN_REMOVED/invocations` resulted in a `403 Forbidden` response:
{"message":"The request signature we calculated does not match the signature you provided. Check your AWS Secret Access (truncated...)
InvalidSignatureException (client): The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details. - {"message":"The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for in /home/USER/Documents/symphonic/SMS-v1/vendor/aws/aws-sdk-php/src/WrappedHttpHandler.php on line 191
Этот PHP SDK ожидает необязательный ClientContext
быть объектом JSON в кодировке base64, а не массивом.
ClientContext => (string)
Используя ClientContext, вы можете передавать специфичную для клиента информацию в функцию Lambda, которую вы вызываете. Затем вы можете обрабатывать информацию о клиенте в вашей лямбда-функции по своему усмотрению через контекстную переменную. Для примера JSON ClientContext перейдите к PutEvents в Справочнике по API Amazon Mobile Analytics и Руководстве пользователя.
ClientContext JSON должен быть в кодировке base64.
https://docs.aws.amazon.com/aws-sdk-php/v2/api/class-Aws.Lambda.LambdaClient.html#_invoke
Предположительно, ошибка подписи является следствием несоответствия между двумя частями внутренних компонентов: способ, которым SDK обрабатывает неверный тип аргумента при генерации подписи, и способ, которым он обрабатывает его при генерации фактического запроса. Похоже, ошибка SDK, что неверный аргумент тип полностью обрабатывается до момента отправки запроса в API, что приводит к неопределенной ошибке.
Однако API сервиса не виноват.
Когда запросы поступают в AWS, некоторые вещи происходят очень быстро и всегда в одном и том же порядке. Первый сбой приводит к сбою всего запроса.
Первым делом проверяется, истек ли срок подписи явным или Date
или же x-amz-date
значение слишком искажено.
Далее AWSAccessKeyId
или же X-Amz-Credential
проверяется на достоверность (и объем, в последнем случае).
Затем подпись проверяется, чтобы удостовериться, что она была подписана с правильным соответствующим секретным ключом, и не была подделана с момента ее подписания. Предполагая, что запрос не был поврежден во время полета или подделан, есть две причины, которые могут вызвать это: неверный секретный ключ доступа или ошибка в коде, который подписал запрос … следовательно, сообщение об ошибке:
Проверьте свой секретный ключ доступа AWS и метод подписи
Причина, по которой сообщение является расплывчатым, заключается в том, что один механизм безопасности, который используют алгоритмы подписывания запросов (HMAC-SHA), делает невозможным различие между двумя условиями (недопустимый секретный ключ и ошибка). Каждый запрос Signature V4 имеет ровно 1 возможную действительную подпись и 16 ^ 64 — 1 другую возможную подпись, причем все они одинаково неверны и не содержат никакой информации о причине несоответствия подписи. (Число меньше для Signature V2, но не так существенно, для этого обсуждения.) Крошечные ошибки бросают весь алгоритм в неузнаваемый хаос, который является неотъемлемой частью безопасности.
Только после завершения этих шагов запрос оценивается на синтаксис и структуру, проверяются разрешения и продолжается обработка остальной части запроса, поэтому более полезная ошибка не так уж и практична.
Других решений пока нет …