context.items[] and postback

[meeps]

I don't want to use querystrings and i was trying to get away from using session variables, so i was quite interested when I read about passing parameters by using Context.Items[] and Server.Transfer(). But when I tried it I saw that the value passed to the 2nd page is only available if no postback has been executed. Is there any way to keep the value around after a postback or am I back to session variables? thanks.

[meeps]

a few minutes after i posted this i thought of how to do it: store the Context.Items value in a hidden field. Do any of you use this method? Problems with it?

 

thanks

[Derek Stone]

Why don't you just store the value directly into the hidden form field in the first place? I don't see why Context.Items even needs to come into play.

[meeps]

I want to pass the value from one page to another. I thought I had to put the value in Context.Items and then use

 

Server.Transfer("nextpage.aspx");

 

so that the value would be available to the new page. Are you saying there's a way to do that by just using hidden fields?

[Derek Stone]

It all depends on how the second page is requested from the first. If the first page is being posted to the second then there is no need for Context.Items, and a hidden form field can be used quite nicely. However if the first page can only use Server.Transfer to request the second page (if so you need to ask yourself why this is, since it is the bigger issue) then a form would never be made available to the client to post, and the data would never be transfered.

 

You need to thoroughly explain how things work within this portion of your application before we can help you out any further.

[meeps]

I'm new to web apps and don't really know what you mean when you say "if the first page is being posted to the second." Here's what I'm trying to do:

 

there's a page with info from a database record on it. clicking a button brings you to a new page that allows you to edit the info. the edit page needs to know the idno of the record you were just looking at.

 

It's a bit more complicated than that, but that's the general idea. The first method I tried was to use response.redirect but the only way I knew of to pass the idno to the second page was to use session variables or url querystrings, which I don't want to use. That's why I started looking into server.transfer and context.items. If there is a simpler and/or better way can you please explain it to me?

 

thanks for your help.

[Derek Stone]

The simple way would be to just use query strings. Applications like this are exactly what they were designed for. For whatever reason you have stated that you don't want to use them, however I don't foresee myself passing along advice to do things the incorrect way. If you want to use Context.Items and Server.Transfer then so be, do just that.

 

Context.Items.Add("variable", "value")

Server.Transfer("page.aspx", True)

[meeps]

The reason I don't want to use querystrings is because some idno values are off limits to some users. I don't want a user to be able to type in random idno values in the url and get a record they are not allowed to access. There are also other values being passed that I'd like to keep behind the scenes as well. I looked into encrypting the querystring, but the context.items method seemed simpler. Since you say this is the incorrect way, how would you do it? Are there disadvantages to using server.transfer other than it is not as simple as url querystrings? Thanks for all of your help. I appreciate it.

[Derek Stone]

If you honestly think obscuring ID numbers can be considered security then I really hope you re-evaluate your security policy sometime soon. I say this with the best intentions: you're going to get bit in the rear if you don't.

 

You should be using query strings AND checking upon each and every page request that the user has the correct level of authorization to access the resource. Doing it any other way is risking usability and security.

 

Tough answer, I know, but you might just thank me someday. :)