Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > Bug? Large Viewstate Breaks Forms Authentication

Reply
Thread Tools

Bug? Large Viewstate Breaks Forms Authentication

 
 
Ed Henn
Guest
Posts: n/a
 
      01-06-2004
In trying to solve a Forms Authentication problem I posted about earlier
("Forms Authentication - Bad Redirect on POST"), the problem now appears
to be due to having too much data stored in viewstate. I have found
several other references in this newsgroup to large viewstate causing
various problems, but not this specific issue. Can anyone confirm that
the following is a bug? I'd like to know if it can be fixed without the
obvious solution of turning off or limiting viewstate size.

The issue is that when a Forms Authentication session is timed out and
the user tries to POST on a page with approx. 50+ kb in viewstate, it
results in a 403.1 error (Execute Access Forbidden). Normally any GET
or POST after a Forms Auth session times out will result in being
redirected to the Login page.

When this error occurs, there is additional odd information in the web
logs. On the web log entry that would normally contain a GET for the
login page (redirected from the requested page), there is a corrupted
looking http verb (i.e. "b25kcztCZWFyIE...") in place of the GET, but
the rest of the line appears like normal.

I'm using VS.NET 2003, framework 1.1.

Can anyone at Microsoft confirm that this is a bug? Anyone else ever
have a similar problem and have a solution? Thanks in advance,

Ed Henn
Sacramento Superior Courts MIS

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
 
Reply With Quote
 
 
 
 
Ed Henn
Guest
Posts: n/a
 
      01-13-2004
I'm posting a resulting offline conversation here -
Reply From: Robert Chaplin [(E-Mail Removed)]

Ed,

I was afraid you'd ask that! I skirted the issue because it's not a
simple answer.

Basically, I'm serializing the view state to a temp file on the web
server that gets deleted when the session ends. We're using "sticky"
session state (InProc) on our web farm so that works well. If we ever
use StateServer or SQLServer session state I'll have to store the view
state data on a file server or as a session variable instead. I used
temp files for now because I wanted to avoid accumulating huge amounts
of view state in session.

BTW: If you have time could you post our exchange to the USENET thread
you started? I'm not hooked up with news right now (other than Google
searches). It might be helpful to others.

Thanks,
Bobby

-----Original Message-----
From: Henn, Ed [(E-Mail Removed)]
Sent: Tuesday, January 13, 2004 8:19 AM
To: Robert Chaplin
Subject: RE: Bug? Large Viewstate Breaks Forms Authentication


Robert -

Clearly you were willing to go to much greater lengths than I was to
solve this issue. Glad to hear you got around it. Just out of
curiosity, how does your solution differ from setting sessionState to
"StateServer" or "SQLServer"? Where/how are you storing the viewstate
on the server? I have never dealt with that area of ASP.NET so bear
with me if I'm asking stupid questions. Thanks again

Ed

-----Original Message-----
From: Robert Chaplin [(E-Mail Removed)]
Sent: Monday, January 12, 2004 5:21 PM
To: Henn, Ed
Subject: RE: Bug? Large Viewstate Breaks Forms Authentication


Ed,

We worked around the problem by overriding the page's
LoadPageStateFromPersistenceMedium() and
SavePageStateToPersistenceMedium() methods to save the view state
elsewhere (server-side). That way the large __VIEWSTATE form field is
not sent to the browser at all and we avoid the bug (whatever it is).
It consumes additional server resources but the nice thing is that it
saves a lot of bandwidth usage.

It would be nice to actually know what the real problem is, though,
instead of just addressing the symptom. Oh well...

I hope this helps.

Bobby

-----Original Message-----
From: Henn, Ed [(E-Mail Removed)]
Sent: Monday, January 12, 2004 2:09 PM
To: Robert Chaplin
Subject: RE: Bug? Large Viewstate Breaks Forms Authentication


Sounds good, thanks for the additional info. I will let you know if we
find anything out also. Thanks

