Профиль пользователя / URL-адреса учетной записи

Я должен предоставить пользователям и администраторам функции по редактированию данных учетной записи и профиля в веб-приложении. Пример URL общедоступной части этих профилей:

http://example.com/user/joe

Я все еще разрываюсь между двумя способами создания этих URL-адресов. Я думал об этом:

http://example.com/user/joe/edit

Или что-то неспецифическое и отдельное для профилей:

http://example.com/account

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

Второй - более стандартный способ работы, он оказался бы проще и безопаснее, хотя это означает отдельный интерфейс для административных пользователей.

Что по этому поводу думает SO? Есть ли еще какие-нибудь плюсы / минусы в любом случае? Какой метод вы бы порекомендовали использовать?


url web-applications profile
person Community    schedule 28.09.2009    source источник
comment
Почему администратору должно быть разрешено изменять чужой профиль?   -  person Gumbo    schedule 28.09.2009
comment
@Gumbo из-за возможного спама на полях? Чтобы удалить аккаунт, если это бот?   -  person Daniel Sorichetti    schedule 29.09.2009

Ответы (4)


arrow_upward
1
arrow_downward

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

Это делает авторизацию намного более понятной, даже если два представления имеют общую форму редактирования.

person dove    schedule 28.09.2009

arrow_upward
1
arrow_downward

Если вы используете подход MVC, я предлагаю следующее:

http://example.com/user/edit/1234

or

http://example.com/user/edit/joe

Если пользователь является контроллером, отредактируйте метод контроллера и 1234 или joe идентификатор пользователя или имя пользователя соответственно.

Но, как прокомментировал Гамбо, администраторам нельзя разрешать редактировать информацию о пользователях. У них должен быть какой-то механизм для отключения учетной записи в случае, если в профиле есть оскорбительный контент или ложная информация. Принуждение пользователя к обновлению, чтобы учетная запись снова стала активной.

person rogeriopvl    schedule 28.09.2009

arrow_upward
0
arrow_downward

Мы делаем это так, что администратор и пользователь разделяют одно и то же представление. Элементы, предназначенные только для администратора, защищены от редактирования или просмотра пользователем.

Причина единого просмотра:

  • Это уменьшает количество «движущихся частей» - когда новое поле добавляется на экран пользователя, его нужно добавить только один раз,
  • Легче перемещать элементы в / из поля зрения пользователя. Если вдруг руководство решает разрешить пользователю управлять своим «FizzBar», нам нужно внести изменения только в одном месте, и
  • На уровне контроллера легче разделить роли и функции.
person BryanH    schedule 28.09.2009

arrow_upward
0
arrow_downward

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

person Daniel Sorichetti    schedule 28.09.2009