Конфигурирайте контейнера на GCS, за да разрешите публичен запис, но не и презаписване

В Google Cloud Storage искам PUBLIC (allUsers) да може да качва нови файлове и да изтегля съществуващи файлове, но не искам PUBLIC да може да презаписва съществуващ файл.

Предистория: URL адресите за качване и изтегляне обикновено се определят от собственото ми приложение. Така че при нормални условия няма проблем, защото приложението гарантира, че URL адресите винаги са уникални при писане. Но злонамерен потребител може да хакне приложението ми и след това евентуално да може да качва файлове (лошо) в облачното ми хранилище и да презапише съществуващите файлове (много лошо).

Знам, че мога да разреша този проблем чрез прокси чрез App Engine или чрез използване на подписани URL адреси, което се опитвам да избегна поради времеви ограничения. Навременната обработка е от съществено значение, тъй като приложението ми обработва файлове (почти) в реално време и допълнително забавяне от само 1000 msec за обработка на две последователни заявки би било твърде дълго.

Възможно ли е да конфигурирате облачно хранилище по начин, по който да се връща грешка в случай, че вече съществуващ файл бъде ударен по време на качване, като например:

Кофа: PUBLIC има достъп WRITE Индивидуален файл: PUBLIC има достъп READ

Щеше ли да работи? Какво се случва в GCS, ако ACL на кофа и файл си противоречат? В горния пример кофата би позволила достъп за запис, но ако качването удари вече съществуващ файл с достъп само за четене, дали такава заявка ще бъде уважена от GCS или GCS ще счита файла за вече несъществуващ в този момент и ще го замени с ново съдържание ?

Всеки друг подход, който може да работи, ще бъде много оценен.


person Oliver Hausler    schedule 17.08.2014    source източник
comment
Въпросът с времето е интересен. Ще бъде ли възможно вашият сървър да раздаде няколко подписани URL адреса, преди да са необходими?   -  person Brandon Yarbrough    schedule 18.08.2014
comment
Да, @Brandon, благодаря ти за идеята. И аз съм мислил за това и ако не се появи нещо друго, вероятно ще използвам този маршрут.   -  person Oliver Hausler    schedule 20.08.2014
comment
Най-накрая се съгласих с вашето предложение за запазване на множество подписани URL адреси предварително. Работи добре въпреки доста голямото натоварване на процесора за подписване, но досега това наистина изглежда единственото жизнеспособно решение. [За да съберете вашите кредити @BrandonYarbrough, публикувайте отговор, за да мога да го потвърдя като правилен.]   -  person Oliver Hausler    schedule 30.11.2014


Отговори (1)


Искате да зададете тези IAM роли в кофата:

  • роли/storage.objectCreator
  • роли/storage.objectViewer

https://cloud.google.com/storage/docs/access-control/iam-roles гласи:

"objectCreator позволява на потребителите да създават обекти. Не дава разрешение за преглед, изтриване или презаписване на обекти."

person Frank Farzan    schedule 06.02.2019