StilauGamer
Explore posts from serversInject IDbContextFactory or DbContext directly?
Yeah, its just that you use the same db context over the whole user request..
In Blazor, 1 scoped service last from when he starts viewing till he closes / refreshes, etc..
So in theory, when using a db context, you have it alive for the whole time, if its not disposed at some point tho ofc..
But then I don't need to do it in my web apis :sunglas:
Another mystery solved for today! 🫡
15 replies
Inject IDbContextFactory or DbContext directly?
From my understanding, the DB Context Factory is more widely used within Blazor applications where the scope is more wide...
The scope is per user request and not just a HTTP request like in a Web API..
So its more recommended to manually create the db context, etc in Blazor.
But in a Web API, you are good enough with just injecting the DB Context directly as its scoped to that request only..
Thats from what I understood.
Reference to the article
15 replies
Localstorage + JWT
I find server sided a lot more secure and I feel more secure as a user when its not stored on my pc...
Thats why I thought about my way of doing it.
It gives the user more flexibility on what devices and what IPs might access their account..
Aswell as you can show a last active time on the cookie to show that some people might've been on it recently..
I find that this way is a little more secure and gives you both encryption on client side with storing it all in a JWT token and on the server side its all encrypted so I can't as a host go and look at it in plain text
15 replies
Localstorage + JWT
This would somewhat protect u against cookie theft, aswell as XSS attacks, it would also have more functionality when it comes to storing the access token, etc on server lets me have more functionality at my hands.
And revoking would also work as it would be done through the unique cookies?
But then I would remove both the advantages getting from only having it client sided 🤔
15 replies
Localstorage + JWT
Okay..
So there are a few issues that might happen..
So how about this.
On the server side I would store:
- A unique ID for the user, discord id.
- Refresh Token
- Time of expiry
- Access Token
- Other data I want
Inside another DB table.
- Discord ID of user
- A unique cookie
- The IP that the cookie was authenticated on
And on the client I would have a JWT that would have:
- Discord ID
- The cookie ( This is used to make sure that your cookie can be authenticated with. )
So what it does when you log in is that it cross checks the cookie and discord id to make sure its acceptable.
This way its both encrypted in a JWT with a secret key, aswell as each cookie is IP whitelisted and I can setup a system of every cookie that has been authenticated on different ips.
And then remember to active HttpOnly and HTTPS
How would this be?
15 replies
Localstorage + JWT
Yeah, I will read through and think about it deeply...
What I've currently done is:
- You log in with discord.
- You get redirected back to the website and it gets the OAuth code.
- It grabs the access_token, refresh_token, etc from discord.
- Stores it in a JWT
- Saves the JWT to a cookie
- Gets the cookie and verifyes the JWT when accessing pages, etc through middleware.
This way I don't store any of the data on the server, and its all locally..
And then I would say store the discord id in a database for a more thorough perm checking...
Is this a bad way of doing it?
Only worry I am having is with cookie stealing, etc?
If someone steals the JWT and tries using it?
Then that would work right?
15 replies
Discord.Net + MagicOnion, heheh
ahhh, went training so didn't see the last messsages.
Basically waht it does is that the source generator detects this
[LoggerMessage(.........)] and then creates the code inside the method automatically.
Right?137 replies