페이지 간 데이터 전달 모범 사례

페이지 간 데이터 전달 모범 사례

문제

프로젝트 간에 재사용한 스택에서 페이지 간에 데이터를 전달하기 위해 세션에 데이터를 약간 너무 많이 저장하고 있습니다.이것은 변조, 리플레이 공격 등을 방지하기 때문에 이론적으로는 좋았지만, 해결하는 만큼 많은 문제를 발생시킵니다.

세션 손실 자체가 문제이지만 대부분 세션 상태 서버를 구현하거나 SQL 서버를 사용하여 처리됩니다.더 중요한 것은 뒤로 버튼이 올바르게 작동하도록 만드는 것이 까다롭다는 것입니다. 또한 사용자가 세 개의 탭에서 동일한 화면을 열어 서로 다른 레코드를 작업할 수 있는 상황을 만드는 것도 추가 작업입니다.

그리고 그것은 빙산의 일각에 불과합니다.

대부분의 문제에 대한 해결 방법이 있지만, 제가 계속 노력하면서, 이 모든 마찰은 세션을 사용하여 페이지 간에 데이터를 전달하는 것이 잘못된 방향이라는 느낌을 줍니다.

여기서 제가 정말 하고 싶은 것은 제 상점에서 페이지 간에 데이터를 항상 전달하는 데 사용할 수 있는 모범 사례를 생각해 내는 것입니다. 그런 다음 새 앱의 경우 현재 세션에 의존하고 있는 스택의 주요 부분을 교체하십시오.

또한 최종 해결책으로 보일러 플레이트 배관 코드가 산더미처럼 쌓이지 않는다면 좋을 것입니다.

제안된 솔루션

세션

위에서 언급한 바와 같이 세션에 많이 기대는 것은 좋은 생각인 것 같지만, 뒤로 버튼이 끊어져서 다른 문제가 발생합니다.

모든 문제를 해결할 수 있는 방법이 있을 수 있지만, 그것은 많은 추가 작업으로 보입니다.

세션을 사용할 때 한 가지 좋은 점은 조작이 문제가 되지 않는다는 것입니다.암호화되지 않은 QueryString을 통해 모든 것을 전달하는 것에 비해 가드 코드를 훨씬 적게 작성하게 됩니다.

교차 페이지 게시

사실 저는 이 옵션을 거의 고려하지 않았습니다.이전 페이지를 수행하기 시작하면 페이지가 얼마나 밀접하게 연결되는지에 문제가 있습니다.FindControl("SomeTextBox")은 SomeTextBox라는 컨트롤이 없는 다른 페이지에서 이 페이지로 이동하려는 경우 유지 관리 문제처럼 보입니다.

그것은 다른 면에서도 제한적으로 보입니다.예를 들어, 저는 링크를 통해 그 페이지에 가고 싶습니다.

쿼리 문자열

저는 현재 예전처럼 이 전략에 기울고 있습니다.하지만 저는 아마도 제 쿼리 문자열을 암호화하여 조작하기 어렵게 하고, 재생 공격 문제도 처리하고 싶습니다.

롤라에서 온 4명의 남자들에게 이것에 대한 기사가 있습니다.

그러나 이 모든 것을 처리하고 페이지에서 모든 암호화 소시지 만들기를 제거하는 HttpModule을 만들 수 있어야 합니다.아니나 다를까, Mads Kristensen은 그가 발표한 기사를 가지고 있습니다.하지만, 그 논평은 매우 일반적인 시나리오에 문제가 있는 것처럼 들립니다.

기타 옵션

물론 이것은 옵션에 대한 철저한 검토가 아니라 제가 고려하고 있는 주요 옵션입니다.이 링크에는 더 완전한 목록이 포함되어 있습니다.쿠키와 캐시와 같이 언급하지 않은 것들은 페이지 간에 데이터를 전달하는 데 적합하지 않습니다.

마감 중...

그렇다면, 페이지 간에 데이터를 전달하는 문제를 어떻게 처리하고 있습니까?어떤 숨겨진 문제를 해결해야 했으며, 이 문제를 완벽하게 해결할 수 있는 기존 툴이 있습니까?완전히 만족스러운 솔루션이 있다고 생각하십니까?

잘 부탁드립니다!

업데이트: 예를 들어, '페이지 간 데이터 전달'을 통해 고객 전달과 같은 정보를 충분히 이해하지 못하는 경우에 대비합니다.CustomerSearch.aspx 페이지에서 Customer.aspx로 이동하는 ID 키. 여기서 CustomerSearch.aspx를 열고 편집할 수 있습니다.

