가끔 잘못된 viewstate 오류를 무시해야합니까?

가끔 잘못된 viewstate 오류를 무시해야합니까?

---

때때로 (매일 한 번 정도) ASP.NET 3.5 애플리케이션에 대한 로그에 다음과 같은 유형의 오류가 표시됩니다.

• 잘못된 뷰 상태
• 잘못된 포스트 백 또는 콜백 인수

ASP.NET 응용 프로그램에서 때때로 "그냥 일어나는"일입니까? 문제의 원인을 진단하는 데 많은 시간을 할애하는 사람이 있습니까?

---

글쎄요. 잘못된 viewstate는 다양한 이유로 발생할 수 있습니다.

1. Viewstate가 너무 커서 사용자가 페이지에서 포스트 백을하기 전에 렌더링을 완료하지 않았습니다. 수정은 일반적으로 포스트 백을 트리거하는 모든 컨트롤을 비활성화하고 페이지로드가 완료되면 클라이언트 측을 활성화하는 것입니다. http://blogs.msdn.com/tom/archive/2008/03/14/validation-of-viewstate- 참조 mac-failed-error.aspx
2. viewstate MAC을 사용하고 있지만 (보안상의 이유로 사용해야 함) 컴퓨터 키를 설정하지 않았고 응용 프로그램 풀이 재활용되어 새 키를 생성했습니다. ViewStateUserKey를 설정하는 것을 잊지 마십시오.
3. 누군가가 Mac에서 숨겨진 양식 필드를 자르는 이전 버전의 IE를 사용하고 있습니다. 이 경우 페이지의 viewstate를 세션 상태 로 이동해야합니다 .
4. Viewstate MAC 문제는 일반적으로 웹 팜에 있고 web.config에서 컴퓨터 키를 설정하는 것을 잊었 음을 나타냅니다. 그러나이 작업을 수행했다면 잠재적 인 보안 문제를 배제하기 위해서만 나쁜 일을하려는 사람 일 것입니다 (댓글을 게시하는 봇, 비활성화 된 제어에 대한 이벤트를 트리거하려는 사람 등). 이러한 문제의 원인을 추적해야합니다.

당신이 무엇을하든 viewstate 또는 이벤트 유효성 검사를 끄지 마십시오 .

---

한 가지 문제는 양식 필드를 자르는 사용자 라우터와 관련이있을 수 있습니다. 이 문제를 해결하는 방법은 web.config에서 MaxPageStateFieldLength를 작은 숫자 (예 : 100)로 설정하는 것입니다. 그러면 ViewState가 작은 청크로 분할됩니다. 매우 간단 하며이 기사에서는 이에 대해 자세히 설명합니다.

---

예외는 때때로 "그냥 발생"하지 않습니다. 그들은 항상 유효한 이유로 발생하며 그중 일부는 이미 다른 답변에 나열되어 있습니다.

그러나 ViewState의 문제를 완화하려면 모두 비활성화하는 것이 좋습니다. ASP.NET 개발자로서 우리는 종종 ViewState가 기본값이기 때문에 필요하지 않은 모든 종류의 장소에서 사용하는 경향이 있습니다. 나는 일반적으로 컨트롤 사용을 고려하기 전에 정적 html 사용에 대해 생각합니다. 컨트롤을 사용하기로 결정했다면 ViewState를 활성화해야하는지 생각해보십시오. 비활성화하면 페이지로드 시간이 더 길어 지므로 가능하면 그렇게하십시오.

나는 기본적으로 비활성화되어 사람들이 이런 식으로 생각하도록 강요했지만 그렇지 않았습니다.

댓글에 대한 답변 업데이트 :

내 머리 꼭대기에서 ViewState를 끌 수있는 3 가지 기회가 있습니다.

1. 모든 포스트 백에서 데이터가로드되는 경우 ViewState를 비활성화합니다. 일반적으로 첫 번째로드에서 데이터를로드 한 다음 AJAX 요청을 사용하여 데이터를 다시로드 / 업데이트 하는 AJAX 사용 사이트 ( UpdatePanel 종류가 아닌 실제 AJAX 입니다)를 빌드하는 경우 에 해당합니다. 경우에 따라 ViewState를 비활성화 할 목적으로 만 방문 할 때마다 데이터를로드 한 다음 대신 서버에 데이터를 캐시 할 수도 있습니다.

2. 정말 정적 인 콘텐츠에 데이터 바인딩하는 경우 ViewState 비활성화를 고려할 수도 있습니다. 때로는 데이터베이스의 작은 정적 basedata 테이블 또는 이와 유사한 것에 데이터 바인딩 된 목록을 찾습니다. 이제 이것은 위험 할 수 있지만 데이터가 변경되지 않는다고 확신하는 경우 데이터를 정적 콘텐츠로 페이지로 이동할 수 있습니다 (데이터의 여러 정적 복사본을 갖지 않도록 별도의 컨트롤로 래핑 할 수 있음). ). 그러나 데이터가 변경되면 수동으로 변경해야합니다.

