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

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

---

문제

프로젝트간에 재사용하는 스택에서 페이지간에 데이터를 전달하기 위해 세션에 너무 많은 데이터를 넣습니다. 이것은 탬 퍼링, 리플레이 공격 등을 방지하기 때문에 이론 상으로는 좋았지 만 해결되는만큼 많은 문제를 발생시킵니다.

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

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

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

여기서 제가 정말로하고 싶은 것은 내 상점이 페이지간에 데이터를 전달하는 데 항상 사용할 수있는 모범 사례를 제시 한 다음 새 앱의 경우 현재 Session에 의존하는 스택의 핵심 부분을 대체하는 것입니다.

최종 솔루션이 수많은 상용구 배관 코드를 생성하지 않았다면 좋을 것입니다.

제안 된 솔루션

세션

위에서 언급했듯이 Session에 크게 의존 하는 것은 좋은 생각처럼 보이지만 뒤로 버튼이 깨지고 다른 문제가 발생합니다.

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

세션 사용에 대해 매우 좋은 점은 변조가 문제가되지 않는다는 사실입니다. 암호화되지 않은 QueryString을 통해 모든 것을 전달하는 것과 비교하면 가드 코드를 훨씬 적게 작성하게됩니다.

교차 페이지 게시

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

다른 방식으로도 제한적인 것 같습니다. 예를 들어 링크를 통해 페이지로 이동하고 싶을 수도 있습니다.

QueryString

저는 현재 예전처럼이 전략에 기대고 있습니다. 그러나 나는 아마도 내 QueryString을 암호화하여 조작하기 어렵게 만들고 싶을 것입니다. 그리고 재생 공격 문제도 처리하고 싶습니다.

Rolla의 4 명의 남자에 대한 기사가 있습니다.

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

다른 옵션

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

마지막으로 ...

그렇다면 페이지 간 데이터 전달 문제를 어떻게 처리하고 있습니까? 어떤 숨겨진 문제를 해결해야했고이 문제를 완벽하게 해결하는 기존 도구가 있습니까? 완전히 만족하는 솔루션이 있다고 생각 하십니까 ?

미리 감사드립니다!

업데이트 : '페이지 간 데이터 전달'을 통해 명확하지 않은 경우를 대비하여 예를 들어 CustomerSearch.aspx 페이지에서 Customers.aspx로 CustomerID 키를 전달하여 고객이 열릴 것입니다. 편집 할 수 있습니다.

---

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

웹 개발과 관련하여 내가 아는 한 서로 조합하여 사용할 수있는 사용자 별 상태를 처리하기위한 다섯 가지 선택 사항이 있습니다. 모든 것에 대해 하나의 솔루션이 작동하지 않는다는 것을 알게 될 것입니다. 대신 각 솔루션을 사용할시기를 결정해야합니다.

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

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

• 양식 데이터-양식 데이터는 게시 시간과 경우에 따라 다시로드 시간을 희생하여 상당한 정보를 취할 수 있습니다. ASP.NET의 ViewState는 숨겨진 양식 변수를 사용하여 정보를 유지합니다. ViewState와 같은 것을 사용하여 페이지간에 데이터를 전달하면 뒤로 버튼을 사용하여 더 잘 작동하는 이점이 있지만 사용자의 경험을 느리게하는 거대한 페이지를 쉽게 만들 수 있습니다. 일반적으로 ASP.NET 모델은 교차 페이지 게시에서 작동하지 않지만 (가능하더라도) 대신 동일한 페이지로 돌아가서 다음 페이지로 이동하는 게시물에서 작동합니다.

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

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

One of the items mentioned in your later link was Application Cache. I wouldn't consider this to be user-specific since it is application wide. (It can obviously be shoe-horned into being user-specific but I wouldn't recommend that either). I've never played with storing data in the HttpContext outside of passing it to a handler or module but I'd be skeptical that it was any different than the above mentioned solutions.

일반적으로 모든 것을 다룰 수있는 해결책은 없습니다. 가장 좋은 방법은 각 페이지에서 사용자가 어디에서나 해당 페이지로 이동할 수 있다고 가정하는 것입니다 (다른 페이지의 링크를 사용하여 이동했다고 가정하는 것과 반대). 그렇게하면 뒤로 버튼 문제를 처리하기가 더 쉬워집니다 (여전히 고통 스럽지만). 개발 과정에서 처음 4 개를 광범위하게 사용하고 필요에 따라 마지막 솔루션을 사용하기도합니다.

---

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

