I need suggestion about storing logged user.
i have front application and we are using token for authorization, I check that token on some authentication server, then I got user from db to do some extra checks for access rights..
But somewhere I need that user again (like to log some changes that he did), and I need advice, is it better to every time get user's email from token, then need to ping database or it's better to make same global variable and to get it when I need.. I know that second approach is faster, but is it good one?
When you authorise a user using token, the best way is to add this to the ClaimsPrinciple (claims). Then you can be able to access it using Identity.User
Related
Let's suppose we have 3 microservices, one of them is the identity server. When the user login, we create a token and get his roles and permissions after validating the credentials (obviously).
So, every time the user accesses/calls the API from the other 2 microservices, we don't want to make a database call based on the token to check whether the user has access/permission for the particular API or not. Also, we don't want to store the roles and permissions in session as there could be thousands (suppose 50000) of user login in at the same time.
Can anyone suggest a solution to reduce the database call in the .NET backend only?
I thought of creating a txt file by the name of token or username and storing the roles and permissions for that user and retrieving them when required. If the token expired, will delete the txt file and create a new one with the new token name.
But I think this is not the correct way to code for major projects. So, looking for good and effective use of DOT NET features.
What I want to do is something common in web pages. You write your email and password and then if you close the page and go back in, you won't have to write them again.
I am using Angular in FrontEnd and .NET 6 in Backend
My first thought is to store your email and password in local storage and when the user enters the page again, the app will read the variables in local storage and try to log in. Looking at other pages, it seems that they do not store this data, which made me think that this was not the correct option.
The second thing I thought of was to store the email and password in .NET, but I don't know if this will work with many clients, I also don't know how to store these credentials permanently.
I hope someone can tell me how to do this in a safe way, at least safer than these options.
I'm working on a .net Core 5.0 MVC project that the user logs in using Windows Authentication.
So there is no Login controller. The browser itself asks for username and password and redirects the user to my controllers.
And I want to do some logging right after the user logs in. I want to log to the database some information regarding the User + Date + IP.
If I understood correctly, if I use .net core middleware (if I create my own middleware and place on Startup.cs), I will be logging on every request. And that's not what I want. I want just the first login of each user.
Is there a way to do that? I've tried to search SO and MS docs, but couldn't find an answer.
Is there any interceptor that happens only after Windows Auth login?
Thanks!
The only way I can think of doing this is by hanging off something you store somewhere. There isn't anything out of the box that I can think of.
A cookie would work but is too volatile. The only safe and consistent way I can think of is to hang off a value stored somewhere in your user store (database) that is a booleon flag that once you have done your first login stuff, you set to true and can check on subsequent requests.
Much like you are probably doing with email confirmation if you are using the standard ASP.NET Identity and demanding verified email addresses.
I've an AspnetCore + Angular setup where the authentication part is handled by IdentityServer4. One of the requirements now is to get a list of all users who are currently logged in. Any ideas/suggestions how to proceed on this?
PS: Just in case it's needed, I'm using implicit flow .
Auth is persisted via a cookie, which lives client-side. The server doesn't know who all is logged in. It only know in the context of a particular request (where the client sends the auth cookie back) whether that particular client is authenticated or not.
If you really need this, you'll need to manually track it yourself somehow, like adding a record to a table for each login. However, this can get gnarly fast. You'll need to also manage sign outs and expirations, to keep your custom data fresh.
A generic answer could be: ASP.NET CORE keeps each user session in a cookie, separately located at each user's browser on each device. Once you need, you have to centralize that system yourself. Howerwer, since the question regards Identityserver, we can look into what is already done in that area by the IdentityServer authors. And they have provided at least two extensibility points.
The first one is to employ Reference Token (instead of the jwt by default), then look through the persisted grants database, fetch all the sessions grouped by userId. Not a standard way for OpenIdConnect, but it exists.
The other approach is to implement your custom session store based on a database (instead of the cookie based by default). That provides you access to all the clients logged in with the given user id. Here is my old (but still valid) example of a hybrid (cookie + IDistributedCache such as REDIS) extension for the DefaultUserSession. Usually after the requirement to list all the user sessions, appears the other one: to create a kill the session button next to each row. Here you have to be careful with access token lifetime (make it reasonably short), as a jwt once issued can not be invalidated before its normal expiration.
There is provision in the default cookie provider in ASP.Net Core to use a DB or distributed cache to store cookie payloads. Check out the Microsoft.AspNetCore.Authentication.Cookies.ITicketStore interface and the CookieAuthenticationOptions.SessionStore property.
We created our own implementation that stores auth cookies in the PersistedGrants table along with IDS4 stuff. It works well, keeps cookies small and facilitates a "sign out on all devices" option also. If you align the expiry of the entry with the cookie authentication properties then the housekeeping is done for you.
This question has been asked many times but I don't find any clear answer about it.
I'm building an App with twitter access.
Of course, I get the two tokens but as I don't want to ask the user every time to authorize the App I need to store them.
But where ? Cookie, Session, DB ??
Can somebody help me and tell me the pros and cons with those methods.
How long do you want to keep the access for? If it is just a single interaction, then keeping it in a session should be fine. If you want to use the cookies over a longer period of time with multiple interactions, then storing it in a DB is probably much better.
I would advise against storing them in cookies. If the user logs in from another browser or another machine, they would be prompted to authorize again. And then the tokens stored in cookies in the original browser wouldn't work. So it would be a confusing experience for the user.