Как защититься от разных URL запросов в Laravel?

Question

[bob_meister]

Здравствуйте. Изучаю создание сайта на Laravel.
Меня интересует такой вопрос:
Например я сделал на сайте возможность создания и удаления групп.
Есть route:

Route::get('/group/delete/{id}', 'App\Http\Controllers\GroupController@delete')->name('group-delete');

т.е. ссылка удаления выглядит так: www.site.ru/group/delete/2 <- ID группы.
И конечно же любой пользователь тупо введя любое ID может удалить любую группу. Конечно же я добавил в функцию delete проверку того, является ли авторизованный пользователь администратором группы.
Но, таких функций у меня полно, где надо проверять, админ ли пользователь и т.д. Меня интересует, есть ли какой-нибудь другой способ борьбы с этим. Например, чтобы в ссылке не было видно ID группы, а само ID отправлялось другим способом, не через URL, и чтобы запросы вида www.site.ru/group/delete/2 не работали. Спасибо.

Answer 1

[JhaoDa]

Во-первых, за удаление методом GET тебя ждёт спец. котёл в аду.

Во-вторых, читай документацию ларавел, про мидлвари и политики.

В-третьих, изучай основы HTTP, чтобы знать, как сделать

Например, чтобы в ссылке не было видно ID группы, а само ID отправлялось другим способом, не через URL, и чтобы запросы вида www.site.ru/group/delete/2 не работали.

Comments

[bob_meister]

Во-первых, за удаление методом GET тебя ждёт спец. котёл в аду.

Надеюсь они сделают исключение начинающему)

Спасибо за советы.

Answer 2

[Константин Б.]

Для глобальных проверок есть Middleware. Для более точных например на то что конкретный пользователь не может удалить конкретную группу есть Guards и Policies

Прятать ID из URI нет смысла, так как его все равно можно увидеть в теле запроса. Ну и да, удалять хотябы через POST метод, в идеале DELETE

В Laravel есть все на подобные задачи. Просто нужно сначала изучить фреймворк и язык

Answer 3

[Антон]

Про удаление и контроль прав написали уже, добавлю про "сокрытие" id в урлах - есть вот такой пакет https://github.com/cybercog/laravel-optimus для этой цели, но в общем и целом - это косметика

Answer 4

[pLavrenov]

При создании модели можно добавлять UUID и использовать его. Но отставить обычные ID для отношений, чтобы не захламлять БД.

Comments

[Антон Антон]

а чем первичный ключ в виде чего-нибудь типа time based uuid не нравится?

[pLavrenov]

Антон Антон, time based это всего лишь способ генерации UUID....

UUID это длинные строки, и при хранении отношений это все весит больше чем хранение id. Суть UUID это скрыть ID от пользователя больше в нем смысла нет.

[Антон Антон]

lavren, так ведь все равно придется его хранить. а для того,чтобы не получить фуллскан при операциях через него - еще и индексировать. Итого данных придется хранить больше.

[pLavrenov]

Антон Антон, больше - да, но не так много как если бы отношения хранились через uuid. Индексы простые, не составные. Строка существует в единственном экземпляре.