첫째, 여러분이 다루고 있는 문제는 상태가 없는 환경에서 상태를 처리하는 것과 관련이 있습니다.당신이 겪고 있는 어려움은 새로운 것이 아니며 아마도 윈도우 개발이나 실행 파일 개발보다 웹 개발을 더 어렵게 만드는 것들 중 하나일 것입니다.

웹 개발과 관련하여, 제가 알기로는 사용자별 상태를 처리하는 데 다섯 가지 선택권이 있으며, 이 모든 것을 서로 조합하여 사용할 수 있습니다.어떤 솔루션도 모든 것에 효과가 없다는 것을 알게 될 것입니다.대신 각 솔루션을 사용할 시기를 결정해야 합니다.

• 쿼리 문자열 - 쿼리 문자열은 데이터(예: 기본 키 값) 또는 상태 값에 포인터를 전달하는 데 유용합니다.쿼리 문자열 자체는 재생으로 인해 암호화되더라도 안전하다고 가정해서는 안 됩니다.또한 일부 브라우저에서는 URL 길이에 제한이 있습니다.그러나 쿼리 문자열은 책갈피로 지정하여 사용자에게 전자 메일로 보낼 수 있으며 다른 항목과 함께 사용하지 않으면 본질적으로 상태 비저장이라는 몇 가지 이점이 있습니다.

• 쿠키 - 쿠키는 특정 사용자를 위해 매우 적은 양의 정보를 저장하는 데 유용합니다.문제는 쿠키에도 크기 제한이 있기 때문에 사용자 지정 데이터를 쿠키에 넣을 때 주의해야 합니다.또한 사용자는 쿠키를 죽이거나 사용을 중지할 수 있습니다(하지만 표준 세션 사용은 금지됩니다).쿼리 문자열과 유사하게, IMO는 데이터가 작지 않은 한 데이터 자체보다 데이터에 대한 포인터가 더 좋습니다.

• 양식 데이터 - 양식 데이터는 많은 정보를 사용할 수 있지만, 게시 시간과 경우에 따라 다시 로드 시간이 필요합니다. ASP.NET의 ViewState는 숨겨진 양식 변수를 사용하여 정보를 유지합니다.ViewState와 같은 것을 사용하여 페이지 간에 데이터를 전달하는 것은 뒤로 단추와 더 잘 작동하는 장점이 있지만 사용자의 경험을 느리게 하는 방대한 페이지를 쉽게 만들 수 있습니다.일반적으로 ASP.NET 모델은 교차 페이지 게시에서 작동하지 않고(가능하지만) 동일한 페이지로 다시 이동하고 다음 페이지로 이동하는 게시물에서 작동합니다.

• 세션 - 세션은 사용자가 진행 중인 프로세스와 관련된 정보 또는 일반 설정에 적합합니다.데이터베이스에서 서버 메모리 또는 로드 시간을 희생하여 상당한 양의 정보를 세션에 저장할 수 있습니다.개념적으로 세션은 메모리 또는 상태 서버에서 사용자의 전체 데이터를 한 번에 로드하는 방식으로 작동합니다.즉, 데이터 집합이 매우 큰 경우 세션에 넣지 않을 수 있습니다.세션은 사용자가 실제로 수행하려는 작업과 비교해야 하는 몇 가지 뒤로 단추 문제를 발생시킬 수 있습니다.일반적으로 뒤로 단추가 웹 개발자의 골칫거리가 될 수 있습니다.

• 데이터베이스 - 마지막 솔루션(다른 솔루션과 함께 사용할 수 있음)은 데이터베이스의 정보를 해당 스키마에 항목의 상태를 나타내는 열과 함께 저장하는 것입니다.예를 들어, 주문 작성을 처리하는 경우 주문이 실제 주문인지 여부를 결정하는 "상태" 열과 함께 주문 테이블에 저장할 수 있습니다.쿼리 문자열 또는 세션에 순서 식별자를 저장할 수 있습니다.웹 사이트는 사용자가 주문이 완료되었다고 선언하고 주문 상태가 실제 주문으로 표시될 때까지 계속해서 테이블에 데이터를 기록하여 다양한 부품 및 하위 항목을 업데이트합니다.이로 인해 보고서와 쿼리는 모두 "실제" 항목과 진행 중인 항목을 구별해야 한다는 점에서 복잡해질 수 있습니다.

