Announcement

Collapse
No announcement yet.

Order Processing

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Order Processing

    We have a problem retrieving orders using Actinic 6.1.3 running in SSL mode (whole site) on RedHat 9, Apache 2.0.47 and perl 5.8, Apache is using mod_perl and we have the registryprefork.pm fix installed to force a chdir to the cgi-bin folder (hardcoded location).

    The .ord files are being written out with a permission of 0200 (o:w) but having looked at the Perl code it would appear that in SSL mode Actinic chmods this to 0600 when it needs to read the file and then chmods it back to 0200 once its done.

    Other than order processing the site works perfectly so we know that the site configuration is fine, this appears to be a client side/order processing issue.

    We *think* its possibly something to do with the script that retrieves orders perhaps not using https when it goes to fetch the order files. This would explain the permission denied error.

    We get the following errors:

    The web script was unable to open the specified file.

    Possible Cause:
    Permissions problems
    The permissions on the acatalog directory are locked
    The permissions on the file on the acatalog directory are locked
    The path from the cgi-bin to acatalog directory is incorrect
    or the directory has been renamed or removed
    Recommendation:
    Abort
    Resolution:
    Check the permissions of the web site.
    The files and directories need to be readable
    and writable by the web server
    Run the Web | Configure Web Site Details command to
    verify your setup

    Command: retrieve

    ------------------------



    Actinic network config is as foillows:

    HTTPPROXYMODE 0
    HTTPPROXYADDRESS
    HTTPPROXYPORT 80
    HTTPPROXYUSER
    HTTPPROXYPASSWORD
    FTPPROXYMODE 0
    FTPPROXYADDRESS
    FTPPROXYPORT 21
    FTPPROXYUSER
    FTPPROXYPASSWORD
    SCRIPTID 100
    SCRIPTEXT .pl
    WEBSITEURL https://www.purecollection.com/
    IGNOREPASSIVEERRORS true
    USERELATIVECGIURLS true
    PATHTOPERL /usr/bin/perl
    SSLCATALOGURL https://www.purecollection.com/acatalog/
    SSLCGIBINURL https://www.purecollection.com/cgi-bin/
    SSLPATHFROMCGITOCATALOG ../acatalog/
    SSLCODEBASE ./
    SSLPATHTOCGIBIN /cgi-bin/
    SSLUSEPASSIVEFTP true


    RegistryPerfork fix is as follows:

    #file:ModPerl/PureRegistryPrefork.pm
    #-------------------------------
    package ModPerl::PureRegistryPrefork;

    use strict;
    use warnings FATAL => 'all';

    our $VERSION = '0.01';

    use base qw(ModPerl::Registry);

    use File::Basename ();

    sub handler : method {
    my $class = (@_ >= 2) ? shift : __PACKAGE__;
    my $r = shift;
    return $class->new($r)->default_handler();
    }

    sub chdir_file {
    my $dir = "/PATHTOWEBFOLDER/cgi-bin/";
    chdir $dir or die "Can't chdir to $dir: $!";
    }

    1;
    __END__

    #2
    Still trying to figure this one out, I'm about to set-up a test rig and load up a fresh config and try a new upload, any help would be appreciated, this is causing me big grief from the customer.

    Would we be better off running Actinic on Apache 1.3 ?, is it better to use command line perl as opposed to mod_perl 2 ?

    Comment


      #3
      Hi Simon

      Is your network settings test successful? If not, what error do you get?

      Ben
      Ben Popplestone
      Ecommerce website software

      Comment


        #4
        Hi Ben,

        Thanks for getting back to me, the network test produces the following result:

        The check script sent an invalid response (108, TP/1.0 200 OK
        Content type: Text/Plain
        Content length: 9
        Date: <SCRIPT RUN TIME>
        20000110).
        Retry the test.
        If the problem persists and you are unable to upload your store contact your actinic reseller or actinic support as appropriate.

        When you click OK you get the following:

        The test script failed to execute on the web server. The error could be caused by several things. Check the path to the Perl shell, the CGI script extension, the path to CGI-BIN, and the CGI-BIN URL. This error could also occur if your web site is out of disk space or your web server is not configured to accept POSTs to CGI scripts.


        NOTE: We are able to upload the site succesfully.


        Thus far I have built a RH9 system with Apache 1.3.28 and mod_perl 1 in order to bypass the fixes for script paths which are needed when using mod_perl 2, I just havent had a chance to test this setup yet but I should be able to do so today. Its just in case my fix for script paths is causing problems with Actinic when it goes to get the orders.

        As I've mentioned beore the site works perfectly once uploaded, its just the downloading of orders thats the problem.


        Cheers
        Simon

        Comment


          #5
          We have now tried loading the same catalog site onto a Windows 2K IIS5 setup and are experiencing the same problem, the network test fails with the same error as in my previous post, security is fully open on the windows test server.

          If we run the configuration wizard, when it goes to the Directorys page, if we select the web root - / and our cgi-bin folder using the wizard it complains that the web root doesnt exist ?????

          As I have mentioned before, the site runs fine once uploaded.

          This is really getting to be a pain in the ass, I dont understand what the issue is here.

          Comment


            #6
            Okay, after a lot of tweaking, we finally have it running on Windows, file permissions are forced to read/write in the acatalog folder where the .ord files are stored, this prevents the perl script from controlling file permissions hence when we run the order processing it succesfully downloads orders. Not exactly 100% secure but its a workaround.

            Going back to Linux, when monitoring file activity we can see the .ord files being changed to 0200 permissions but when you run order processing it fails to change the perms to 0600 hence order processing fails to download orders.

            Comment

            Working...
            X