Хорошо, так что я довольно новичок в веб-разработке, но я освоил js / html / css и работаю над игрой / веб-сайтом. Я в основном закончил свою работу, но я не уверен, что мне следует делать сейчас

То, что я хочу сделать, это использовать тот же интерфейс администратора, который у меня есть, с некоторыми ограничениями для пользователя / игрока. Например, представьте, что «администратор» может добавлять материалы на сайт и перемещать их и тому подобное, в то время как игрок может только просматривать и использовать их, не имея возможности редактировать их или добавлять новые элементы в представление.

Кроме того, я использую один и тот же интерфейс для многих HTML-страниц, и поэтому я чувствую, что должен спросить об этом.

Должен ли я клонировать текущие классы и удалить некоторые ненужные вещи или просто скрыть элементы с помощью css и html?

PS: сайт довольно большой, есть много классов, поэтому я колеблюсь.

Я не знаю, должен ли я предоставить какой-либо код, но пример моего вопроса:

Классы клонирования - класс "viewer" для администратора и класс "limitedViewer" для игрока

Скрытие элементов - просто используйте "display: none" <- это не работает с некоторыми элементами, поскольку они отображаются только тогда, когда происходят некоторые взаимодействия, и я хочу, чтобы указанные взаимодействия были доступны игроку

0
Lrdox 26 Июл 2019 в 11:24

2 ответа

Лучший ответ

Действительно легко переписать некоторые классы в инструменте разработчика, чтобы получить доступ к функциональности администратора, не имея надлежащих прав. Если вас беспокоит безопасность, вам определенно не следует прятать админ-панели с помощью простого «display: none».

Я бы сделал так, чтобы у меня была определенная страница администратора, доступ к которой можно получить только при наличии правильных учетных данных. Однако для этого требуется, чтобы у вас была надлежащая система авторизации.

Я понимаю, что это решение не очень полезно, если вам нужны дополнительные кнопки для администраторов. Чтобы пользователи не могли щелкнуть что-то, что им не следует (потому что они запутались в инструментах разработки), вы также должны найти способ проверить учетные данные после нажатия кнопки. В этом случае, даже если пользователь каким-то образом может отобразить кнопку и щелкнуть ее, он не сможет ее использовать.

Другой вариант заключается в том, чтобы JS генерировал кнопки, и в этом фрагменте кода проверьте учетные данные, чтобы сгенерировать кнопки в соответствии с ролью пользователя. Это немного сложнее «взломать», так как вы не можете просто переключить класс или свойство CSS в инструменте dev. Конечно, вы все равно должны проверить учетные данные в обработчике кнопки.

Просто помните, что скрытие определенных элементов HTML не является хорошим способом защитить их. Вам необходимо проверять учетные данные пользователя на каждом этапе, включая обработку.

1
Smallwater 26 Июл 2019 в 08:38

Для пользовательского интерфейса любой метод подходит. Все, что имеет значение, - то, что администраторы получают доступ к некоторым страницам, которые не администраторы не могут видеть. Любой механизм, который вы разрабатываете для достижения этого, действителен.

Теперь есть еще одна очень важная часть веб-разработки, о которой вы не спросили: авторизация . Для авторизации недостаточно CSS . Вы должны предположить, что пользователи имеют и знают, как использовать почтальона или curl или Chrome / Edge / Safari / Консоль разработчика Firefox. Это правильное предположение, потому что это общие инструменты в веб-разработке, и большинство (не очень большое, но все же много) ваших пользователей, вероятно, будут веб-разработчиками.

Вы должны сделать невозможным для не администраторов вызывать функции, к которым имеют доступ только администраторы.

Есть несколько механизмов, чтобы сделать это, и большинство методов, которые считаются лучшими, не требуют дублирования классов. Они обычно включают роль пользователя или механизм разрешения.

Самая простая реализация - это функция, которая проверяет, есть ли у пользователя разрешение на доступ к странице, и вы вызываете эту функцию в качестве первого элемента вашего контроллера. В зависимости от вашей среды вы также можете использовать промежуточное программное обеспечение для этого, поскольку роль пользователя / разрешение / авторизация является сквозной задачей. Некоторые языки могут использовать аннотации / шаблоны / макросы для пометки страниц с разрешениями.

Какой бы механизм вы ни внедрили, это должно быть сделано на сервере, потому что пользователь всегда может сделать:

curl http://your.website/some/admin/endpoint/to/restart/server

.. для доступа к странице (или введите ее прямо в браузере). Иногда вам нужно будет реализовать некоторую причудливую проверку или скрытие в интерфейсе для более удобного пользовательского интерфейса. Все нормально. Но это не означает, что вам не нужно также реализовывать надлежащие механизмы авторизации в бэкэнде.

1
slebetman 26 Июл 2019 в 08:57