Integrating Nochex

[Bruce]

Caite,

Did you raise a support query on this issue? If so what is the issue number please?

Kind regards,

[caite]

no, I didn't, I just tagged along on this thread. I'll go and raise a support query now. Cheers!

[petesouthwest]

Hi

We have got the access logs for www.ict-coursework.co.uk working so we put in another test order and looked at the logs as requested by email.

It shows Nochex trying to access the script several times:

62.105.93.124 - - [23/Aug/2006:17:30:28 +0100] "POST /cgi-bin/os000001.pl?PATH=%2e%2e%2facatalog%2f&SEQUENCE=3&ACTION=AUTHORIZE_52&CARTID=81Z79Z4Z215A1156349780B6630&ON=DJ43QN10000002&TM=0&TO_EMAIL=care@pureskincare.co.uk&ACT_POSTPROCESS=1& HTTP/1.1" 200 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" ict-coursework.co.uk
62.105.93.124 - - [23/Aug/2006:17:32:30 +0100] "POST /cgi-bin/os000001.pl?PATH=%2e%2e%2facatalog%2f&SEQUENCE=3&ACTION=AUTHORIZE_52&CARTID=81Z79Z4Z215A1156349780B6630&ON=DJ43QN10000002&TM=0&TO_EMAIL=care@pureskincare.co.uk&ACT_POSTPROCESS=1& HTTP/1.1" 200 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" ict-coursework.co.uk
62.105.93.124 - - [23/Aug/2006:17:34:29 +0100] "POST /cgi-bin/os000001.pl?PATH=%2e%2e%2facatalog%2f&SEQUENCE=3&ACTION=AUTHORIZE_52&CARTID=81Z79Z4Z215A1156349780B6630&ON=DJ43QN10000002&TM=0&TO_EMAIL=care@pureskincare.co.uk&ACT_POSTPROCESS=1& HTTP/1.1" 200 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" ict-coursework.co.uk
62.105.93.124 - - [23/Aug/2006:17:36:28 +0100] "POST /cgi-bin/os000001.pl?PATH=%2e%2e%2facatalog%2f&SEQUENCE=3&ACTION=AUTHORIZE_52&CARTID=81Z79Z4Z215A1156349780B6630&ON=DJ43QN10000002&TM=0&TO_EMAIL=care@pureskincare.co.uk&ACT_POSTPROCESS=1& HTTP/1.1" 200 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" ict-coursework.co.uk
62.105.93.124 - - [23/Aug/2006:17:38:28 +0100] "POST /cgi-bin/os000001.pl?PATH=%2e%2e%2facatalog%2f&SEQUENCE=3&ACTION=AUTHORIZE_52&CARTID=81Z79Z4Z215A1156349780B6630&ON=DJ43QN10000002&TM=0&TO_EMAIL=care@pureskincare.co.uk&ACT_POSTPROCESS=1& HTTP/1.1" 200 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" ict-coursework.co.uk
62.105.93.124 - - [23/Aug/2006:17:40:28 +0100] "POST /cgi-bin/os000001.pl?PATH=%2e%2e%2facatalog%2f&SEQUENCE=3&ACTION=AUTHORIZE_52&CARTID=81Z79Z4Z215A1156349780B6630&ON=DJ43QN10000002&TM=0&TO_EMAIL=care@pureskincare.co.uk&ACT_POSTPROCESS=1& HTTP/1.1" 200 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" ict-coursework.co.uk
62.105.93.124 - - [23/Aug/2006:17:52:28 +0100] "POST /cgi-bin/os000001.pl?PATH=%2e%2e%2facatalog%2f&SEQUENCE=3&ACTION=AUTHORIZE_52&CARTID=81Z79Z4Z215A1156349780B6630&ON=DJ43QN10000002&TM=0&TO_EMAIL=care@pureskincare.co.uk&ACT_POSTPROCESS=1& HTTP/1.1" 200 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" ict-coursework.co.uk
62.105.93.124 - - [23/Aug/2006:17:56:28 +0100] "POST /cgi-bin/os000001.pl?PATH=%2e%2e%2facatalog%2f&SEQUENCE=3&ACTION=AUTHORIZE_52&CARTID=81Z79Z4Z215A1156349780B6630&ON=DJ43QN10000002&TM=0&TO_EMAIL=care@pureskincare.co.uk&ACT_POSTPROCESS=1& HTTP/1.1" 200 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" ict-coursework.co.uk
62.105.93.124 - - [23/Aug/2006:18:00:28 +0100] "POST /cgi-bin/os000001.pl?PATH=%2e%2e%2facatalog%2f&SEQUENCE=3&ACTION=AUTHORIZE_52&CARTID=81Z79Z4Z215A1156349780B6630&ON=DJ43QN10000002&TM=0&TO_EMAIL=care@pureskincare.co.uk&ACT_POSTPROCESS=1& HTTP/1.1" 200 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" ict-coursework.co.uk
62.105.93.124 - - [23/Aug/2006:18:04:28 +0100] "POST /cgi-bin/os000001.pl?PATH=%2e%2e%2facatalog%2f&SEQUENCE=3&ACTION=AUTHORIZE_52&CARTID=81Z79Z4Z215A1156349780B6630&ON=DJ43QN10000002&TM=0&TO_EMAIL=care@pureskincare.co.uk&ACT_POSTPROCESS=1& HTTP/1.1" 200 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" ict-coursework.co.uk

