|Can't Launch Order Template from public_html?|
|Can't Launch Order Template from public_html?|
Author Mark Lannen on 11-30-2000 at 08:32 (EST)
|My ISP does not allow HTML pages to be served from the cgi-bin directory. This causes a problem with my ushop 2.0 configuration when I try to launch the order_template.html page since ushop requires that the order_template.html file be located in the cgi-bin directory.|
I tried several workarounds including setting the of the page containing the uShopOrderButtonCGI.class button to point to my public_html directory which contains the order_template.html file, but that didn't work. I also tried setting the order_page parameter of the uShopOrderButtonCGI applet to the full server address of the order_template.html page in public_html, but that didn't work either. Each time I get the ushop error: "Unknown Order Page - Unable to locate order page: INVALID." However, the good news is that this error tells me that I have correctly configured ushop such that it reads and executes the ushop_authnet.cgi file in the cgi-bin of my secure server as expected since that is where that custom error message is generated.
Is there a way to get ushop to launch the order_template.html from the public_html directory? I don't understand why the order_template.html file needs to be in cgi-bin anyway since the form reveals nothing until it is filled out and submitted to the secure server.
|Messages In This Discussion|
| 1. RE: Can't Launch Order Template from public_html?|
Author Bill Weiner on 11-30-2000 at 09:14 (EST)
|Actually, the uShop 2.x order template file ("order.template" or "order.html") does not actually get served like any other HTML page on your server... but rather just needs to be readable by the ushop_cgiscript. The ushop_cgiscript will handle outputting it. So really, the "order.template" file can be located anywhere on your server - including your cgi-bin - providing that "order_page" parameter of your uShopOrderButtonCGI applet is properly set to the relative directory path of the "order.template" file from the ushop_cgiscript. And the easiest way to do this is to just put the "order.template" file in the same directory as your ushop_cgiscript... and then simply set the "order_page" parameter to "order.template". See Section 6 on the following uShop 2.x reference page for more information about setting up the uShopOrderButtonCGI applet:|
| 2. Can't Launch Order Template from public_html?|
Author Mark Lannen on 12-01-2000 at 00:47 (EST)
|Thank you for your prompt reply to my configuration problem. Prior to your suggestion, I had already read your Secure Transactions reference page and probably focused on the following line of section 6.4:|
>> After creating the order.template file, transfer it into the "same directory as the uShop CGI script on your secure server." <<
Not only does that line lead one to believe that the order template pages should be in the secure cgi-bin directory, but the words in quotes are actually in boldface, as if to underscore that point.
As my original message indicated, I moved those template files to my public_html directory and appended my full public_html server path to the filename of the order_page parameter in the uShopOrderButtonCGI.class applet, on the chance that perhaps those template files could be launched from a directory other than cgi-bin. I think the instruction in section 6.4 should be amended to make it clear that the template files can be served from the public_html directory as long as the full directory path is specified.
I'd also like to mention that I tried launching the order form from an ordinary hyperlink. That worked like a charm, so I knew that the order template form was valid, and that my secure server address was valid.
With those possibilities out of the way, I think I am close to the root of my problem regarding this issue. For one thing, I decided to change the extension of my two order template files from *.htm to *.html, and that made a difference. When I pressed the order button, instead of getting "Unable to locate order page: INVALID", the "INVALID" was replaced by the full directory path and name of the file that ushop_authnet.cgi was trying to open. As expected, I found that the Perl program could not resolve my full public_html server name.
The path to my public_html server name is in the format:
I found that your perl program did not recognize the @ symbol in my pathname (my email address). So I tried escaping it, but that didn't work. Next, I replaced the @ with its ISO-8859-1 character code (@) but that was not recognized either. What I find odd is that your perl program doesn't appear to have trouble interpreting the scriptpath of the secure server, even though it too has an @ within its name (my email address, again).
I need to find a way to allow the @ symbol to pass your server name filter in ushop_authnet.cgi so that the order form can be served.
| 3. RE: Can't Launch Order Template from public_html?|
Author Bill Weiner on 12-01-2000 at 06:51 (EST)
|Relating to uShop 2.x:|
Again, I still don't quite understand why you don't just put the "order.template" (or "order.html") file in the same directory as the ushop_cgiscript (or the ushop_authnet script if that is what you are using) ... as described in the instructions. Remember that the uShop CGI script just has to be able to read that file... kind of like a configuration file. And by having it in the same directory as your CGI script, then you can just set the "order_page" parameter to "order.template" (or "order.htm").
And oh, yes, you are correct... the order template file has to end with either ".template" or ".html" due to a security check that is built into the uShop 2.x script.
Anyway, if you still want to put the order.template page in a public directory...and your full path has an @ sign in it, then you are correct... that @ sign in your directory name is causing the problem. This is because the uShop 2.x CGI script performs a validation on the value passed to it via the "order_page" parameter. This validation that is performed on the "order_page" name will remove any character from that name except letters, numbers, periods, and forward slashes.
If you want, you can modify that validation by:
STEP 1: Open the script with any text editor such as WordPad.
STEP 2: Do a search on "sub validate_template" to find the start of the subroutines that validates the name of that order_page template.
STEP 3: Locate the following line in that subroutine:
$vstring =~ s/[^./A-z0-9]//g;
and change it to:
$vstring =~ s/[^./@A-z0-9]//g;
.... so that it will accept the @ sign.
STEP 4: Save the script (as TEXT if your editor asks).... and try it out!