Bug? Large Viewstate Breaks Forms Authentication

Discussion in 'ASP .Net' started by Ed Henn, Jan 6, 2004.

  1. Ed Henn

    Ed Henn Guest

    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!
    Ed Henn, Jan 6, 2004
    #1
    1. Advertising

  2. Ed Henn

    Ed Henn Guest

    I'm posting a resulting offline conversation here -
    Reply From: Robert Chaplin []

    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 [mailto:]
    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 [mailto:]
    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 [mailto:]
    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 [mailto:]
    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 [mailto:]
    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 [mailto:]
    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!
    Ed Henn, Jan 13, 2004
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Eric
    Replies:
    2
    Views:
    1,457
    Tommy
    Feb 13, 2004
  2. Jerry O
    Replies:
    2
    Views:
    1,616
    Jerry O
    Feb 4, 2005
  3. =?Utf-8?B?dGhlaGVyY21hbg==?=

    Forms Authentication, Cant download large files

    =?Utf-8?B?dGhlaGVyY21hbg==?=, Jan 20, 2006, in forum: ASP .Net
    Replies:
    3
    Views:
    453
    Joerg Jooss
    Jan 21, 2006
  4. Eric
    Replies:
    2
    Views:
    498
  5. Kyle Peterson
    Replies:
    13
    Views:
    277
    Kyle Peterson
    Dec 30, 2006
Loading...

Share This Page