Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 483
  • Last Modified:

IIS and webapp custom login page just flickers the first time

We created a website running under .NET. This site is always accessed directly from the computer that is serving it. The site is comprised of .NET pages with c# code behind files running under IIS.

Our website runs on Windows 2000 (IIS 5.0) and .NET 1.1 without issues. We recently transitioned to Windows 2003 (IIS 6.0) and .Net 3.5 SP1. Now we have an interesting issue. Before users can use the system they must enter a username and password on our custom login page and press the submit button. This works fine most of the time.

The problem is that if the website has been idle for an extended period of time, say 2 hours, then the login is not processed. The user enteres their info, presses submit, but nothing happens, the page just flickers. We have attached a Visual Studio 2005 debugger to the www publishing service. When the user hits submit, the page does go through page_load, and then through page_unload, but it never triggers the button clicked event. It basicly just reloads the page and ignores our button press.

After this occures, if the user enters their info again, presses submit, the button click event correctly fires and the gets logged in. It will work as expected from that point forward until a long period of inactivity has occured.

The problem occures on other pages as well beyond just our login page. For example, we have a page with 10 buttons that each perform an action. If the wepage has been idle too long (more than 20 minutes) then the session expires as expected. What should happen is that when the user presses one of those buttons, the code behind sees that the session is invalid, and redirects the user to the login page. What actually happens after a long period of inactivity (say 2 hours) is that user presses the button and the page simply reloads, never calling the button click handler, hence the user is never sent to the login page.
If they press the button again after that, the user is correctly sent to the login page meaning the button click event did indeed fire that time.

This situation also occurs if the login page is left open in the web browser (IE), and the www publishing service is restarted. The first time you try to log in the page just flickers rather than firing the button click event. After that everything works fine until you leave it idle too long.

Initially I thought this had to do with the IIS Application Pool setting, "Shutdown worker process after being idle for" 20 minutes. I tried changing it from 20 minutes to 2 days and the issue remains.

Any ideas on what to try next?
  • 5
  • 3
1 Solution
Just to check...

.net 3.5 is not backwards compatible with apps that were built for .net 1.1.

May be worth installing .Net Framework 1.1 and setting your website to use this version using aspnet_regiis tool
James MurrellProduct SpecialistCommented:
to add to comment from Springy555:

first remove all versions of asp.net then install 1.1 and service packs... the install 3.5 if required

trust me took me 5 hours of remote desktop and googling to work out that when i had this sort of problem
jonathanknezAuthor Commented:
We did take our app through the conversion process built into VS2005. We have up through .NET 3.5 installed however we are not utilizing any of the advanced features found in 3.5 so it would probably be more accurate to say we are using .NET 2.0. When looking at the properties of the website in the IIS configuration tool, we are set to use .NET 2.0, rather than 1.1. I will try setting that back to 1.1 and see if anything changes.
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

jonathanknezAuthor Commented:
As expected, forcing the website to run under .NET 1.1 just causes are app to crash. The login page I described is about 1% of our app, the rest of which runs fine on this system. In the usual case, the login page even works fine, just not after long periods of inactivity.

As a quick fix we have changed the login page to include a meta refresh set for 14 minutes. Now the even if the page has been left on the login page for a long time, the refresh keeps the client sending requests which keeps the mystery timeout from occuring and causing an issue. The downside is that if a user happens to be entering their info on the login page at the 14 minute mark, the page will refresh and whatever info they entered will be lost.
You've probably checked, but is there anything in the event log (system and application) related to IIS / App pool recycling?
There should also be a timeout section in the machine.config file.  See if increasing this makes a difference.

Also worth checking the web.config, although if you copied this straight from the Win2K server it probably won't have changed.
jonathanknezAuthor Commented:
The problem appears to be resolved but I have an overnight test to complete before I officially close it.

We actually have 2 similiar apps running on similiar hardware that use the exact same OS, .NET version, etc. The second app never suffered from the long time out page refresh issue. I compared the web.config files for both projects per Springy's advice. I found that under the "SessionState" element the attribute "cookieless" was set to false for the app that worked and true for the one that did not.

I changed it to false and now our app does not appear to have the long timeout page refresh issue. I had changed setting previously for the default website using the IIS manager utility but it seems that the web.config settings has the final authority.

So far I have verified that the website works as expected when www publishing is restarted with the webpage open, and also when the page is idle for 2 hours. I am going to leave it overnight just to confirm it still works as expected in the morning after a 14 hour idle time, though I fully expect that it will work fine.
jonathanknezAuthor Commented:
Unfortunately the solution did not work, at least not without producing some serious side effects. The refersh issue is gone however now we can no longer get our session to timeout.