The firewall is open for:

62.105.93.102 (secure.nochex.com)
62.105.93.124 (nochex-fw.cust.pipex.net)

We seem to be going around in circles though, I cant see how this tells us any more than it did when I looked at the logs back in post 35 on 03-Aug-2006, 03:31 PM......

Its now 20 days later and we seem to be doing the same things.

I know in your email you have suggested changing hosts, and we have done so temporarily for www.pureskincare.co.uk as we could not wait for a solution. The temporary hosting package is costing much more than our original package. Ultimately we were hoping to get several niche online stores going using Actinic, and already have other domain names registered with Supanames. I know changing host is any easy 'work around', but I would have thought Actinic would have liked to get to the bottom of this problem, so that other customers don’t have the same problem.

Pete

[petesouthwest]

Any updates?

Caite - Is this solved for you?

Pete

[caite]

Hi Pete

No, still no progress. I'm right back to the situation I was in at the start, Actinic are saying "Actinic is behaving correctly - Nochex is not responding" and Nochex are saying "Nochex is behaving correctly - Actinic is not responding."

As far as I can see, Nochex is more likely to be correct at this stage because their repeated confirmation requests can be seen on my server logs (which have been sent through to Actinic), and they wouldn't keep sending them if they were getting a response.

Bruce, if you're out there, it's support query: 84092

Feeling very jealous of all those people that just managed to get this working straight off with no struggle.

[petesouthwest]

Hi Caite

Sorry to hear your in the same situation.

Did you ever try asking 34sp to enable ssl support for you?

I did notice that their website mentioned it as an option for an extra £10/year. http://www.34sp.com/hostingfeatures

I know nobody at Actinic thinks that it is the problem, but in my opinion a bug in their ActinicSSL module is still the possible cause.

To be fair, it is hard to test software thoroughly in-house, and even Bruce says their software has bugs:

This is because v8 is a new product and a lot of new bugs and issues are raised when a variety of users test it.

http://community.actinic.com/showthr...t=13966&page=3 post 31.

So given the fact that only a small percentage of users will try using Nochex and Actinic on a host that doesn’t have SSL support (remember, all of those people saying it worked for them without problems, had SSL support) I think its fair to assume it could be a bug that hasn’t been found.

The other thread also shows that Actinic don’t pull out the stops to fix bugs that only effect a small number of users. The stock control issue mentioned in that thread has inconvenienced several people for 13 months, but Actinic don’t even have a date for when the fix is due.

Pete

[wjcampbe]

remember, all of those people saying it worked for them without problems, had SSL support

Not quite true, I do not have any SSL on my site, and as I posted way back, I enabled Nochex with no problem at all.

[Bruce]

Pete,

You are making some unfair statements.

To get to the results of the debug on your site..

The authorisation callback arrives, then PostOCCNochex.fil gets the control and tries to send the information it received to Nochex server as a confirmation. It is done by calling ACTINIC::HTTPS_SendAndReceive.

This routine then tries to load NET::SSL, it is not installed, so it loads Actinic::SSL. It is successful. Then it tries to open the connection to Nochex server, by getting the IP address from name, creating the socket then call connect. The the script freezes or is kicked out by the operating system, we couldn't find out which as we have no root SSH access for this site (and I know we can't get it due to security reasons).

So the problem occurs in a perl library, which is out of our control. The possible reasons could be:
- the perl installation is broken, so that's why the connect can't be done.
- the server kicks out this script for some reason we don't know, as we can't see all server logs.

The suggestion from development is to force the ISP to investigate this problem, as you can see from the debug information provided above, it is not an Actinic problem, but a server installation or configuration problem. Actually we can't do anything about it from this point, except helping to create the problem, when the ISP is ready to trace what happens on the server with this script. If there is anything else we could help with please let us know.

It would also be useful to check if the installation of perl was done as per the guide on teh following link http://www.visualwin.com/Perl/ . This method of installation solved a problem another user was facing on a server. ( Only for IIS server )

Kind regards,

[petesouthwest]

Not quite true, I do not have any SSL on my site, and as I posted way back, I enabled Nochex with no problem at all.

Hi Bill

Which post was that?
I only remember one post where you tried Nochex, and as I said at the time, the host you were using had SSL support, so you joined all those other people that say it works, but have SSL support provided by their host package.

Pete

[petesouthwest]

Pete,
The authorisation callback arrives, then PostOCCNochex.fil gets the control and tries to send the information it received to Nochex server as a confirmation. It is done by calling ACTINIC::HTTPS_SendAndReceive.

