Take the 2-minute tour ×

I want to transfer some data from one ASP.NET (WebForms) application to another, edit: where the first application redirects to the second. The two applications run in a load-balanced environment, so don't necessarily execute on the same server machine. We are talking about an XML blob in the size range a few hundred to maybe a thousand bytes, so it's a bit long for encoding and tacking it into the URL query-string. The user must also not be able to muck with this data (it's not security-critical currently, but exposing it to the user still seems like a bad idea).

Any suggestions on how to do it?

share|improve this question
add comment

7 Answers

I don't know all the details of your situation, but there are a few ways you could do this.

  1. You could insert the XML blob into a database from one site and retrieve it from the database from the other site.

  2. You could post your XML blob from one application to a receiver page in the other application which would then read the XML from the request.

  3. You could create a webservice in the second application with a method to receive the XML blob from the fist application.

  4. You could write the XML to file in one application and read it from file in the second application.

share|improve this answer
#4 is definitely out because of the load balancing as well as usage (way too high risk of race conditions). –  Michael Kjörling Mar 9 '12 at 13:22
add comment

Just a quick idea off the top of my head...

If the data is entirely specific to the current user's session, and the two sites are running on the same domain.

  1. Generate a key for the client - something that is going to be reasonably unique, for instance something like md5(some guid + some header from the user's browser)

  2. Store the information in a key value store/database table, with the generated key from 1 as the key.

  3. Set the key as a cookie to the client.

This way you avoid ever sending the data to the client, and the 'key' should be random enough that it will be very hard to guess. If you also store the header and the GUID that you use to generate/salt the hash, you can then validate the key from the user's cookie against the headers sent in the request and deny access if all the details don't match up. This also has the benefit that you can store as much data as you can realistically cope with on the server side.

share|improve this answer
add comment

You will probably want to look into either or .NET Web Sevices or WCF (Windows Communication Foundation).

share|improve this answer
add comment

Store it in an encrypted cookie, You'll only add 1Kb to each request/response.

share|improve this answer
OP says 'The user must also not be able to muck with this data'. Sticking it in a cookie would allow access to the data using Firebug etc. –  mdm Mar 9 '12 at 13:32
add comment

Maybe like a SSO or something like that.

In a database, a table with those columns:
Guid (Guid.NewGuid())
(maybe other columns like the user id...for security log)

The first webapp send the Guid through the URL. The second retrieve the Content in the database.

The date can be used to validate the data: you can only access to the content within X seconds.

share|improve this answer
add comment

Should be fairly easy using cross site requests.

The first application should just return a page containing a form with the Action parameter pointing to the other application's url. The page should also contain a small javascript to postback the form as soon as the page is loaded. The body of the page contains the data you want to pass between servers.

This way you are using client's browser to do the job for you. Because page's body can be much longer than uri/cookie, this approach should work for you.

Note, that this is completely legal and at least few passive authentication protocols rely on such possibility.

Edit: The integrity of the data is achieved with cryptography. The data can be signed (the simplest approach) or encrypted+signed (which not only prevents users from modyfing the data but also from seeing the content).

Also note that if you don't have to involve client browser, you can use any communication protocol to pass the data directly between servers (TCP, HTTP).

share|improve this answer
How would you stop a malicious user from seeing the data, if it is sent to the browser? –  mdm Mar 9 '12 at 13:34
You can encrypt it or even sign it to validate at the receiver side. –  Wiktor Zychla Mar 9 '12 at 14:22
add comment
up vote 0 down vote accepted

Thanks to all who responded! In talking this over with some other people at the office, in the end we decided that, since the data is actually made available by yet another web application, both of the applications that make use of the data will simply make a call to the third to get the data. The downside to that approach is the small amount of time it takes to make that call twice; the upside is that it virtually ensures that the two applications always have up-to-date data, and even a naïve implementation makes it very difficult for the end user to do anything with the data.

share|improve this answer
add comment

Your Answer


