Doing a form POST to an EPiServer page

Vote:
 

Has anyone out there tried posting to an EPiServer page? I am working on an ecommerce site, based on EPiServer, which posts to another site for handling payments. The other site then posts back to our site, and we need to pull various info from the Request.Form variables.

However, because of something that EPiServer's URL rewriting modules does, by the time Page_Load fires, the form variables are gone and the verb has changed from POST to GET.

As a quick and dirty workaround we have overriden EPiServer's URL rewriting and rewritten the path ourselves, which works - almost. The only problem we have now is that the EPiServer properties do not work properly.

Does anyone have any suggestions as to how to fix this? Thanks.

#23603
Sep 10, 2008 16:44
Vote:
 

We've improved the workaround so that it passes the page ID on the querry string. This has got the EPiServer property controls working again. The code is as follows

protected override void HttpUrlRewriteToInternal(EPiServer.UrlBuilder url)

if (requestUrl.Contains("CheckoutComplete"))
{
    context.RewritePath("/MasterTemplates/EPiServer/Pages/CheckoutCompleteTemplate.aspx?id=10");
}
else
{
    base.HttpUrlRewriteToInternal(url);
}

However this now means we have got a hard-wired page ID, any suggestions as to how we can avoid this?

#23742
Sep 15, 2008 10:53
Vote:
 

Looks like you can programatically discover the ID of a page, using the URL builder, as follows

private PageReference GetPageReference(UrlBuilder url)
{
    object page;
    Global.UrlRewriteProvider.ConvertToInternal(url, out page);
    return page as PageReference;
}

The use the ID property of the PageReference class.

#23744
Sep 15, 2008 11:35
Vote:
 

Looks like the last bit doesn't work. Calling ConvertToInternal in order to get the PageReference also ends up rewriting the URL. Doh!

Guess we will have to go back to hard-wiring the page id, unless anyone has any suggestions?

#23746
Sep 15, 2008 12:41