Passing Objects Through QueryString

Question

I have an object A, which in turn has a property of type Object B

Class A property x as Object B End Class 

On my ASP.NET page, when I select a gridview element that maps to an object of type A, I serialize the object to a QueryString and pass it to the next page.

However, I ran into problems if the x property really does matter, since it looks like I'm exceeding the length of the QueryString 4k capacity (although I did not think the objects were so big)

I have already considered the following approaches for this.

• Session Variables

The approach is not used, as I read that this is bad practice.

• Using a unique key for an object and obtaining it on the next page.

The approach is not used, since objects are not mapped to a single instance in the table; they consist of data from different databases.

So, I think my question is double

• Is it worth using GKZip to further compress the request (is this possible?)
• What other methods would suggest doing this?

Answer 1

If displaying the URL of the next page in the browser does not matter, you can use the context.items collection.

 context.items.add("keyA", objectA) server.transfer("nextPage.aspx") 

Then on the next page:

 public sub page_load(...) dim objectA as A = ctype(context.items("keyA"), objectA) dim objectB as B = objectA.B end sub 

One reason to use this is because you want users to believe that the next page is indeed part of the first page. For them, it only looks like a PostBack.

In addition, you do not need a unique key using this approach if the only way to use the “next page” is if you first came from the “first page”. The scope for collections of contextual elements is specific only to this particular request.

I agree with other posters that mentioned that serialized objects in querystring are far worse evil than using session state. If you are using session state, just remember to clear the key that you use immediately after using it.

Answer 2

I do not understand why you would not use the session state, but ...

Option 1: Viewstate

Option 2: form parameters instead of request

But also remember that you do not return the same object when serializing / deserializing. You get a new object initialized with the original values ​​that were serialized. You will get two objects.

EDIT: you can store values ​​in viewstate using the same syntax as session state

ViewState ["key"] = val;

The value should be serializable, though.

Answer 3

While storing objects in a session can be considered bad practice, it is easier than passing them through serialized queries.

Back in classic asp, storing objects in a session was considered bad practice because you created a thread binding and limited the ability to scale the site by adding other web servers. This is no longer an issue with asp.net (if you are using an external state server).

There are other reasons to avoid session variables, but in your case, I think the way to go.

Another option is to combine 2 pages that need access to this object onto one page, using panels to hide and display the necessary "subpages" and use the viewstate to store the object.

Answer 4

I don’t think that passing it to the query string or storing it in a session is a good idea.

You need one of the following:

a) The caching layer. Something like Microsoft Velocity will work, but I doubt that you need something on this scale.

b) Put the keys to each object in the databases that you need in the query string, and return them next time. (For example, myurl.com/mypage.aspx?db1objectkey=123&db2objectkey=345&db3objectkey=456)

Answer 5

Using session state seems like the most practical way to do this, exactly what it is for.

Answer 6

Cache is probably not the answer either. As Telos said, I'm not sure why you are not considering the session.

If you have a page that depends on the availability of this data, then you simply throw a security offer into the page loading ...

 public void Page_Load() { if(!IsPostBack) { const string key = "FunkyObject"; if(Session[key] == null) Response.Redirect("firstStep.aspx"); var obj = (FunkyObject)Session[key]; DoSomething(obj); } } 

If the session is completely excluded from quesiton, you will have to re-materialize this object on another page. Just send a unique identifier to querystring so you can return it back.

Answer 7

That's what I'm doing:

Page1.aspx - Add a public instance property of my object. Add a button (Button1) with the PostBackURL property equal to ~ / Page2.aspx

 Private _RP as ReportParameters Public ReadOnly Property ReportParams() as ReportParameters Get Return _RP End Get End Property Protected Sub Button1_Click(ByVal sender As Object, ByVal e As EventArgs) Handles Button1.Click _RP = New ReportParameters _RP.Name = "Report 1" _RP.Param = "42" End Sub 

Now, on the second page, page2.aspx, add the following to the markup at the top of the page according to the first directive:

 <%@ PreviousPageType VirtualPath="~/Default.aspx" %> 

Then for Page_Load in the code behind Page2.aspx, add the following

 If Not Page.PreviousPage is Nothing Then Response.write (PreviousPage.ReportParams.Name & " " & PreviousPage.ReportParams.Param) End If 

Answer 8

Session is not always available. For example, when the XSS (cross-site scripting) security settings in IE prevent the storage of third-party cookies. If your site is called in an IFrame from a site that is not your DNS domain, your cookies will be blocked by default. No cookies = no session.

Another example: you need to transfer control to another site that will make the callback on your site a pure URL, not mail. In this case, you need to save the session parameters in the querystring parameter, which is very difficult to do, given the 4k size limit and URL encoding, not to mention encryption, etc.

The problem is that most of the built-in serialization methods are pretty detailed, so you have to resort to the roll-your-own method, possibly using reflection.

Another reason not to use sessions is simply to improve user experience; Sessions are cleared after N minutes and upon server restart. Well, in this case viewstate is preferable, but sometimes it is impossible to use a form. Well, one could use JavaScript for postback, but again, this is not always possible.

These are the problems that I am currently coding.

Answer 9

Faced with a similar situation, I had XML serialize the object and pass it as a query string parameter. The difficulty with this approach was that, despite coding, the receiving form throws an exception saying "a potentially dangerous request ...". The way I got around was to encrypt the serialized object and then encode it to pass it as a query string parameter. This, in turn, made evidence of fake query strings (a bonus wandering around the HMAC)!

FormA XML serializes the object> encrypts the serialized string> encode> pass as the query string to FormB FormB, decrypts the value of the query parameter (like the request.querystring decoder)> deserializes the resulting XML string to the object using XmlSerializer.

I can share my VB.NET code on demand with how Ididit-at-applecart-dot-net