- 1
- 2
- 3
- 4
function checkPermission(user, post) {
return equals(post.author, user) ||
user.role = 'admin';
}
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+7
function checkPermission(user, post) {
return equals(post.author, user) ||
user.role = 'admin';
}
when you see it, you'll shit bricks
может по этому role потом клиент принимает решение показывать или нет тыцки "редактировать", "удалить" и т.д.?
всё равно по ним должен уйти post на бек, который есесно сам проверит разрешения на эти операции, и даст по рукам 403
а вдруг они все сделали правильно и у них код реюзается?)
если говорить конкретно про указанные 3 строчки и закрывающую скобку, то я вижу другие проблемы - должны быть права доступа (а-ля "read", "edit", "delete" и т.д.), а не bool результат, роль это лишь мета сущность аггрегации прав
найдите синтаксическую ошибку называется, я то думал
а какой приоритет операций в js?
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence
ты типа намекаешь что должно быть синтаксической ошибкой?
я тоже по современному JS не спец.
Фишка в другом, если это фронтед и без проверки на бекенде - любой школьник присвоит user.role = 'админ'.
Ну и что за вотзефак equals
>> ты пропустил строку 3? где пользователям раздаётся роль админа?
= вместо ==
про любой школьник я уже написал в самом верхнем посте
клиент может дрочить всё что угодно, у него есть f12 и анонимные прокси
хоть вообще через фиддлер ресты вызывать руками, на беке ты обязан проверять всё
хуярить верификацию прав на клиенте может себе позволить только kerman
шта за kerman ?
алсо, условие вывалится с ексепшеном.
BTW, проверка прав на клиенте - это один из основных недостатков всех двузвенных решений. Такое получается по причине наличия бизнес-логики в тушке толстого клиента и неотделимости проверки прав от логики.