이후 링크에서 언급된 항목 중 하나가 응용프로그램 캐시였습니다.애플리케이션 범위가 넓기 때문에 저는 이것이 사용자별이라고 생각하지 않습니다.(분명히 사용자별로 구분할 수 있지만 저도 권장하지 않습니다.)저는 HttpContext에 데이터를 저장하는 것을 핸들러나 모듈에 전달하는 것 외에는 해본 적이 없지만, 위에 언급된 솔루션과 다른지 의심스러울 것입니다.

일반적으로, 그들 모두를 지배할 수 있는 하나의 해결책은 없습니다.가장 좋은 방법은 사용자가 다른 페이지의 링크를 사용하여 해당 페이지로 이동했다고 가정하는 것과 달리 각 페이지에서 해당 페이지로 이동할 수 있다고 가정하는 것입니다.이렇게 하면 뒤로 단추 문제를 처리하기가 쉬워집니다(아직은 귀찮지만).제가 개발할 때는 처음 4개를 광범위하게 사용하고 필요할 때는 마지막 솔루션을 사용하기도 합니다.

좋아요, 그래서 저는 이것으로 제 대답을 서문을 쓰고 싶습니다.토마스는 신선하게 시작하는 사람들을 위해 지금까지 가장 정확하고 포괄적인 답을 분명히 가지고 있습니다.이 대답은 전혀 같은 맥락이 아닙니다.제 대답은 "비즈니스 개발자"의 관점에서 나온 것입니다.우리 모두가 너무 잘 알고 있듯이, 때때로 돈을 들여 이미 존재하는 것을 다시 쓰는 것은 실현 가능하지 않습니다. 적어도 한 번의 촬영에서 모두가 작동하는 것은 아닙니다.때로는 시간이 지남에 따라 더 나은 대안으로 마이그레이션할 수 있는 솔루션을 구현하는 것이 가장 좋습니다.

토마스가 빠진 유일한 것은 클라이언트 쪽 자바스크립트 상태입니다.제가 일하는 곳에서는 고객들이 "Web 2.0" 유형의 애플리케이션을 점점 더 기대하고 있다는 것을 알게 되었습니다.또한 이러한 종류의 애플리케이션은 일반적으로 훨씬 더 높은 사용자 만족도를 제공합니다.WCF에서 구현된 JSON 기반 REST 서비스와 통신하는 jQuery와 같은 정말 훌륭한 Javascript 라이브러리의 도움은 사소한 것일 수 있습니다.이 접근 방식은 또한 SOA 기반 아키텍처로 전환하고 UI와 비즈니스 로직을 깔끔하게 분리할 수 있는 매우 좋은 방법을 제공합니다.

하지만 나는 주제에서 벗어났군.

이미 애플리케이션을 보유하고 있으며 ASP.NET의 기본 제공 세션 상태 관리의 한계를 이미 확장한 것처럼 들립니다.그래서... 제가 제안하는 것은 (이미 ASP.NET의 프로세스 내/온박스 세션 관리보다 확장성이 훨씬 뛰어나다는 가정하에) NCache입니다.

NCache는 ASP.NET의 세션 관리 옵션에 대한 "드롭인" 대체 기능을 제공합니다.구현이 매우 쉬우며, 기존 코드베이스를 즉시 리팩터링하는 데 큰 투자를 하지 않아도 애플리케이션을 충분히 "밴드 에이드"할 수 있습니다.

추가 시간과 비용을 사용하여 새로운 접근 방식(예: 다른 답변에 제시된 대안 또는 나의 대안)을 사용하여 즉각적인 비즈니스 가치가 있는 것에 새로운 개발을 집중함으로써 기술 부채를 줄이기 시작할 수 있습니다.

그냥 제 생각입니다.

몇 달 후, 저는 이 질문이 아주 잘 해결되었기 때문에 제가 사용하게 된 기술로 이 질문을 업데이트할 것이라고 생각했습니다.

더 많은 세션 상태 처리(이로 인해 뒤로 단추가 많이 깨지는 등)를 실행한 후 암호화된 쿼리 문자열을 처리하기 위해 제 코드를 굴렸습니다.큰 성공을 거두었습니다. 모든 문제 시나리오(뒤로 버튼, 여러 탭이 동시에 열림, 세션 손실 상태 등)가 해결되었으며 사용법이 매우 익숙하기 때문에 복잡성은 최소화되었습니다.

이것은 여전히 모든 것을 위한 마법의 총알은 아니지만, 저는 여러분이 마주치는 시나리오의 약 90%에 좋다고 생각합니다.

세부 사항

저는 페이지를 계승하는 CorePage라는 클래스를 만들었습니다.SecureRequest 및 SecureRedirect라는 메서드가 있습니다.