3. 레이블과 같은 간단한 컨트롤은 종종 ViewState를 비활성화하는 좋은 후보입니다.

마지막으로 ASP.NET MVC 프레임 워크로 전환하여 이러한 문제에 대해 영원히 작별을 고할 수 있습니다. 이것이 제가 다른 문제에 직면하더라도 그렇게 할 계획입니다. ;)

---

BlowDart는 잘못된 Viewstate 문제에 대한 정답을 가지고 있습니다. 앱 풀이 재활용되고 암호화 키를 변경하는 것일 수 있습니다.

지원을 받으려면 다음 게시물을 참조하십시오.

.NET 응용 프로그램의 비정상적인 잘못된 Viewstate 문제

ASP .Net Membership을 사용하여 사용자 로그인 지속성 만들기

---

잘못된보기 상태는 로거, 사용자 또는 웹 사이트에 대한 값이 없으며 최종 사용자는 이러한 오류를 볼 수 없습니다. 이 오류를 방지하려면 Global.ascx에 다음을 추가하십시오 .

void Application_Error(object sender, EventArgs e)
    {          
                if (ex is HttpException && ex.InnerException is ViewStateException)
                {
                    Response.Redirect(Request.Url.AbsoluteUri);
                    return;
                }
    }

자세한 내용은 다음 링크를 확인하십시오.

https://www.karpach.com/viewstateexception-invalid-viewstate.htm

---

전자에 대해 할 수있는 일이별로 없습니다. 이러한 예외를 포착하고 사용자를 "귀하가 있던 페이지가 만료되었습니다."라는 메시지와 함께 오류 페이지로 이동합니다. 이것은 일반적으로 페이지를 다시 방문하려고 할 때 발생합니다. 이미 데이터를 입력했습니다. "

후자는 UpdatePanels를 사용하는 상당히 큰 페이지에서 가장 많이 봅니다. 페이지로드가 완료되기 전에 사용자가 다시 게시 (또는 콜백) 할 때라고 생각하므로 페이지 끝에 태그가 지정된 모든 자바 스크립트가 아직 실행되지는 않았습니다.

다시 말하지만, 오류 페이지에 적절한 메시지를 표시하는 것 외에는 할 수있는 일이 많지 않습니다.

---

나는 이런 종류의 예외가 내 로그에 던져졌고 여기에 나열된 다른 것들과는 매우 다른 원인이있었습니다. 문제의 일부인 매우 큰 ViewState가 있습니다. 그러나 그것은 다른 문제와 결합하여 이러한 예외를 발생 시켰습니다 (그리고 가끔 IIS에서 잘못된 응답을하기도 함).

내가 작업중인 코드베이스에는 더블 클릭을 방지하는 멋진 코드가 있으며, 그 일부로 모든 버튼 클릭 이벤트의 자바 스크립트에 일부 항목을 추가하여 첫 번째 클릭 후 버튼을 비활성화 한 다음 일반적인 포스트 백을 수행합니다. 그러나 내 버튼 중 일부에는 이미 .NET에서 자동으로 생성 된 포스트 백 호출이 있기 때문에 포스트 백을 호출하는 것이 문제였습니다. 그래서 저는 이중 포스트 백으로 끝났고 그중 하나는 잘못된 ViewState를 가졌습니다. 추가 포스트 백을 제거하면 예외가 중지되었습니다.

I know I should really be drastically decreasing the size of the ViewState, but this is a large legacy code base and a change like that would be very invasive.

---

It's probably not a good idea to ignore this error. In addition to all the above answers you may want to consider looking into how large your viewstate is. A large viewstate can be truncated by a proxy server.

If your view state is large then it might be a good idea to use a ASP.net trace to see what controls are using viewstate, and where you can turn this off.

---

According to Wayne Walter Berry in this blog post another culprit can be using the XHTML doctype in IE8 without having XHTML compliant markup on the page. This can cause IE8 to send scrambled parameters to scriptresource.axd and throw the invalid viewstate exception.

He recommends making sure all javascript blocks are wrapped with // <![CDATA[]]> or simply changing the doctype (which could cause other css/styling problems on your page).

---

Update: Microsoft announced that the following bug fix for IE 8 fixes this problem:
http://blogs.msdn.com/ieinternals/archive/2010/04/01/IE8-Lookahead-Downloader-Fixed.aspx

ReferenceURL : https://stackoverflow.com/questions/576990/should-i-ignore-the-occasional-invalid-viewstate-error