This routine then tries to load NET::SSL, it is not installed, so it loads Actinic::SSL. It is successful. Then it tries to open the connection to Nochex server, by getting the IP address from name, creating the socket then call connect. The the script freezes or is kicked out by the operating system, we couldn't find out which as we have no root SSH access for this site (and I know we can't get it due to security reasons).

Hi Bruce

This is basically what i was saying back at the beginning of August. The only difference is that Actinic now recognise that the ActinicSSL module doesn’t manage to reply.

So the problem occurs in a perl library, which is out of our control.

So the problem is in the actnicSSL module. Who has written this Perl module?

The possible reasons could be:
- the perl installation is broken, so that's why the connect can't be done.
- the server kicks out this script for some reason we don't know, as we can't see all server logs.

Or there is a bug in the actinicSSL module.

It amazes me that after a month you essentially repeat what I have already said and then say:

Actually we can't do anything about it from this point

as you can see from the debug information provided above, it is not an Actinic problem, but a server installation or configuration problem.

The 'debug information' you have provided has not narrowed down the problem sufficiently to say where the problem lies. As you have access to my test site, why not put debug statements in the actinicSSL to write debug information to a file and narrow down exactly where in the actinic SSL module the problem occurs?

t would also be useful to check if the installation of perl was done as per the guide on teh following link http://www.visualwin.com/Perl/ . This method of installation solved a problem another user was facing on a server. ( Only for IIS server )

I'm not sure why you have given a link to the instructions to set Perl up on a IIS Windows server setup rather than a Linux box. But why doesnt someone from Actinic email Supanames and 34sp to find out how Perl has been setup?

Pete

[caite]

So the problem occurs in a perl library, which is out of our control. The possible reasons could be:
- the perl installation is broken, so that's why the connect can't be done.
- the server kicks out this script for some reason we don't know, as we can't see all server logs.

Hi Bruce

I'm just wondering, does this mean you have basically pinpointed the exact point where something is going wrong?

Are there specific server logs that would exist, and if you were able to get SSH access you'd be able to see them? If so I'm wondering if there is a way we could speak to our hosting companies and request they go in themselves to get us some particular pieces of information that might help with this?

Caite

[Bruce]

Yes, Specific server logs so exist and can only be accessed if we have SSH access. The logs for the period around the call would help identify what is causing the script to fail to execute.

Kind regards,

[Bruce]

Pete,

The attempt to open a connection using the Actinic:SSLpen:connect fails to return.

We can do nothing without a response from the system software. Normally if the connection is invalid then an error is reported but on this server no response is given to our scripts.

Debugging has shown that the first line of the following code does not return...

unless (connect($ssl_socket, $sin))
{
my $sError = ACTINIC::GetPhrase(-1, 1934, $!);
close($ssl_socket);
return($::FAILURE, $sError); # Record internal error
}

This can happen only if the operating system stops the process. It would normally do this if the process has run for too long. As it always stops at the same place then the reason for timing out at this point is most likely due to the connection being blocked. A 'Stealth' firewall would not respond to the connection request and therefore the calling script would wait for ever unless the process is killed off.

The ISP needs to open outgoing connections on port 443 otherwise the callback will never work.

You to determine from the ISP if they are willing to open outgoing connections on port 443. Should the ISP state that there is no block on outgoing connections to port 443 then we need to know from the ISP why the process is being stopped at the same point every time.

Kind regards,

[petesouthwest]

Pete,

The ISP needs to open outgoing connections on port 443 otherwise the callback will never work.

But Bruce when I repeatedly asked if port 443 needed to be open back around the begining of august:
03-Aug-2006, 07:44 post 21 PMhttp://community.actinic.com/showthread.php?t=22625&page=2

you replied with posts:
04-Aug-2006, 10:07 AM post 58
70 on 04-Aug-2006, 02:27 PM
saying:

Pete,

There is no need of open port 443 for the merchant's server, as the request sent by PostOCCNOCHEX.fil is a client request to Nochex server, so there is a need for an open 443 port only on the Nochex server.

The connection will be established in this way...

Merchant's server port X <-> Nochex server port 443

Where X is a random number above 1024. For connecting from a script to a server, the server must have a static port number, so the script will know where to connect to. The server will retrieve the client's port number from the TCP frame of the request.

It seems to have taken Actinic's development team a month to work out what I worked out in a weekend.

If only back on the 4th Actinic had said Port 443 needs to be open rather than continually trying to tell me I was wrong, we could saved a lot of time and money. This is totally frustrating.


Have you contacted Caite to suggest that she tries asking her host whether port 443 is open?

It is a fair assumption that servers with SSL support will have port 443 open, while servers that do not support SSL, would close this port as there would be no need of leaving it open.

Pete

[petesouthwest]

On the 4th aug post 86 I also asked:

Can anyone confirm that Actinic and Nochex have been tested on a Linux system with the bare requirements of CPAN Perl 5.004 and MD5 with port 443 disabled and NO SSL support via crypt::SSLeay???

you replied with post 91 on the 7th Aug

Yes, it was done. We would not release a new package, without testing it in all possible environments.