title: Best Practices for Passing Data Between Pages
body: <p><strong>The Problem</strong></p>
  
  <p>In the stack that we re-use between projects, we are putting a little bit too much data in the session for passing data between pages. This was good in theory because it prevents tampering, replay attacks, and so on, but it creates as many problems as it solves.</p>
  
  <p>Session loss itself is an issue, although it's <em>mostly</em> handled by implementing Session State Server (or by using SQL Server). More importantly, it's tricky to make the back button work correctly, and it's also extra work to create a situation where a user can, say, open the same screen in three tabs to work on different records.</p>
  
  <p>And that's just the tip of the iceberg.</p>
  
  <p>There are workarounds for most of these issues, but as I grind away, all this friction gives me the feeling that passing data between pages using session is the wrong direction.</p>
  
  <p>What I really want to do here is come up with a best practice that my shop can use all the time for passing data between pages, and then, for new apps, replace key parts of our stack that currently rely on Session.</p>
  
  <p>It would also be nice if the final solution did not result in mountains of boilerplate plumbing code. </p>
  
  <p><strong>Proposed Solutions</strong></p>
  
  <p><em>Session</em></p>
  
  <p>As mentioned above, leaning heavily on Session <em>seems</em> like a good idea, but it breaks the back button and causes some other problems. </p>
  
  <p>There may be ways to get around all the problems, but it seems like a lot of extra work. </p>
  
  <p>One thing that's very nice about using session is the fact that tampering is just not an issue. Compared to passing everything via the unencrypted QueryString, you end up writing much less guard code. </p>
  
  <p><em>Cross-Page Posting</em></p>
  
  <p>In truth I've barely considered this option. I have a problem with how tightly coupled it makes the pages -- if I start doing PreviousPage.FindControl("SomeTextBox"), that seems like a maintenance problem if I ever want to get to this page from another page that maybe does not have a control called SomeTextBox.</p>
  
  <p>It seems limited in other ways as well. Maybe I want to get to the page via a link, for instance.</p>
  
  <p><em>QueryString</em></p>
  
  <p>I'm currently leaning towards this strategy, like in the olden days. But I probably want my QueryString to be encrypted to make it harder to tamper with, and I would like to handle the problem of replay attacks as well.</p>
  
  <p>On 4 guys from Rolla, <a href="https://web.archive.org/web/20210125142425/https://www.4guysfromrolla.com/articles/083105-1.aspx" rel="noreferrer">there's an article about this</a>. </p>
  
  <p>However, it should be possible to create an HttpModule that takes care of all this and removes all the encryption sausage-making from the page.  Sure enough, <a href="http://madskristensen.net/post/HttpModule-for-query-string-encryption.aspx" rel="noreferrer">Mads Kristensen has an article where he released one.</a> However, the comments make it sound like it has problems with extremely common scenarios.</p>
  
  <p><strong>Other Options</strong></p>
  
  <p>Of course this is not an exaustive look at the options, but rather the main options I'm considering. <a href="http://msdn.microsoft.com/en-us/magazine/cc300437.aspx#S6" rel="noreferrer">This link</a> contains a more complete list. The ones I didn't mention such as Cookies and the Cache not appropriate for the purpose of passing data between pages. </p>
  
  <p><strong>In Closing...</strong></p>
  
  <p>So, how are you handling the problem of passing data between pages? What hidden gotchas did you have to work around, and are there any pre-existing tools around this that solve them all flawlessly? <em>Do</em> you feel like you've got a solution that you're completely happy with?</p>
  
  <p>Thanks in advance!</p>
  
  <p><strong>Update:</strong> Just in case I'm not being clear enough, by 'passing data between pages' I'm talking about, for instance, passing a CustomerID key from a CustomerSearch.aspx page to Customers.aspx, where the Customer will be opened and editing can occur.</p>