Recently I had the chance to migrate a Forefront Threat Management Gateway 2010 RC environment over to the TMG 2010 RTM SP1. The RC had been developing some issues and it was time to install with the full produciton release. The server was only needed for reverse proxy for a SharePoint implementation.
Our users access SharePoint sites and our InfoPath form in 1 of 3 different ways:
Via the Intranet: http://sharepoint.mycompany.com
Via the Extranet: http://sharepoint.mycompany.com
Via the TMG 2010 Server: https://sharepoint.mycompany.com
The form is set to domain trust, published from InfoPath as a site content type and associated with a SharePoint document library (browser compatible) at https://sharepoint.mycompany.com
After setting up TMG and verifying that people could access the sites externally and internally I turned to testing the functionality of the site and the forms located within.
When accessing externally I noticed that approving published documents tied to the workflow would generate an InfoPath error stating "The form cannot be submitted to the Web server either because your computer is offline or because the host server is currently unavailable. If this problem persists, contact your network administrator." Internally the forms would work flawlessly, but that was due to TMG only handling the external traffic.
This was perplexing because it worked in the previous RC version of TMG. Now it was time for troubleshooting SharePoint and how the TMG communicated the host headers when accessing the forms.
After some looking and testing I noticed on closing the form users were then redirected to https://sharepoint.intranet (the URL that the form is published to in InfoPath) which of course they could not access. I looked around on the Internet and found some articles on this exact problem but they were relating to ISA Server 2004 and 2006.
If these domain strings in "g_objCurrentFormData" don't exactly match the domain in which the form is being viewed, **including the https!** then the submit will be blocked (....browser-level prevention of cross-domain shennanigans, I suppose.)
Oddly enough the forward slashes are encoded by InfoPath as u002f.... in case you didn't guess.
Running Fiddler before and after the Link Translation Rule was defined showed....
No Fiddler traffic on submit.
A POST to the SharePoint domain on submit!
Create a link translation in your Rule for your published SharePoint site with the InfoPath form.
Also leaving the
So you should show both entries in your link translation.
Skybyte Consulting is Chicago's premiere IT consulting firm. We provide local area network design, disaster recovery solutions, Cisco IP Phone Support, Cisco ASA Firewall support, Checkpoint support, VPN installation, (SAN) storage area network support and much more!