tags:

views:

103

answers:

4

I am trying to replicate a browser page to another browser on another machine. I basically want to reproduce a page exactly how it appears to a customer for viewing by the website owner. I have done this before using some impersonation trickery, but found that it would throw the session state out of wack when the site owner would switch customers. So I would like to stay away from cookie and authentication manipulation.

Anybody done anything like that? Is there a way to easily transfer the DOM to a webservice?

The tech/programming at my disposal are C#, javascript, WCF.

A: 

If session state is getting messed up when the site owner changes customer roles, your implementation might be the problem. I'd probably try fixing how your session management is working before solving a problem which is really a sympton of a deeper problem IMO.

jagprinderdeep
A: 

Is sending image an option? If that is an option, you can use IECapt program to take screenshot of that image and send it to the other machine: http://iecapt.sourceforge.net/

Holystream
A: 

Since you mentioned transferring the DOM to a webservice, I assume you need to inspect the page's source and not just its appearance. I recommend checking this link:

http://www.eggheadcafe.com/community/aspnet/7/10041011/view-source-of-a-web-page.aspx

It was a few suggestions for grabbing a page's source programmatically / screen-scraping.

Of course, a few more details might yield better answers. Specifically, does the customer submit their page to the owner (I imagine a scenario where a user of your site says "Hey, I'm having a problem! Take a look at this...") or is the owner looking at how the page renders when logged-in as a specific customer?

djacobson
A: 

Easiest way is to post the innerHTML of the body tag to your webservice, which your other page can poll (or use comet, or something) to get back. You'll have to be careful to load the right css in your clone page. Also, you'll need to think about how often you want it to update.

This is a bit of a hack though, a better solution would be to have designed the page from the start with this in mind (I'm assuming this is too late now?), so that anything that mutated the page would at the same time send a message back to the server describing what was changed, or if the page is not very interactive, storing the canonical state of the page on the server, and querying that from both browsers with XHRs or similar.

Adam