Сообщение Re: Swashbuckle - пример кастомной формы типа авторизации от 04.09.2020 9:25
Изменено 04.09.2020 9:28 bnk
Re: Swashbuckle - пример кастомной формы типа авторизации
Здравствуйте, Shmj, Вы писали:
S>Вопрос такой.
S>Хотелось бы передавать в HTTP-заголовках, чтобы не засорять методы:
S>1. Если авторизован — то данные авторизации (ID-клиента и ключ).
S>2. Если не авторизован — то предпочтения (язык, часовой пояс и т.д.).
Обычно, чтобы не париться, делается так называемая "анонимная авторизация", когда пользователь всегда аутентифицирован.
Просто некоторые пользователи имеют "анонимный" ID (просто ключ типа guid), и не имеют почты, имени, ну и т.д.
Также это решает проблему с тем, если пользователь таки решит зарегистрироваться — его профиль с данными уже есть,
просто нужно будет привязать к нему имя пользователя и почту.
В результате в запросе просто всегда имеешь "аутентифицированного" пользователя.
S>Вопрос такой.
S>Хотелось бы передавать в HTTP-заголовках, чтобы не засорять методы:
S>1. Если авторизован — то данные авторизации (ID-клиента и ключ).
S>2. Если не авторизован — то предпочтения (язык, часовой пояс и т.д.).
Обычно, чтобы не париться, делается так называемая "анонимная авторизация", когда пользователь всегда аутентифицирован.
Просто некоторые пользователи имеют "анонимный" ID (просто ключ типа guid), и не имеют почты, имени, ну и т.д.
Также это решает проблему с тем, если пользователь таки решит зарегистрироваться — его профиль с данными уже есть,
просто нужно будет привязать к нему имя пользователя и почту.
В результате в запросе просто всегда имеешь "аутентифицированного" пользователя.
Re: Swashbuckle - пример кастомной формы типа авторизации
Здравствуйте, Shmj, Вы писали:
S>Вопрос такой.
S>Хотелось бы передавать в HTTP-заголовках, чтобы не засорять методы:
S>1. Если авторизован — то данные авторизации (ID-клиента и ключ).
S>2. Если не авторизован — то предпочтения (язык, часовой пояс и т.д.).
Обычно, в этом случае, чтобы не париться, делается так называемая "анонимная авторизация", когда пользователь всегда аутентифицирован.
Просто некоторые пользователи имеют "анонимный" ID (просто ключ типа guid), и не имеют почты, имени, ну и т.д.
Также это решает проблему с тем, если пользователь таки решит зарегистрироваться — его профиль с данными уже есть,
просто нужно будет привязать к нему имя пользователя и почту.
В результате в запросе просто всегда имеешь "аутентифицированного" пользователя.
S>Вопрос такой.
S>Хотелось бы передавать в HTTP-заголовках, чтобы не засорять методы:
S>1. Если авторизован — то данные авторизации (ID-клиента и ключ).
S>2. Если не авторизован — то предпочтения (язык, часовой пояс и т.д.).
Обычно, в этом случае, чтобы не париться, делается так называемая "анонимная авторизация", когда пользователь всегда аутентифицирован.
Просто некоторые пользователи имеют "анонимный" ID (просто ключ типа guid), и не имеют почты, имени, ну и т.д.
Также это решает проблему с тем, если пользователь таки решит зарегистрироваться — его профиль с данными уже есть,
просто нужно будет привязать к нему имя пользователя и почту.
В результате в запросе просто всегда имеешь "аутентифицированного" пользователя.