Нужно ли авторизовать заказчика через ту же форму входа, что и менеджеров с исполнителями?

Question

[personafour]

Добрый день! Занимаемся с другом написанием своей системы управления взаимоотношениями с клиентами (сугубо для приобретения опыта и навыков). Практически со старта уперлись в один момент который вызвал у нас немало споров. Позиция друга такова, что клиенту необходимо регистрироваться и авторизоваться наравне с другими пользователями через общую для всех форму входа/регистрации. Я же считаю, что более правильным будет не регистрировать клиента вообще, а лишь генерировать для него уникальный URL, при переходе по которому пользователь сможет увидеть лишь статус-отчет о своей задаче и иметь возможность добавить некий комментарий, который будет обрабатываться (в оптимальном случае) менеджером для исполнителя. Очень хотелось бы получить аргументированный ответ для любого из случаев. Небольшая подборка наших минусов и контраргументов:

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

В случае единой формы авторизации:
- У пользователей нет возможности сделать что-то сверх того, что определено в правах группы пользователей (если пользователь попал в единую систему для всех - ничто не мешает ему ее взломать "изнутри").
- Возможность взлома формы входа через (broot) bruteforce.

Answer 1

[maxaon]

- Возможность перейти в чужой заказ через подбор уникального постфикса в URL (использовать алгоритмы шифрования для генерации постфикса).

Тут лучше не используйте шифрование. Генерируйте токен случайно.

Невозможность проследить историю заказов

Можно, если ссылка с токеном будет являтся авторизационными данными.

Если пользователь, по каким-либо причинам, потерял ссылку на свой заказ - он не сможет получить доступ к его статусу и истории

Да, согласен.

У пользователей нет возможности сделать что-то сверх того

Натянуто. Система прав и корректно реализованная система ничем не отличается от токена, как я вас понял.

Возможность взлома формы входа через broot

Что такое "broot". Если вы имеете ввиду что это bruteforce, то ограничение на количество попыток входа от этого спасет, c нормальны паролем.

Но в общем, разделение такое:
ссылка с токеном - идентифицирует пользователя.
форма - аутентифицирует пользователя.

Если надо просто посмотреть статус, без каких-либо подробностей (в процессе, заявка принята и т.д.) то ссылка будет вполне уместным вариантом.
Если есть какие-либо подробности (имя заказчика, сумма сделки) или можно что-то сделать (сменить статус заявки) однозначно необходима аутентификация пользователя.
Если почта пользователя получена ранее, то вы можете просто упростить ему жизнь, выслав письмо-приглашение со ссылкой на регистрацию, где будет заполнено поле email и, например, номер договора, чтобы связать аккаунт пользователя и лицо, заключавшее договор.