전화해 보세요.

 SecureRedirect(String.Format("Orders.aspx?ClientID={0}&OrderID={1}, ClientID, OrderID)

CorePage는 QueryString을 구문 분석하여 CoreSecure라는 QueryString 변수로 암호화합니다.따라서 실제 요청은 다음과 같습니다.

주문.aspx?CoreSecure=1IHXaPzUCYrdmWPkkkuThEes%2fIs4l6grKaznFGAeDDI%3d

사용 가능한 경우 현재 로그인한 사용자암호화 키에 ID가 추가되므로 재생 공격은 큰 문제가 되지 않습니다.

여기서 다음 전화를 걸 수 있습니다.

X = SecureRequest("ClientID")

결론

익숙한 구문을 사용하여 모든 것이 원활하게 작동합니다.

지난 몇 달 동안 저는 다운로드를 트리거하는 하이퍼링크와 같은 에지 케이스와 함께 작동하도록 이 코드를 조정했습니다. 때로는 보안 쿼리 문자열이 있는 클라이언트에서 하이퍼링크를 생성해야 합니다.정말 잘 작동합니다.

이 코드를 보고 싶으시면 알려주시면 제가 어딘가에 올려놓겠습니다.

마지막으로 생각해 보겠습니다. 다른 사람들이 여기에 올린 매우 사려 깊은 게시물 중 일부에 대해 제 자신의 대답을 받아들이는 것은 이상하지만, 이것이 제 문제에 대한 궁극적인 답인 것 같습니다.저를 그곳에 데려다 주신 모든 분들께 감사드립니다.

위의 모든 시나리오와 답변 및 이 링크 데이터 페이싱 방법을 검토한 후 최종 조언은 다음과 같습니다.

쿠키:

• 암호화[userId]
• 암호화[productId]
• 암호화]
• 암호화[등]

데이터베이스:

• 쿠키 ID별 데이터 세트
• 쿠키 ID별 데이터 테이블
• 쿠키 ID별 다른 모든 큰 청크

제 조언은 또한 아래 통계에 따라 달라지며 이 링크는 데이터 페이징 방법에 대해 자세히 설명합니다.

난 절대 이러지 않을 겁니다.사용자 쿠키를 기반으로 모든 세션 데이터를 데이터베이스에 저장하는 데 문제가 있었던 적은 없습니다.그것은 무엇에 관한 한 세션이지만, 저는 그것에 대한 통제권을 유지합니다.세션 데이터에 대한 제어 권한을 웹 서버에 포기하지 마십시오...

약간의 작업으로 하위 세션을 지원하고 다른 탭/창에서 멀티태스킹을 허용할 수 있습니다.

우선 고객 ID와 같은 중요한 데이터 요소를 사용하는 것이 쿼리 문자열에 가장 적합하다는 것을 알게 되었습니다.이러한 요소에서 발생하는 불량 데이터를 쉽게 추적/필터링할 수 있으며, 전자 메일 또는 기타 관련 사이트/응용 프로그램과의 통합도 가능합니다.

이전 애플리케이션에서는 애플리케이션에 로그인하거나 해당 직원을 검색하거나 최근 레코드를 검색하여 문제의 레코드를 찾는 방법밖에 없었습니다.이는 관련 부서의 누군가가 감사 목적으로 기록에 대한 간단한 보기를 수행해야 할 때 문제가 되었고 큰 시간이 소요되었습니다.

다시 작성할 때 "ViewEmployee.aspx?"라는 기본 URL을 통해 직원 ID와 요청 ID를 모두 사용할 수 있도록 했습니다.ID=XXX" 및 "ViewRequest.aspx?ID=XXX".A) 잘못된 ID 및 B) 사용자가 이러한 페이지에 액세스할 수 있도록 허용하기 전에 사용자를 인증하고 권한을 부여하도록 응용 프로그램이 설정되었습니다.이를 통해 주로 애플리케이션 사용자들이 할 수 있었던 것은 감사자들에게 이메일에 URL이 포함된 간단한 이메일을 보내는 것이었습니다.그들이 매우 급할 때, 대량 처리 시간에 있을 때, 그들은 URL 목록을 클릭하고 적절한 처리를 할 수 있었습니다.

수정 날짜 및 사용자와 응용 프로그램의 상호 작용 상태 유지와 같은 다른 세션 관련 데이터는 조금 더 복잡해지지만, 이것이 여러분에게 출발점이 되기를 바랍니다.

언급URL : https://stackoverflow.com/questions/3207611/best-practices-for-passing-data-between-pages