Page-to-page communication

Posted September 16th, 2011 by Bruce Wilson

I have two pages, both with iParts, which need to communicate with each other. Some of the details I want to communicate are a bit sensitive. It's not credit cards or other personal info, but it could potentially be used to manipulate the system to gain access to records that shouldn't be seen by the current user.

I know the first page can pass parameters to the second page using the URL, but the security is non-existent. Even my mother-in-law can manipulate URL params.

Cookies are invisible to the user and not very easy to manipulate, but have the problem of being global across all browser windows. A user could legitimately have two windows open, and each one should know which item it was asked to work on in a way that isn't affected by opening another window.

What other mechanisms are available in iMIS for saving some information on one page (e.g. the key of the item the user clicked on) so the destination page can make use of it?

I think you basically have 3

On September 16th, 2011 james_schwartz says:

I think you basically have 3 options here: 1) QueryString variables 2) Session variables or 3) Server.Transfer (as well as a combination of techniques)

The QueryString option would work fine but you would want to encrypt the data before setting the querystring variable so that they couldn't manipulate the data or see the data that you are tracking.

Using Session variables is more secure because it only stores the data on the server and the end user isn't exposed to the data. The end user simply gets a cookie set on their computer to identify the session. However, you would still have the same issue whereby a second browser window in the same session might overwrite the data from another session.

So to get around the session issue, you could generate a GUID that you pass through the QueryString which maps to a session variable which would contain the actual data you are looking for. This would resolve the issue of having multiple windows open in the same session. The GUID would ensure that the data you are retrieving is specific to the current window, and passing the GUID through the querystring ensures this.

This is probably more complex than it needs to be. So the last option would be to do a Server.Transfer and set public properties on the source page that would be read on the target page. This ensure that the data is kept on the server (thus you don't need to encrypt it), and it also ensures that the data from page 1 is read on page 2 (so you could have multiple windows open and they wouldn't affect one another).

Here's a good MSDN article with more detail: http://msdn.microsoft.com/en-us/library/6c3yckfw(vs.80).aspx

I would go with the encrypted querystring or the Server.Transfer to keep it simple.

Cheers,

James / Bursting Silver

PS: As you mentioned,

On September 16th, 2011 james_schwartz says:

PS: As you mentioned, Cookies are another option but unnecessary in this particular case and would require some encryption if you want to hide the contents from the user.

PSS: I am assuming that these pages will be accessed sequentially (e.g. the user wouldn't go to page 1, then browse somewhere else, then go back to page 2).

How about some kind of form variables?

On September 20th, 2011 Bruce Wilson says:

The page flow is like this:

Visit Page A (shows list of data for selected ID)
Click one of the items, which leads to Page B
Page B shows information about selected ID based only on the item clicked on Page A.
Click one of the items on Page B, which leads to Page C.
Page C knows which item on Page B was clicked, and shows only data based on (Selected ID + Page A item + Page B item)
Click a "go back" button on Page C. (Not the browser Back button.) This returns to Page B, filtered the same way it was before.

So Page C needs to know the information Page B received from Page A so it can send the user back there later. Referrer may not be reliable, as Page C could also lead to Page D. "Go back" on page C should always lead to Page B, never Page D.

If the user has another browser window open, they could click on different items on pages A and B, and the Page C "go back" button should still do the right thing.

What about some kind of form variables? That is, is there a way for the sending page to load some stuff into form variables which are submitted to the receiving page? I don't want to put them into hidden fields (again, user control), but instead to populate them after the click and before the redirect. Or maybe that's what you mean by System.Transfer?
--
Bruce Wilson
Director, Technical Services
RSM McGladrey, Inc.

Querystring variables are

On September 22nd, 2011 james_schwartz says:

Querystring variables are the easiest way to do it because you can set the URL on each item to have the selected item in the URL (and the link to page C could have 3 parameters: e.g. PageASelectedID, PageBSelectedID and PageCSelectedID).

But if you are worried about the user manipulating the data, the Server.Transfer could do the trick (except you'd have to handle server side click events when the user clicks on an item, which may be easy or not depending on how you are generating the links to the items).

Using Server.Transfer, PageA would have 1 public property called "PageASelectedItem". When the user clicks the item, the code behind will set this public property to the selected item and then perform a Server.Transfer (which is similar to a Response.Redirect, except it allows you to pass class variables). PageB would have 2 public properties (PageASelectedItem and PageBSelectedItem). Similarly when they click the link to go to PageC, PageC would have 3 variables. That would allow the user to go back to PageA or PageB at any time and it would still know which items they selected.

Would this perhaps do the trick?

iMIS Community

Page-to-page communication

Comment viewing options

I think you basically have 3

PS: As you mentioned,

How about some kind of form variables?

Querystring variables are

Navigation

User login