Здравствуйте, Shmj, Вы писали:
НС>>Дублировать ничего не надо, это в хидере передается. S>Где написать, чтобы в каждом из 100 методов появился такой параметр?
Ну ты уже совсем обленился. Ни вопрос нормально задать, ни погуглить.
private class AddAccessToken : IOperationFilter
{
public void Apply(Operation operation, SchemaRegistry schemaRegistry, ApiDescription apiDescription)
{
var descriptor = (ReflectedHttpActionDescriptor)apiDescription.ActionDescriptor;
var actionAttributes =
descriptor.MethodInfo.GetCustomAttributes(typeof(AuthScopeAttribute), true).OfType<AuthScopeAttribute>();
var controllerAttributes =
descriptor.ControllerDescriptor.GetCustomAttributes<AuthScopeAttribute>(true).OfType<AuthScopeAttribute>();
if (actionAttributes.All(a => a.AuthorizationType == AuthorizationType.None)
&& controllerAttributes.All(a => a.AuthorizationType == AuthorizationType.None))
return;
if (operation.parameters == null)
operation.parameters = new List<Parameter>();
operation.parameters.Add(
new Parameter
{
description = "Access token",
@in = "header",
name = "Authorization",
required = true,
type = "string"
});
}
}
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Swashbuckle - пример кастомной формы типа авторизации
Хотелось бы передавать в HTTP-заголовках, чтобы не засорять методы:
1. Если авторизован — то данные авторизации (ID-клиента и ключ).
2. Если не авторизован — то предпочтения (язык, часовой пояс и т.д.).
Не знаю хорошая ли идея, но если сервисом могут работать как авторизованные так и не авторизованные — то по идее так (не передавать же в каждый метод предпочтения, тем более они не нужны для авторизованных — их предпочтения берутся из базы).
А так же как-то это совместить с Swashbuckle — т.е. чтобы была форма авторизации, но с возможностью просто указать предпочтения без ID-клиента/ключа.
Вопросы:
1. Хорошая ли идея так расширить форму авторизации?
2. Попадался ли вам пример подобной формы, чтобы не писать все с нуля?
Re: Swashbuckle - пример кастомной формы типа авторизации
Здравствуйте, Shmj, Вы писали:
S>Вопрос такой.
S>Хотелось бы передавать в HTTP-заголовках, чтобы не засорять методы:
S>1. Если авторизован — то данные авторизации (ID-клиента и ключ). S>2. Если не авторизован — то предпочтения (язык, часовой пояс и т.д.).
Обычно, в этом случае, чтобы не париться, делается так называемая "анонимная авторизация", когда пользователь всегда аутентифицирован.
Просто некоторые пользователи имеют "анонимный" ID (просто ключ типа guid), и не имеют почты, имени, ну и т.д., но имеют профиль.
Также это решает проблему с тем, если пользователь таки решит зарегистрироваться — его профиль с данными уже есть,
просто нужно будет привязать к нему имя пользователя и почту.
В результате в запросе просто всегда имеешь "аутентифицированного" пользователя.
Здравствуйте, Shmj, Вы писали:
S>А так же как-то это совместить с Swashbuckle — т.е. чтобы была форма авторизации, но с возможностью просто указать предпочтения без ID-клиента/ключа.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>OAuth2 swashbuckle поддерживает искаропки.
Емнип, OAuth2 перенаправляет на URL с формой авторизации, после чего редиректит назад с ключом, который нужно проверить. А хотелось бы просто задать HTTP-Header-ы без всяких перенаправлений.
Re[3]: Swashbuckle - пример кастомной формы типа авторизации
Здравствуйте, Shmj, Вы писали:
S>Емнип, OAuth2 перенаправляет на URL с формой авторизации,
Только для auth code flow. И это правильно с точки зрения безопасности.
А есть еще, как минимум implicit, client и resource owner.
S> после чего редиректит назад с ключом, который нужно проверить. А хотелось бы просто задать HTTP-Header-ы без всяких перенаправлений.
Так нет же никаких проблем задать хидер, если токен тебе известен. Выглядит примерно так:
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[4]: Swashbuckle - пример кастомной формы типа авторизации
Здравствуйте, Shmj, Вы писали:
НС>>Так нет же никаких проблем задать хидер, если токен тебе известен. Выглядит примерно так: S>Просто не хочется в каждом методе отдельно дублировать это.
Дублировать ничего не надо, это в хидере передается.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[6]: Swashbuckle - пример кастомной формы типа авторизации
