Създаване на HttpContext след валидация на токен, ASP.NET Core 2

Здравейте.

Преди 2 месеца някъде 2-ма колеги от моя екип създадоха база за API на .NET Core.
Преди да продължа с въпроса си, ще кажа, че основно пишем на PHP и де факто никой не е имал взимане даване с .NET като цяло.

Този проект е създаден на база четене на статии, документации и т.н. и голяма част ми се струва, че е написана типично като PHP програмист.

Като цяло бих казал, че REST API в нашия случай не е въобще REST API, но това настрана.


Използваме автентикация чрез JWT токен. Накратко като информация, в нашите системи идентифицираме потребителите си по userId и firmId. Това е така, понеже един потребител може да подлежи на няколко фирми.

Към същността на въпроса ми:

В JwtBearerEvents, при OnTokenValidation се екстрактват userId и firmId от payload-а на токена, за да се установи потребителя. Това, което не ми харесва след това е, че колегата е създал DTO, в което подава данните, след което това DTO го добавя към

Идеята му е след това в контролера, когато се изпълнява някой action лесно да може да вземе данните за потребителя. Може би, за да спести редове, знам ли.
Всичко хубаво и удобнно, но ми изглежда грешно.

До колкото знам, в контекста на контролера имам User.Identity и мога да взема всички Claims, които са подадени на токена.

Правилно ли е да се записват по този начин данни в HttpContext или по-правилно да си използваме User.Identity въпреки че ще увеличи размера на методите в контролерите?
Тази информация естествено ни трябва, за да можем да вземем информация от базата данни.

Не съм сигурен какви са точно best practices за това и е трудно да се намери информация в интернет. Всеки де факто си драска, както си иска и го приема за правилно.

Ако случайно имате и добри примери за проекти в гитхъб ще е още по-добре.


П.П. За да не питате защо не питам него защо така го е направил, ще кажа, че с него не се говори нормално и де факто няма да ми даде основателна причина.

Това мнение е било редактирано от relax4o на 05-03-2020, 16:46

Това за User.Identity зависи от Authentication-а

в Startup.cs трябва да има нещо от сорта

след това узера трябва да се аутонтекира разбира се, тогава ще можеш да ползваш

edit:

ако забелязваш тези неща с юзъра пак са в HttpContext

Това мнение е било редактирано от r4nd0m на 05-03-2020, 17:25

след това узера трябва да се аутонтекира разбира се, тогава ще можеш да ползваш

edit:

ако забелязваш тези неща с юзъра пак са в HttpContext

Да, да. Всичко това е ясно.

Въпроса тука беше: правилно ли е да създаваш DTO, което да съдържа userId и firmId и да го добавяш като нов item в HttpContext, когато валидацията на токена преминава, или е удачно да взимаш нужните claims във всеки индивидуален контролер/акшън, по начина, който си показал в последния ти код блок?

Идеята на колегата очевидно е да подава информация към репота и сървиси чрез подаване на това DTO, вместо да подава двете ID-та самостоятелно.


Сега също чета за UserManager също. Някои хора го използват, но не съм сигурен дали е удачно за API.
Доста варианти за имплементиране на автентикация и идентифициране на потребителя има, но колкото повече информация абсорбирам, толкова повече се объркваш кое в каква ситуация се използва.

П.П. Ето какво се случва в момента при валидация.

и следователно, където е нужно, се взима в акшъна

Това мнение е било редактирано от relax4o на 05-03-2020, 18:00

Ако всички контролери ще искат тая информация не виждам нищо притеснително в

но ако искаш да е с claims просто на user - dto-то му кажи да наследи IClaimsTransformation и имплементирай

после в DI-a

и вместо user обект ще имаш истински claim

Това мнение е било редактирано от r4nd0m на 05-03-2020, 18:41

Ще разгледам твоето предложение, благодаря.

Също намерих и друго предложение, с extension method.

и след това, където ми трябва чрез User.

което изглежда доста удобно и чисто.