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.
Related
I have an application that uses APS.NET as the middle tier. One of the features for administrators is to allow them to popup another browser window logged in as a non-admin user, so they can provide support.
I use a javascript function "openWindowWithPost." The application takes credentials from a DB and forces a login so the support staff does not need to know the user credentials. Unfortunately when it does that the original session is reused and hence all of their application variables are shared, causing havoc with the original Admin login.
What I would like the ability to do is to force a second browser window to popup and when it talks to IIS have it create a new session and keep the original one active. Is this possible? If so where can I find how to do this?
From your post, it looks like you are using the Session object in ASP.Net to store data.
By default the Session ID is stored by the browser in a cookie. See MSDN
for a description of how it works. You could setup your application to use query strings to store the session id, but that is really old fashion and can become messy and hard to deal with.
Your best bet is to find a solution at the browser level. For example, Firefox has an extension called Multifox that would do what you want. Other browsers have similar extensions.
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.
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 was wondering if anybody could give advice on a secure way to implement a global login. I have an admin page that accesses active directory admin groups after typing in your username and password.
current logged in account (on computer) does not matter
user in web browser goes to web app, redirects to global login page with query string of app name
types user name and password of an account in AD (not necessarily current computers logged in user)
authenticates (looks up user, pass etc and authentication is valid)
redirects back to original web app.
Once redirection happens, how do I securely tell the original web app that this user is ok until the original web session dies?
The way I'm thinking of implementing it:
My original thought was to pass the session ID of original app to the login page as well as the app
name. Store that session in a DB once authentication is checked. Master page of the other app validates on page load that the session ID matches. On session close, remove current session ID from DB.
You cannot depend on sessionID accurately in some cases. SessionID only becomes a constant value after a (any) page makes a request for a session variable, if you dont have Session_Start not defined in global.asax. If you log the user in and the default page does not access session, you will end up with a different session id for the subsequent requests until a request to session is made. Usually it is always constant as there is a default empty session_start event in global.asax.
But similar to your model, you could generate a GUID (or make sure you access session on login/authentication) and store it in the user table with an expiration. Your web sites can check this key and if currently valid, auto sign the user in.
You also cannot depend on session_end event since there is no real accurate way of detecting it (eg: user closing browser). So, you should store this ID with an expiration time along with it, preferably the same as session timeout. Just like session, you will need to extend this, something like a sliding expiration. This way, this id will be expired after a period of inactivity.
also, this Claims-Based Single Sign-On for the Web may be of interest to you.
What you're describing sounds like it would be better implemented using Windows Identity Foundation and Active Directory Federation Services 2.0. I don't know the extent of all your requirements, but it might be valuable to check out what these will give you out of the box.
You could use a cookie. If you pass the name of the application to the login page, you can set that application name to the PATH property of the formsauthentication cookie. By setting the PATH property, you're effectively limiting the readability of the cookie to the pages within that path. Because it's a common login interface, this may require some code being done perhaps in a common page base class that handles the parsing of the cookie information.
You can share authentication tokens between .NET applications, even between .NET CLR's if you want to. I think this will give you the single sign on you're looking for.
At a high level you need to share a machine key between the applications. You can generate the machine key using the key generator app code example found on this link, and providing you then reference the same key in each application the sign on can be shared:
http://msdn.microsoft.com/en-us/library/ms998288.aspx
There are some consideration when looking at things across domains or accross machines/web farms etc, but if all apps are on the same box it's not too hard.
The harder side of things is sharing things like session state which I don't believe can be done accross app pools. (I ended up recreating the session object on the new app manually last time I did it :( but that was between 1.1 and 2.0 apps )
EDIT: I did a rough write up of it last year and was using it as a test for a demo article on my site, might be worth a read through if you want things broken down a bit more (Ignore the unfinished site!):
http://www.dougmcdonald.co.uk/test/html5/v5/articles/2010/05/10/Sharing-forms-authentication-between-applications/
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.