У меня есть веб-приложение, которое подключается к AWS Cognito для аутентификации.В свою очередь, приложение использует лямбда-функцию для подключения к внешнему API.Приложение собирает информацию из этого API и сохраняет ее в таблице DynamodB для использования авторизованными пользователями Cognito.Ни в коем случае конечный пользователь не имеет доступа к токену, который соединяет их с внешним API.Это важно, потому что конечный пользователь может использовать этот токен злонамеренно и доставить мне неприятности с поставщиком API.По сути, мое приложение действует как буфер и агрегатор между конечным пользователем и внешним API.
Внешний API предоставляет URL-адреса файлов для прямой загрузки, которые требуют авторизации.Я хотел бы сделать их доступными для конечного пользователя.Как я уже говорил, я не хочу давать им прямую авторизацию, но вместо этого прокси-сервер запрашивает через лямбду, а затем перенаправляет его конечному пользователю.Вот где я застрял.
Очевидно, я мог бы загрузить файл, используя лямбду и S3, а затем, в свою очередь, сделать его доступным для конечного пользователя.Это не очень хорошее решение, поскольку для загрузки, сохранения и загрузки файла конечному пользователю требуется немало ресурсов.Кроме того, будет промежуток между временем, когда пользователь хочет получить файл, и временем, когда он был загружен на S3 и готов к загрузке пользователю.
Поток NodeJS вне функции AWS Lambda указывает, что лямбда-функции не поддерживают потоки Node в качестве ответов, так что идея как-то начать загрузку в лямбду и затем передавать поток не представляется осуществимой.Я не уверен, что это все равно имеет смысл.
Я не знаю, возможно ли для лямбды (или шлюза API) каким-либо образом вернуть перенаправление с авторизацией, встроенной таким образом, чтобы конец-user не имеет доступа к токену.Я даже не уверен, возможно ли то, что я пытаюсь сделать, но мне кажется, что это разумный вариант использования.Какие-нибудь мысли?Спасибо.