Как правильно реализовать «введите пароль еще раз для продолжения» для критических действий в REST

#rest #django-rest-framework #api-design

#rest #django-rest-framework #api-дизайн

Вопрос:

Как следует из названия, я пытаюсь реализовать механизм, retyping the password again прежде чем приступить к каким-либо критическим действиям, например, изменить адрес электронной почты, деактивировать учетную запись, пригласить нового пользователя и т.д.

Проблема в том, что я не понимаю, как это должно быть сделано в мире REST.

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

Или это должно быть сделано в одном запросе с указанием пароля и на основе проверки пароля действие будет продолжено или отклонено?

Или это должно быть что-то другое?

Заранее спасибо за вашу помощь, я действительно ценю это.

Примечание: я использую DRF, поэтому я добавил этот тег к вопросу, но поскольку это общий вопрос

Комментарии:

1. Самый простой способ на сегодняшний день — просто вернуть представление, которое вежливо просит пользователя повторно ввести свои учетные данные через представление на основе форм, такое как HTML или hal forms, и сохранить ранее введенные данные во временном ресурсе. После повторной проверки учетных данных вы можете безопасно обрабатывать фактические данные в соответствии с вашими потребностями. Так работает Веб, и так же должен работать REST ootb.

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

3. Например, при смене пароля старый пароль вместе с новым паролем предоставляются в одном запросе, должен ли я сделать то же самое для других вещей? или лучше разделить на два этапа? сначала введите пароль, получите токен diifrent, присоедините к нему защищенный ресурс?