Environment:
Server 2008
IIS 7, integrated mode
.Net 4
ASP.NET WebForms Routing (which uses the same .dll as MVC routing, though I'm not sure which version)
Cookieless sessions (session ID travels around on the user's URL).
We have an application that uses routing to identify which organization a user is associated with. The URL will take the form domain/Organization/OrganizationSubCategory. The user follows their custom URL and sees a landing page. When they hit next, they are directed to a page that collects some demographic info, then they hit next to proceed to the application. When they do, the user is added (if necessary) to their organization in our database. After the initial landing page, routing no longer applies - the user is directed to regular aspx pages.
The site is receiving a fair amount of users entering the app; an average of 850 per day.
The problem is that a small number (less than 1%) of users are getting added to the wrong organization.
We are logging information on the landing page and when they submit the demographic page. One thing we log is Request.RawUrl. We started noticing users who are associated with one organization being logged as having requested the full correct URL (including the sub-category) of another organization. Sometimes nobody legitimately came in following the incorrect organization URL even in the same day. We've had people report directly that they just created the "sub category" (using an administrative application), instructed a user to follow their unique URL, and yet the logs show an entirely different URL for that very user (I know it's that user because I'm logging email address and session ID so I can associate the same user's path through the landing page and the demographic page). It's as if IIS is sometimes creating a new session, and simply assigning some previously requested URL to that user.
In an attempt to eliminate some sort of caching, we have:
Set the config httpRuntime element's enableKernelOutputCache attribute to false
Disabled caching in IIS settings
Set the config sessionState element's regenerateExpiredSessionId attribute to false (even though we haven't seen the session ids being re-used).
Other suggestions?
Are these internal users? Are there proxy considerations? That wouldn't explain a wrong url though. Are you 100% certain the users were given url A and they show up with URL b? Do you have any routing modules currently assigned? Are you sure its not getting rewritten by a rule in another module?
Could this be an application issue where their 'new user' email (for ex) contains the wrong url?
Well, we still don't know with complete confidence, but it seems that users in one organization were most likely searching the Internet to find URLs into the system and following those.
I can't explain the report we had as I described in the original post.
When I tried to enhance logging to capture pre-post session creation to prove it for sure, the logging on the begin request event worked in our QA environment (same as production), but just flat wouldn't work in production. I could never determine why.
Related
I have a problem that appears while using concurrent users in IIS/.Net 3.5.
I am logged in using two users to the same server (user1, user2), both are using different computers. If I press on a link to one page using user1 and immediately on the same link to the same page using user2, I receive the sent page to user1 on both computers.
It seems that IIS is caching the requests and sending it to both computers even though that both are logged in using different accounts.
This never happens if you wait a bit before doing that. Is there any specific IIS configuration that caches those requests? How can I link it to per account instead to all? At worst case, how can I disable it?
Any tips are highly appreciated.
ASP.NET has a configurable/extensible output caching mechanism.
You can configure/disable the stock page output caching in web.config, or write your own custom output cache provider and refer to that in web.config.
There's information about it here.
I have several websites that use a HTTPModule (wrapped in a dll) to authenticate users and store an authentication object in the application cache for ~10 hours. I then set a cookie containing the cache key on the users machine.
I'm now looking for a way to allow admins to clear a specific cache object for all websites for any given user (effectively logging them out) causing them to automatically log back in (via windows authentication) next time they visit any of the sites.
I was planning to have a single administration website with the facility to reset logins - but I can't change the application cache for other websites for obvious security reasons.
Is there any way of passing a signal to those sites that use the authentication module so that they can clear their own application cache?
Note: I have read up on memcached but I would like to avoid a solution that isn't 'Standard ASP.NET' if possible.
Here are two ideas:
If they are on the same server, you could have a file containing the active logins in the file system, that all projects can access.
Add a generic handler to each project, that resets the login of a given user. Call this from another project when he gets logged out there. You could add a passphrase for security reasons.
EDIT: I just thought of a better solution:
Create a central "authentication" project that keeps track of the login status. Call it from the websites (e.g. through generic handlers, webservice, ...) to log out a user or check his status.
I've opted to piggyback code onto the existing HTTPModule.
I check for a custom user-agent string, if it exists I clear the relevant cache entries based on a query string and return a custom HTTP header upon success.
The only extra overhead is checking the user-agent for each request which I can live with.
With this setup I can now use a WebRequest object (injecting my custom user-agent string) from my central site to send messages to all sites using the module.
Technology
ASP.NET, VB.NET 2.0 (soon to be 4.0)
Overview
I'm writing a Login / Authentication Portal, so that a web application can use it to login a user, and then they can use the application using their credentials.
The login portal will be a separate application, and initially only available via an extranet as well as intranet for certain applications; but future apps will need to authenticate via the web (happy to implement as a separate instance). I basically want other individual applications to be able to authenticate users via this portal.
So that...
A user goes to an application's web url (i.e. www.application.com / http://apps/application - intranet) and clicks "login".
User's browser is redirected to the portal application, with a query
string
www.loginportal.com/login.aspx?url=www.application.com/login.aspx
(or other page).
User fills in their credentials (username, password), and clicks
"login" button.
Browser redirects back to url i.e. www.applications.com/default.aspx or login.aspx and is authenticated and logged in; and can use app.
Completed
I have the authentication itself sorted, and will implement as a class library in the local applications via a dll.
Need
So I basically need to know, how to:-
1. Post data to the portal url (could be different domain).
2. Redirect browser with post.
3. Make sure that the authentication is secure, and not easily hackable (I know how to use urlencode and htmlencode etc) - just not sure about implications of posting data across domains.
Any help greatly appreciated...
Cheers,
Duncan.
Seriously tough stuff, here. If it were me, I'd lean heavily on Windows Identity Foundation. I believe it can support this scenario (haven't actually done it; someone else at my company is developing against it).
OK, so this is the solution I ended up using:
In the original application (the one that needs the authentication; step 1 above) I redirect the user to my login portal, and include the original url as a get parameter.
The user then types in their details, username and password.
Next, the server-side code authenticates them, and redirects to a new page, where I send back to the page an html form which includes the request datetime (for security) along with a encrypted string (including the datetime of the request) of the data I want sent back to the original form.
I also add a JavaScript post method which sends the data to the original url as a form post. Because I'm using the same class library at both ends, I can encrypt and decrypt the data using the same method and the original requesting application has all the user data, including the ability to check the datetime of the request (I allow a set amount of time between the authentication and the picking up by the original app, making sure these are within say 5 minutes.
And job done.
If anyone wants the code, I can provide it, just don't have it with me at the moment, if I remember I'll post it.
Not the most elegant solution, but it works, and it's secure, so I'm happy. :).
I have a sharepoint webpart where I have links to go to different web sites to which login is required. Therefore, I think i need to log the users on before redirect them into deep pages in that site, therefore I think i need to set up a cookie to that web site when the web part is loaded (by using the user credentials of the user's active directory information).
How can I achieve this requirement with out opening up a new browser window? (Though I have used a client side script, it pops up a new browser window)
Any help is highly appreciable...
Thanks
If you are referring to "different web sites" as sites having completely different URL's, then it's probably not possible without SSO system.
The reason is that it's impossible to read/write cookies from other domain in web environment, i.e. pre-login the users like you are saying.
If all the sites are inside same domain, like mycompany.com for example, and different sites are in abc.mycompany.com or mycompany.com/subsite, then yes, you can set the cookie. See top section here http://www.15seconds.com/issue/971108.htm
A simple way to implement SSO is by implementing method described later on in same article.
in the "Requesting Cookie from Another Domain". This is not a very secure method though, but can be done if you restrict it properly to specific slave domains. And obviously all the slave sites have to be modified, as with any SSO implementation.
I have an asp .net webforms app that uses forms authentication. For a small number of users we have a problem where they log in, they navigate to a couple of pages and then they are asked to log in again. Once logged in for a second time they seem to be able to stay logged in as expected. They shouldn't be asked to login the second time.
This is a single server, no web farms, nothing tricky.
This only happens to a few users, but it does seem to be all users from the same building. I am unable to replicate this and at this point might even start to deny that t was happening if one of our trainers hadn't watched it happen to a couple of customers.
Has anyone else seen anything like this?
I am also seeing a lot of "Membership credential verification failed." errors in the event log. This may be related, but all the googling I've done seems to point to web farms and the like, not a single server.
UPDATE
There is no proxy server, the IIS server and the browser (IE8) are both on the same machine.
The AV software installed is Symantec Endpoint, on one machine, on the other the user didn't have any AV at all (AV Fail!).
The browser is IE 8 with no frills, not a single addin that didn't come with the default installation.
Both session and user login time-outs are set to 30 mins and the problem happens within 1 min of the user logging on.
Logging shows the user to only have one IP address.
I have tried the sessionMode in all it's variations, this doesn't seem to make any difference.
Something has to be causing ASP.NET to think these users have new sessions or their authentication cookie is getting invalidated. Here a a few things I can think to check:
Are the users accessing the site through a proxy server? One of our customers has a proxy that will sometimes close all open connections causing ASP.NET to see the session as new.
Could an overly agressive anti-virus, anti-spyware product be "eating" the session authentication cookie?
Do they have a cookie manager browser add-in that is causing the authentication cookie to disappear or change?
Sounds basic but I've seen this happen because of site timeouts being set too short. If the user sits on the page for longer than the timeout, they will be forced to logon again. And this could be specific to a page when that page presents a large amount of data that takes a while for them to go through.
One other thing I just thought of, have you allowed multiple worker processes for the ASP.NET process (aka web gardens)? If so, the same constraints as with a web farm would apply for authentication.
Crack open Fiddler from the problem user's PC and see what's getting passed in the headers. My bet is on a proxy server and or networking issue.
Are the users possibly coming from a dynamic ip address? I've seen problems where the users sessions get messed up because the IP address that they're accessing the site from changes for some reason.
Are the people this is happening using a browser that's somehow different (different browser, different version, different extensions)? That could be a clue.
In general, when the problem is somewhat reproducible or at least predictable, I use Http Fiddler. Install it on a client machine, turn it on, and start browsing (this works via a system proxy - so it'll work for firefox, IE and any other proxy-supporting browsers alike). Fiddler will record all http traffic between client and server, and you can then peruse such a session later on to find any oddities.
It's a long shot, but one thing I've seen happen occasionally that can lead to these sorts of unpredictable errors is scripting parallelization issues: sometimes buttons + links have onclick handlers which cause a post-back. If you have several such handlers that fire on the same event - in particular when the default event still fires additionally to your custom onclick or whatnot - you may be causing several postbacks when it appears to be just a single postback. That can cause all kinds of unpredictable weirdness as it's not entirely clear which request ends up "winning" - and some odd errors may cause a session to terminate. Since this behaviour is very browser + network latency sensitive, it seems quite unpredictable when it occurs.
Delete the cookie on the client PC's that are playing up
ASP.NET Forms Authentication can redirect users to the login page if they do not have the credentials to access a specific page. It does this so that users who may have more than one login are given the opportunity to login with another account which may have the appropriate access. Basic question I know, but are the users using the same credentials the second time they log in?
Its possible that you have don't have specifically specified asp.net to use cookie based session but are allowing either cookie or cookieless sessions.
In the later case the session id is embedded in the Url. The type of issues you are experiences might be explained by that. Basically depending on how you define your links, some of them would not get the session id, so the user would get a new session when using those links - or maybe during a redirect. That could explain why at specific parts of your site the users loose their session.
If you have the mixed mode enabled, try setting it to only cookieless and go through your site.
Update: Based on the extra info posted there is surely more info needed for it. Some extra things to check:
Are you using subdomains, if that's the case the cookie might not be configured to allow that and that doesn't fail in all environments.
If you are using in-process session, make sure there isn't a bug in the application causing it to restart the process
Maybe what's causing it to ask for login again is an authorization check, and you have an issue on some roles related code
Is it possible that the user is just opening a separate window? ;)
To rule out the possibility of the browser or a browser addon messing things up, have you checked their User Agent strings? If they are randomly distributed it might not cause the problem, but if they're all the same, this might be a hint too.