Как получить информацию о пользователе после проверки REST на стороне клиента?

У меня есть Spring REST backend и Angular frontend.Как получить информацию о пользователе после проверки REST на стороне клиента?

Аутентификация выполняется с использованием запроса POST для URL «/ login» с именем пользователя и паролем внутри запроса. Тело JSON (я использую проверку на основе форм). Ответы бэкэнда REST с кодом ОК. Все в порядке, и я могу выполнять другие запросы из интерфейса, требующие аутентификации.

Но интерфейс должен знать, какова роль аутентифицированного пользователя, чтобы он мог отображать правильный вид/rote для него. И где мы можем получить эту роль в интерфейсе? Единственный ответ, который мы получили от аутентификации, был в порядке, и это нормально для REST.

Мы можем получить информацию о пользователе, выполнив запрос GET на «/ users/[user_id]». Но у нас нет идентификатора пользователя, просто имя пользователя.

Итак, вопрос: Какой правильный способ для REST получить роль (или другую пользовательскую информацию) из интерфейса, имеющего только имя пользователя?

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

источник

2016-10-29 nickolay.laptev

Если ваш сервер требует передачи идентификатора пользователя, чтобы получить текущую информацию пользователя, но не позволяет получить идентификатор пользователя, тогда у бэкэнд проблемы с серьезными проблемами. Кажется, вы можете отправить запрос, требующий аутентификации. Это означает, что бэкенд способен определить, кто вы (возможно, благодаря файлу cookie). Если это правда, вам не нужно передавать что-либо в качестве параметра, поскольку оно неявно передается в cookie. У вас может быть только ресурс/текущий пользователь. –

И бэкэнд, и интерфейс находятся в разработке мной. Каков правильный способ для бэкэнд предоставлять информацию о пользователе после REST? –

Я только что сказал. Предполагая, что бэкэнд имеет неявный способ идентификации запросов (например, с помощью файла cookie), вы можете просто указать/current-user, или a/me или все, что вы хотите назвать им, ресурсом. Например, https://developer.github.com/v3/users/#get-the-authenticated-user. –

После обсуждения вопроса с @JBNizet в комментариях я решил изменить конечную точку REST с "/ users /: user_id" на "/ users /: user_name".

источник

2016-10-31 15:31:00

Вы не можете переопределить HTTP-методы. Если вы планируете писать GET-вызов с разными параметрами запроса с тем же путем, тогда это не разрешено. Вам нужно написать два пути GET.

например.

GET/пользователей/идентификатор/{идентификатор} GET/пользователи/имя пользователя/{имя}

А во втором вызове, вы можете добавить нужную логику для получения роли во втором.

источник

2016-10-29 16:45:28 Sakalya

Но с точки зрения REST я не уверен, что это правильно. Что означает «DELETE/users/username»? –

Если вы не хотите разрешать DELETE, не записывайте реализацию для вызова DELETE. Это вполне приемлемо в соответствии со стандартом REST. – Sakalya

Есть два способа сделать это.

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

2) Когда вы проверяете подлинность пользователя, если пользователь действителен, вы можете получить его данные и сохранить их в объекте.

Теперь в вашей логике сервера при возвращении ответа вы можете сделать как ниже

response.setHeaders("User",userDetilsObj);

ПРИМЕЧАНИЕ: реакция является объектом HttpServletResponse.

После выполнения запроса, как вы сказали, что мы получим статус OK ответ, который 200. Для того, чтобы получить доступ к деталям пользователей на JS стороне следует ниже код

if(response.status == '200/OK'){ 
    $rootScope.user = response.getHeaders().User;//In this object all the user details set at server side are available now.. 
}

Надеется, что это дает некоторый свет о том, как достичь желаемых результатов.

источник

2016-10-30 05:45:44

Спасибо. Эти два способа выглядят очень похожими на обходные пути, о которых я упоминал в вопросе. И вопрос в другом. JB Nizet отметил, что замена «/ users /: id» на конечную точку «/ users /: name» в порядке с точки зрения дизайна, так что отвечает на мой вопрос. –

согласен, но вы спросили, что лучше сделать, поэтому я бы предложил пойти на первый подход, который является более чистым и удобным для обслуживания. –

Использование «/ users /: name» не является более чистым подходом, поскольку идентификатор - это то, что останется навсегда. Постоянное имя может быть изменено или оно может быть чувствительным к регистру, что снова требует преобразования, если у вас больше пользователей с таким же именем? Как вы решите, какой из них вошел в систему? –

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

источник

2016-10-31 11:21:36 Ajit

Как получить информацию о пользователе после проверки REST на стороне клиента?

ответ

Смежные вопросы