DM
в 2.0 все выглядит очень прилично
Size: a a a
2018 August 09
DM
policy based auth
DM
resource based auth
DM
вчера нашли говнокод в фреймворке с которым можно просидеть пару часов
DM
если кто-то будет юзать такой middleware у себя
DM
app.UseForwardedHeaders(forwardedHeadersOptions);
DM
var forwardedHeadersOptions = new ForwardedHeadersOptions
{
ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
};
{
ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
};
DM
не забудьде добавить пару строчек
forwardedHeadersOptions.KnownNetworks.Clear();
forwardedHeadersOptions.KnownProxies.Clear();
forwardedHeadersOptions.KnownNetworks.Clear();
forwardedHeadersOptions.KnownProxies.Clear();
DM
это для сценария где вы закрыты reverse proxy
A
не скажу за 1.1 (помоему там фреймворк в целом кусок говна)
ну а мы с автогенерацией жили на 4.6 ещё. потом переехали на 1.1, потом на 2.0. все эти атрибуты на экшнах - это интересно и клёво, если есть чёткий маппинг на то, что описано в апи. swagger на тот момент тоже был не текущей версии и всё было с этим плохо, поэтому мы и "не придумали".
по факту же ничто не мешает это использовать, если у нас в сваггере есть описания для этого.
по факту же ничто не мешает это использовать, если у нас в сваггере есть описания для этого.
A
app.UseForwardedHeaders(forwardedHeadersOptions);
cool. а то намучились в своё время.
DM
ну просто resource based auth. в сваггере не опишешь
A
ну просто resource based auth. в сваггере не опишешь
у них там oauth2, да. но в целом, через x-... можно описать всё что угодно :)
A
3я версия OpenAPI (бывший сваггер) в общем и целом сильно лучше. например, стало можно по-человечески описывать ендпойнты с блобами.
DM
не, я имею ввиду такой тип авторизации где в зависимости от конкретного ресурса тебе нужно авторизовать конкретный identity
типичный пример это при наличии какого-нибудь
/api/companies/{id}
не позволять получить информацию о компании юзеру другой компании
User
{
CompanyId: "1"
}
/api/companies/1 - 200 OK
/api/companies/2 - 403 Forbidden
типичный пример это при наличии какого-нибудь
/api/companies/{id}
не позволять получить информацию о компании юзеру другой компании
User
{
CompanyId: "1"
}
/api/companies/1 - 200 OK
/api/companies/2 - 403 Forbidden
DM
такую авторизацию сложно формально описать каким то мета dls
A
не, я имею ввиду такой тип авторизации где в зависимости от конкретного ресурса тебе нужно авторизовать конкретный identity
типичный пример это при наличии какого-нибудь
/api/companies/{id}
не позволять получить информацию о компании юзеру другой компании
User
{
CompanyId: "1"
}
/api/companies/1 - 200 OK
/api/companies/2 - 403 Forbidden
типичный пример это при наличии какого-нибудь
/api/companies/{id}
не позволять получить информацию о компании юзеру другой компании
User
{
CompanyId: "1"
}
/api/companies/1 - 200 OK
/api/companies/2 - 403 Forbidden
да, я понял. непонятно, что мешает написать в сваггере
x-requireCompanyRoles: User
x-requireCompanyRoles: User
DM
ну надо гдето потом такой заголовок обработать
A
или там.
requiredClaims: company:userA
ну, нагенерить соответсвующий атрибут к экшуну. возможно, даже штатный