Previously we had our application's web.config set to cookieless=true. This meant the session ID had to be passed via the URL. If a user logs in, then leaves the page idle for 15 minutes, their session would expire. Any time after that any page they navigated to would check their session, see that it no longer contained a valid user name (originally stored in session when the logged in), and would redirect them to the login page.

Now that we have our web.config set to cookieless=false, the original refresh probelm is gone however our session never expires. I have the application connected to debugger so I can see exactly what is happening. I have breakpoints all over the place, including the Session_End method of our Globals page. This session_end is never called when the session should have timed out. If logged in, the user has the option to press logout. When they do, Session.Abandon() is called which DOES trigger session_end to get called. The user manually able to end their session, but the timed end of the session does not work.

IIS has plenty of options for timeouts. So far I change the "timeout" value in my web.config to 1 minute. In the IIS manager window, for my web app, there is an option for "Enable Session State" which I have checked (it was always checked) and I set the associated "Session Timeout" to 1 minute.
I have left a user logged into the webpage for 5 minutes with no activity and still the Session_End is not called. If I try to navigate to a different page, the username string is still stored in the session, hence I am allowed to.

Can any one help me get my session to time out? I have also isolated my web app into is own dedicated application pool. There was no change.
jonathanknezAuthor Commented:
I finally have some time to close the loop on this issue. Ultimately we fixed the double login problem but it required reworking the way we were handling the users session. Let me elaborate.

There are 2 ways for the client to notify the server about the session id; by including the session id in the url itself or by including the session id in a cookie (and consequently included in the page header).

Our application originally took advantage of the session id encoded in the url. On Windows 2000 with .NET 1.1 this worked great. Under Windows 2003 with .NET 2.0, this fell apart. The session still worked fine, except that when the session expired, the server would redirect the user to a new url including a new session id rather than process the users request. For example, suppose the user was logged into our application (valid credentials stored in the session) then decided to log out. The user would be sitting at our custom login page. Their session would be valid since they have not been idle for very long, though their session does not include the credential info necessary to access our system. Fast forward 15 minutes of inactivity and the session times out. The client is still displaying the same webpage that includes the url that uses the now expired session id. When the user enters the login info and presses submit, the page does a postback. Rather than processing their button press, the server instead simply redirects the user to a new page at a url that includes a new session id. The button click is completely skipped by the server. Everything we read online indicated that .NET would reuse the old session id however that was absolutely not happening in our case. I was watching the session ID with in a visual studio debugger. Perhaps it was because our page was https secure enabled. Regardless, the old session id was not being reused, regardless of whether we were doing session.abandon or not. This method of maintaining the sesison ID was no longer working for us.

The next method we tried was storing the session ID in a cookie. This worked great and eliminated the double login issue but it introduced another weird problem; the users session never expired, ever. We logged into our application and left it idle for an hour. Even with a 15 minute timeout, the session stayed active. We rely on the session timing out so we know when a user has been idle too long and thus needs to be sent to the login page. After much searching online and debugging it turns out the issue that we were were invoking a webservice at a regular interval that was keeping the users session active. We had a status item on the page that was dynamically updated every few seconds by a javascript file that was invoking a web service. The web service was in the same root website that the user was accessing so everytime the webservice call was made, the users session was extended. It turns out that web services are incapable of passing a session ID via the url, but that are perfectly capable of passing a session ID in the form of a cookie. This second approach was not going to work for us after all because the users sesison never timed out due to pre-existing web service calls.

Ultimately we decided to keep the session ID in a cookie and drastically change how we were managing the users session. Since the session ID is in a cookie, and since we have a web service that keeps the users session active, the session never expires. We decided to add a session timeout tickcount variable and store it in the session itself. We added a new base page that all other web pages extended. The base page would redirect the user to the login page if the session was invalid OR if the  timeout tickcount had expired. If the session had not expired AND the timeout tickcount was not expired, then the timeout tickcount would be extended since a page loading should be counted as activity from the user. We based the timeout tickcount on the same timeout threshold defined in our applications web.config just to keep things consistent.

In the end, we had to write a base page (should have always had one) and make a lot of small code changes to all of our pages. This allowed us complete control of the user timeout logic while avoiding any double login issues (and without abandoning our existing javascript webservice updates). Our timeout logic has been working flawlessly since we added it. Its actually kind of freeing not to have to worry so much about what is happening with the .NET session... while it time out after 14 minutes or 15 minutes and 20 seconds. Now our session just stays active indefinately.

I should specify that this works great in our specific environment where we essentially have only a single user. That javacript webservice call that keeps the session active would be a big problem if we had lots of users visiting for a short period then leaving their browser open and keeping their session active.

I hope this long winded explanation helps the next person that has the same session issues.

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 5
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now