내가 토마스가 빠졌다고 말할 수있는 유일한 것은; 클라이언트 측 자바 스크립트 상태. 제가 일하는 곳에서는 고객들이 "웹 2.0"유형의 응용 프로그램을 점점 더 많이 기대하고 있다는 사실을 알게되었습니다. 또한 이러한 종류의 응용 프로그램이 일반적으로 사용자 만족도를 훨씬 더 높이는 것으로 나타났습니다. 약간의 연습과 WCF에서 구현 된 JSON 기반 REST 서비스와 통신하는 jQuery (우리는 GWT를 사용하기 시작했고 AWESOME 인 것으로 밝혀 짐)와 같은 정말 훌륭한 자바 스크립트 라이브러리의 도움으로 간단 할 수 있습니다. 이 접근 방식은 또한 SOA 기반 아키텍처로 이동하기 시작하고 UI와 비즈니스 로직을 깔끔하게 분리하는 아주 좋은 방법을 제공합니다.

그러나 나는 빗나 갔다.

이미 응용 프로그램이 있고 이미 ASP.NET의 기본 제공 세션 상태 관리의 한계를 확장 한 것처럼 들립니다. 그래서 ... 여기에 제 제안이 있습니다. 그것); NCache.

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

You can use the extra time and money to start reducing your technical debt by focusing new development on things with immediate business-value - using a new approach (such as any of the alternatives offered in the other answers, or mine).

Just my thoughts.

---

Several months later, I thought I would update this question with the technique I ended up going with, since it has worked out so well.

After playing with more involved session state handling (which resulted in a lot of broken back buttons and so on) I ended up rolling my own code to handle encrypted QueryStrings. It's been a huge win -- all of my problem scenarios (back button, multiple tabs open at the same time, lost session state, etc) are solved and the complexity is minimal since the usage is very familiar.

This is still not a magic bullet for everything but I think it's good for about 90% of the scenarios you run into.

Details

I built a class called CorePage that inherits from Page. It has methods called SecureRequest and SecureRedirect.

So you might call:

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

CorePage parses out the QueryString and encrypts it into a QueryString variable called CoreSecure. So the actual request looks like this:

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

If available, the currently logged in UserID is added to the encryption key, so replay attacks are not as much of a problem.

From there, you can call:

X = SecureRequest("ClientID")

Conclusion

Everything works seamlessly, using familiar syntax.

Over the last several months I've also adapted this code to work with edge cases, such as hyperlinks that trigger a download - sometimes you need to generate a hyperlink on the client that has a secure QueryString. That works really well.

Let me know if you would like to see this code and I will put it up somewhere.

One last thought: it's weird to accept my own answer over some of the very thoughtful posts other people put on here, but this really does seem to be the ultimate answer to my problem. Thanks to everyone who helped get me there.

---

After going through all the above scenarios and answers and this link Data pasing methods My final advice would be :

COOKIES for:

• ENCRYPT[userId's]
• ENCRYPT[productId]
• ENCRYPT[xyzIds..]
• ENCRYPT[etc..]

DATABASE for:

• datasets BY COOKIE ID
• datatables BY COOKIE ID
• all other large chunks BY COOKIE ID

My advise also depends on the below statistics and this link details Data pasing methods :

---

I would never do this. I have never had any issues storing all session data in the database, loading it based on the users cookie. It's a session as far as anything is concerned, but I maintain control over it. Don't give up control of your session data to your web server...

With a little work, you can support sub sessions, and allow multi-tasking in different tabs/windows.

---

As a starting point, I find using the critical data elements, such as a Customer ID, best put into the query string for processing. You can easily track/filter bad data coming off of these elements, and it also allows for some integration with e-mail or other related sites/applications.

In a previous application, the only way to view an employee or a request record involving them was to log into the application, do a search for the employee or do a search for recent records to find the record in question. This became problematic and a big time sink when somebody from a related department needed to do a simple view on records for auditing purposes.

In the rewrite, I made both the employee Id, and request Ids available through a basic URL of "ViewEmployee.aspx?Id=XXX" and "ViewRequest.aspx?Id=XXX". The application was setup to A) filter out bad Ids and B) authenticate and authorize the user before allowing them to these pages. What this allowed the primarily application users to do was to send simple e-mails to the auditors with a URL in the e-mail. When they were in a big hurry, they were in their bulk processing time, they were able to simply click down a list of URLs and do the appropriate processing.

Other session related data, such as modification dates and maintaining the "state" of the user's interaction with the application gets a little more complex, but hopefully this provides a starting poing for you.

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