Ed

-----Original Message-----
From: Robert Chaplin [(E-Mail Removed)]
Sent: Monday, January 12, 2004 12:33 PM
To: Henn, Ed
Cc: Todd Thompson
Subject: RE: Bug? Large Viewstate Breaks Forms Authentication


Thanks for the info. Perhaps we are not experiencing exactly the same
problem...

What we are seeing so far leads us to believe the problem is with the
IIS connection somewhere. The fact that Disabling keep-alive fixes it
supports this idea. And we also suspect that SSL (HTTPS) also avoids
the bug, but we can't verify that yet. We are not experiencing the bug
in one environment where SSL is the only difference we know of.

I'll let you know if we find out anything else.

-----Original Message-----
From: Henn, Ed [(E-Mail Removed)]
Sent: Monday, January 12, 2004 12:19 PM
To: Robert Chaplin
Subject: RE: Bug? Large Viewstate Breaks Forms Authentication


Robert -

No, we didn't find a solution and your response is the first I've
received on this topic. I researched the issue a bit before posting,
and found a reference to a keep-alive solution on another post (not sure
if it was you or not). I tried it and it didn't work. But I appreciate
your suggestion. I was hoping to get some response from MS (hence "bug"
in the subject), but have received none so far. We'll see. Thanks
again for your help, and let me know if you run across anything new on
this issue.

Ed

-----Original Message-----
From: Robert Chaplin [(E-Mail Removed)]
Sent: Monday, January 12, 2004 11:02 AM
To: Henn, Ed
Cc: Todd Thompson
Subject: Re: Bug? Large Viewstate Breaks Forms Authentication


Did you ever find a solution to the large ViewState problem you found?

We're having a similar problem here. Curiously, we found that disabling
"HTTP Keep-alives" for the IIS web site in question prevents the problem
from happening. Maybe that's a clue to the cause. For performance, we
prefer to have HTTP Keep-alives enabled though.

Thanks in advance for any information.

---------------
In trying to solve a Forms Authentication problem I posted about earlier
("Forms Authentication - Bad Redirect on POST"), the problem now appears
to be due to having too much data stored in viewstate. I have found
several other references in this newsgroup to large viewstate causing
various problems, but not this specific issue. Can anyone confirm that
the following is a bug? I'd like to know if it can be fixed without the
obvious solution of turning off or limiting viewstate size.

The issue is that when a Forms Authentication session is timed out and
the user tries to POST on a page with approx. 50+ kb in viewstate, it
results in a 403.1 error (Execute Access Forbidden). Normally any GET
or POST after a Forms Auth session times out will result in being
redirected to the Login page.

When this error occurs, there is additional odd information in the web
logs. On the web log entry that would normally contain a GET for the
login page (redirected from the requested page), there is a corrupted
looking http verb (i.e. "b25kcztCZWFyIE...") in place of the GET, but
the rest of the line appears like normal.

I'm using VS.NET 2003, framework 1.1.

Can anyone at Microsoft confirm that this is a bug? Anyone else ever
have a similar problem and have a solution? Thanks in advance,

Ed Henn
Sacramento Superior Courts MIS



*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Best practices for using forms authentication and security in a hosted env (was: Re: Using a Forms authentication in a shared hosting environment) JEFF ASP .Net 1 11-12-2007 07:00 PM
Forms Based Authentication Issue (VIEWSTATE) Login Form On Non Protected Page Kyle Peterson ASP .Net Security 13 12-30-2006 04:11 PM
forms authentication -- expired forms cookie vs. not provided forms cookie Eric ASP .Net Security 2 01-27-2006 10:09 PM
Forms Authentication and long ViewState Problem Jerry O ASP .Net 2 02-04-2005 08:35 AM
Forms Authentication question: How to have some pages open and some requiring forms authentication Eric ASP .Net 2 02-13-2004 02:14 PM



Advertisments