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.
Related
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
I am developing an application that will support several departments in our organization, and want to define what data is accessible by AD Groups a user is in.
My question is, is it more cost effective resource wise (bandwidth, time slices, etc) to use an IsUserInRole() call at each decision point or to load several Session[] variables at user login which are Boolean and use those throughout my code?
Thoughts?
I would avoid Sessions. They make scaling an application harder since you need a centralized store (a Database or Redis), while will be hit at every single request. It slows down the process since you have to wait for the request to complete before going on with the actual business logic.
The answer for this is using JWT tokens. They work very well for small amount of data (like a limited amount of roles, not hundreds of them). JWT tokens can safely be put inside a cookie so every browser request carry it to the server.
You may get more information about JWT tokens here: https://jwt.io/introduction/. This other StackOverflow question has a lot of information about JWT tokens: Using JWT to implement Authentication on Asp.net web API.
I hope it solves your issues. Good luck.
I have an asp.net (webforms) application and I would like to track user visits to the site. I have the DB, objects, basic idea down.
My goal is to track a user from the first time he enters the site and up until he creates an account. So I can trace back where this user came from in his initial visit (Organic, paid, referrer, etc.).
I am planning to create a cookie with a GUID for each initial visit, store all actions in the DB, and finally, when the user registers, I can go back and update a username field for all rows matching the GUID.
My problem is that I can't make up my mind on the best method to do this.
Should I use an HTTP module and the session start and end events,
or maybe ajax calls to a WCF backend?
What would be the most efficient and accurate way to do this?
Unless you plan on supporting anonymous sessions (which depending on traffic may or may not be an option), Session won't work.
The simplest thing that could work is simply putting a ticket (like your guid) in a cookie. You can set and retrieve Cookies from your Page and use that to track the user. This does mean you'll only be able to track a user when he accesses from the same machine but until he's authenticated, you don't really have that much of a choice.
My asp.net session objects are storing in SQL server.I am storing an ID in session. If client open another browser and storing different ID in session. I need to notify client is “are you sure you want both ID’s open?” in same based user logged user.
Application runs on logged in user (not anonymous)
How can we check this in asp.net?
Session is not linked to an authenticated user, and there is no way of accessing an other connection's Session without knowing its SessionID.
Usually this kind of problem can be solved using cache instead of session state. With cache you can create your own user-based keys to store data. Depending on whether you are planning to just run your web app on one server or in a web farm environment, you can either use asp.net in-process cache or one of numerous distributed cache solutions (like memcached which I'm using in my web projects with great success).
There are a couple ways to go about this:
Option #1, in your user table, add a value called "session id"
When a user logs in, check to see what their last session id was. Then test to see if it's still a valid session. If it is, ask them what they want to do. Store the latest session id in that table after each log in.
However, I'd go with option #2: Don't do this. If the user wants to open multiple browser windows to access your application then let them. There's probably a pretty good reason for it. Most (as in nearly all) users have no idea what "session state" even means and they really have no desire to know. All they care about is getting their job done.
I currently have a website and upon registration to the website i generate each member a unique GUID. Upon the user logging in to the website i check the credentials and store the guid in session if successful, in order to show the user there profile / how many post have been made etc i run my queries to the database passing the users session GUID to fetch data related to them.
Can anyone kindly confirm a better approach for this ?
Have a look at the membership features in ASP.Net: http://msdn.microsoft.com/en-us/library/ms998347.aspx
This is basically how most authentication/authorization systems work. Some things you may want to keep in mind:
Don't reinvent the wheel if you don't need to - as Max pointed out, ASP.NET has a built-in auth provider that is fairly feature-rich and can be extended as well.
I would avoid storing anything in Session unless you have to. It is easy to get lazy with Session, and it is also potentially volatile - if you bounce the service, anything in Session is gone.
If you store a cookie on the client to handle this, ensure it is salted and encrypted.