function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Anand@SAASAnand@SAAS 

Posting to a Visual Force page from an external App

All,

We are trying to capture some POST parameters that are passed from an External Site in a Visual Force page. We cannot do GET due to the client's security compliance policies.

One doing simple test (see code below), we are seeing that the POST parameters is not available when we do "getParameters()" on the Controller. It looks like the "domain" for visual force pages is the reason for this behavior.

Does anyone have a recommendation on what is the best way to accomplish this. Is the domain for the "Visual force pages" fixed per org /instance?

Additional details:
============================
While doing a httpsPost to a visual force page in the dev org I am not able to get the Post parameters even though the VF page is rendered.

This works fine in another sandbox environment where the visual force page remains in the same domain (atleast when seen through the Browser's address bar).

Shown below is the code used to send a Post request to VF page . This is an SControl in the same org.







frameUrl:

Page:

Page:






Upon POST the VF page is rendered with the following URL: https://c.cs2.visual.force.com/apex/Redirect (Domain changed to c.cs2.visual.force.com)

If I try to post directly to the changed domain, I am able to retrieve the POST parameters as shown below:




frameUrl:

Page:

Page:






Let me know whether we can POST directly to the changed domain.If the domain is dynamic it will cause problems.
mtbclimbermtbclimber
All URLs are potentially "dynamic".  For example, as long as the organization has separate domains enabled then a page built and deployed by the customer owning that environment will be served from the url:

c.<instancename>.visual.force.com/apex/<pagename>.

In that URL the customer can only control the pagename variable.  The instance name in your case, "cs2" is the sandbox environment, which depending on customer's process or changes to sandbox could be cs0, cs1, or cs3, etc.

Likewise without separate domains enabled the url pattern, as you have noted is:

<instancename>.salesforce.com .

Again, customers do not control the instance name aspect (salesforce routinely moves customers between instances) and if that changes you would see the same behavior with your scontrol since the net effect is a redirect which in both cases will lose the post parameters.

Basically, any solution that is URL dependent is not going to have additional fragility in Visualforce vs. Scontrols or standard pages.

TehNrdTehNrd
This may be of interest to you:

http://ideas.salesforce.com/article/show/10091004/Apex_method_to_identify_salesforcecom_server#skin=le