Мне не нужна ситуация, когда пользователь случайно или злонамеренно удаляет ресурсы других пользователей
Когда вы настраиваете S3 Bucket, вы настраиваете разрешения, которые есть у любого человека.ваши ресурсы ведра.Если я не ошибаюсь, по умолчанию все рассматривается как «личное».
Вам также необходимо настроить пользователя IAM и предоставить ему доступ (через Политика ) разрешить ему читать, а также записывать данные в ваше ведро.Если вы делаете это правильно, только этот user может сделать важную вещь: написать.Вся эта «запись» ресурса (создание / обновление / удаление) должна выполняться на вашем сервере от имени этого «пользователя IAM» с ключом пользователя / секретными учетными данными.
Это дает вам единственный способ внести изменения в ваш S3.При такой настройке ваши ресурсы защищены даже тогда, когда злонамеренные пользователи знают путь к вашей корзине, потому что эти пользователи будут иметь доступ только к «чтению».
Я рекомендую вам следовать этой статье (или этот один, в случае, если вы понимаете испанский) в качестве руководства по настройке вашей корзины S3.
В ответ на эту другую проблему:
Как я могу защитить ресурсы на S3, чтобы пользователь мог удалять только свои ресурсы, а не ресурсы любого другого пользователя?
Все эти операции должны выполняться в вашемсервер для обеспечения целостности / безопасности.Вашим пользователям не нужно иметь прямой доступ к вашим ресурсам, чтобы иметь возможность их изменять.
Возможно, ваш вопрос идет в этом направлении:
Что если пользователь тролляхочет изменить чужую фотографию профиля, если у системы есть конечная точка, которая выглядит следующим образом? :
POST /users/{id}/update-photo
В этом случае вы можете позволить злоумышленнику (скажем, пользователь id равно 10) чтобы иметь доступ к чужому ресурсу:
/**
* he/she could do this:
*/
POST /users/23/update-photo // <-- id=23
/**
* instead of:
*/
POST /users/10/update-photo // <-- id=10
Как этого избежать?с проверкой подлинности и «маскировкой маршрута».
/**
* Instead of this:
*/
POST /users/23/update-photo // <-- user id=23
/**
* Try this kind of endpoint:
*/
POST /profile/update-photo // <-- note that we disabled the ability to specify a user id
Как распознать пользователя?В случае API через токен, в случае веб-вызова через сеанс.В этом примере для идентификации пользователя вы делаете что-то вроде этого:
public function updatePhoto(Request $request)
{
$user = auth()->user(); // <-- now we ensure the user is id=10
// the rest of the code..
}
Конечно, я просто предполагаю, что это одна из ваших проблем, но это простой пример того, как этот вид проверки можетбыть реализован на стороне сервера для обеспечения защиты ваших ресурсов.