I'm using IIS 7.0 on WS2008.
I've implemented a simple login page that redirects to another simple page showing the Request.ServerVariables key/values.
I'm using the built-in SQL membership provider.
The website is on a DEV machine and there are no users on it.
When I login at the same time with 2 different users from 2 different locations (2 different public addresses) then one of the Request.ServerVariables page is the same as the other.
That includes the client IP address which is then completely wrong.
The authentication as well as the other cookies are wrong as well.
I checked the IIS log and it shows the correct client address as well as the correct login name.
If I then reload the wrong page I get the correct data.
Is there some concurrency issue in ASP.NET? I disabled the session and caching but I still get the same behaviour.
Cheers.
We had exactly the same issue when we accidentally cached too heavily on the IIS. The website simply returned whatever it had returned before.
Take a look at the site settings and see if you have any settings in the "Output Caching" of your website.
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.
We currently have 2 separate ASP.Net websites hosted on one of our server. These sites uses StateServer to maintain same session across both sites. We are looking to move these sites to Azure. I was able to upload both sites on Azure without any trouble but I was not able to share the session between both sites. I tried using Azure Cache Service (Preview) to maintain session but for some reason it doesn't work, it always uses different session when I redirect to the second site. I already spent quite a bit of time googling around with no avail.
To get to the bottom of the issue, I now have created 2 test sites and have uploaded it on the Azure. I changed the config to use the Cache Service (Preview) as SessionState but it still doesn't work.
The link to get to the test site is: http://sessiontestsite1.azurewebsites.net/
On the home page, please enter a value in the textbox and click "Update session variable", this will store the text into a session variable. Then, on the top right corner of the page there is a link called "Site2" which will redirect to the second site. I am hoping that second site will be able to access the session variable set in the "Site1" and vice versa. Please note on my local machine I was able to use the same session using StateServer.
I followed this link to configure cache service.
I read somewhere, people were saying that Cache Service cannot be used with Azure Websites but I think those are old posts, as per Scott Gutherie's blog (sorry, StackOverflow doesn't allow me to post more than 2 links) Cache Service can be used with Azure Websites.
Also our requirement is to use these sites as Azure Websites, we do NOT want to use WebRoles or VMs or CloudServices etc.
This is not how session works.
When you put a value in the Session the server assign the client an ID and sends it to the client in a cookie. In ASP.NET it's ASP.NET_SessionId. The client (Browsers) will only send the cookie to the remote address associated with it. If you use Fiddler or browser dev tools you will see the browser sending back the ASP.NET_SessionId cookie to sessionstatesite1 and not to sessionstatesite2 because it has a different hostname.
You can either add the cookie manually (using browser dev tools for example) and test it again.
If you want to use the cache for user session and have the user access the site using 1 URL that get's routed to different Azure Website Instances, that cache will work fine for you. Again you can verify that using multiple ways. Adding the cookie manually above should show you that it's working. If you wanna do it in an end-to-end flow do this:
Create an Azure Website
Scale the site to run on multiple instances
Configure your site to display the Process Id or Instance Id Environment Variable
Configure your site to use caching as you already did before
Store something in session state
log in to kudu (https://<yoursitename>.scm.azurewebsites.net)
Go to process explorer view (https://<yoursitename>.scm.azurewebsites.net/ProcessExplorer) and right click on the w3wp.exe and kill it (you can also verify the PID there)
send a request again from the browser, it will go to a different instance and you can tell by the Process Id, but the session value will still be saved.
Because session sharing in our current setup doesn't work we have decided to use two sites as virtual applications.
We have now created a new website and that website has two sub folders (set as virtual applications). Both sites now sits in theses sub folders. That way session state using cache service works.
I have a diagnostic web application hosted in IIS7 that has Windows Authentication enabled and Anonymous auth disabled. This application generated some kind of a report where it includes information about what kind of authentication was used to view the site. Every time I browse to this site I get a message that I connected using Anonymous authentication which for me is unbelievable. The report works fine (tested on other machine) and the fact is that I do not get a credentials popup. How is this possible and how can I fix this?
First, i'm not knocking your diagnostic application, but it may be worth looking at the IIS logs (or indeed switching them on for your site) to see what IIS thinks is going on. If you're not familiar with IIS logs, I'd suggest writing them in Microsoft format (at least while you're sorting this problem). One of the key fields you get is the user id. If you really are hitting the pages anonymously, this id will be the id you configured to field anonymous requests. Otherwise, it will normally be the calling user's id (at least in a simple scenario).
Second, how many sites are you running? Are you sure you're going in through the expected site? Or maybe you're hitting the default site instead?
Third, bear in mind that authentication can be set at the site level but anso at the page level. Are you sure one isn't overriding the other?
I created an ASP.NET application for an internal purpose, where the domain user accesses a simple web form, fills in the form and submits. The application impersonates the user and sends an email as the logged on domain user to our ticketing system where a ticket is generated from the user who filled out the form. Now, everything works when I test by logging onto the same server that IIS (7.5) is located and submit the form, but when I try to do the same from my desktop (opening browser and pointing to web server), it does not work. After investigating the issue, I discovered that this is likely a double-hop issue (which I confirmed when the exchange admin checked logs after a few failed attempts and found that site was trying to send email as NTAuthority/Anonymous.)
I've combed the web and found a lot of info on this issue, but all I can seem find are articles detailing the issue in relation to earlier versions of IIS (IIS 5 or 6.) I’m using 7.5 so I’m not certain of how the process for resolving this would differ. Could someone who has had this issue on IIS 7.5 post the basic step by step instructions for resolving double-hop as it relates to IIS 7.5 and sending impersonated email to an Exchange server? Something to the effect of, step one – do this, step 2 – do this, etc…
Another question that I have is the following: Many articles that I have read specify setting up a service account for delegation, and then create SPNs...However with IIS 7.5, I have the option of using application pool identities. Would application pool identities work with delegating impersonation, or would a service account be required to fix the issue?
Thanks all!
From your description, it sounds like your ASP.NET application is trying to determine the logged in user by their Windows network login credentials?
If so, all you should need to do is turn off "Enable Anonymous Access" in your IIS site and make sure that "Authenticated Access" has the "Integrated Windows Authentication" turned on. Then IIS should properly query the browser for their login info and the session should use the user's credentials. This assumes a few things about the client browser used and if something other than Internet Explorer is used, then you might also need to turn on one of the other authentication methods so that the other browsers will properly prompt the user for their network login credentials. Sorry I don't have a running IIS 7.5 server at the moment to give you the exact site properties and descriptions to look at. So if you cannot determine it from my description here, hopefully someone else might add on with that or I can try to follow up later if you need.
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.