Доступ к произвольному объекту S3 с использованием усиления-угла - PullRequest
Новая
       5

Доступ к произвольному объекту S3 с использованием усиления-угла

0 голосов
/ 29 июня 2018

Я настроил усиление-angular и работаю для аутентификации и доступа к API. Используя Angular 5.

Могу ли я получить доступ к частным ресурсам S3 и использовать ту же аутентификацию, что и при доступе к API?

В частности, я хотел бы сделать запрос REST GET для объекта S3, например: https://s3.amazonaws.com/my-bucket-name/my-private-file.dat

Подпись AWS должна быть включена в качестве заголовка авторизации, чтобы это работало. (при условии, что у пользователя есть разрешение)

Возможные варианты:

  • Класс RestClient : Кажется, он делает то, что я хочу, но я не думаю, что он экспортируется или доступен для использования моим кодом приложения
  • API: Могу ли я определить другой API в моей конфигурации усиления как https://s3.amazonaws.com? Я не уверен, какие побочные эффекты связаны с обработкой этого, как экземпляра шлюза API, а не ... как бы то ни было.

Я не могу поставить конечную точку API перед доступом S3; списки ACL будет проще проверять на основе прямого доступа S3, поскольку они имеют отдельные ACL для каждого объекта.

Модуль «Хранилище» не подходит. Это, кажется, работает только для заранее определенного ведра. Мои шаблоны доступа могут обращаться к любому количеству сегментов, которые не известны до времени выполнения.

Ответы [ 2 ]

0 голосов
/ 23 марта 2019

Там также будет возможность использовать <amplify-s3-image> компонент. 

<amplify-s3-image [path]="mainImage?.key" [options]="{customPrefix: {public: ''}}">
</amplify-s3-image>

MainImage-Object был загружен с помощью графика усиления и выглядит следующим образом: 

"mainImage": {
    "bucket": "bucketname",
    "region": "eu-central-1",
    "key": "public/b369e63d-1a40-4793-ae49-cecde042b1b9.jpg",
    "__typename": "S3Object"
  },

Я не могу найти какую-либо документацию для этого, поэтому вот ссылка на код на github .

0 голосов
/ 10 июля 2018

Я смог использовать модуль Storage, но это взлом. 

const storage = this.amplifyService.storage();

const storageOptions = { 
  bucket: 'any-bucket',
  // see https://github.com/aws/aws-amplify/blob/master/packages/aws-amplify/src/Storage/Storage.ts#L325
  // public appears to be the only option that doesn't append hardcoded values
  customPrefix: { 
    public: ''
  },
  level: 'public' 
};

storage.get( 'objectIdWithinBucket', storageOptions ).then( 
  data => {
    console.log( "A signed URL is returned that can be used to access the object");
    console.log( data );
  },
  error => {
    console.log( "Boo. Err. ", error );
  }
)

Почему это работает: пользовательский префикс и открытый уровень переопределяют параметры s3 по умолчанию. Ресурс на самом деле не является общедоступным, но любой другой параметр добавляет косые черты и дополнительные символы, которые не принадлежат.

Модуль хранения (на мой взгляд) является примером плохого проектирования API: они предоставляют значения, основанные на ожидаемом сценарии использования, который не документирован. Возможность их переопределить не документирована нигде, которую я могу найти. Пример: если вы не укажете «уровень», он добавит «public» в качестве префикса к идентификатору объекта.

Более того, модуль Storage предполагает, что вошедшие в систему пользователи хранят объекты в одной корзине с известным соглашением об именах. Изменить их сложно.

Предупреждение: переопределение может назначить переданные параметры в _options по умолчанию. Это может произойти в https://github.com/aws/aws-amplify/blob/240e50b61f50eaf3712bfbc088d1b096360b401c/packages/aws-amplify/src/Storage/Storage.ts#L86 (снимок самого последнего коммита на момент написания)

...