Integrating Nochex

[petesouthwest]

The biggest danger facing Pete at the moment is that when the fix is published, he has to somehow get back to a standard installation as that will be the starting point from which the required changes will be documented.

Hi Bill
Actually that will only be the case if I end up having to over-write the HTML templates I have modified to make my site more complient with people still using 800x600. I would be extremly surprised if that was the case as none of them have anything to do with this issue.

If that happens I will simply jump under a bus

The edits I have done to add our logo to the Nochex page, I removed just to ensure they were not causing any problems.....

I'll only add them back in once the change to the new server has taken place and I have tested the system to ensure the APC is working.

Pete

[petesouthwest]

Pete,

I think you are over complicating this. There is no need of SSL support on the merchant's server, Actinic perl module will provide the SSL support. This is done by calling on scxxxxxx.pm in PostOCCNOCHEX.fil, as you have posted above. This script provides the SSL module. You do not need SSL port 443 turned on.

Kind regards,

Hi Bruce

I'm not over-complicating things Bruce, I just need to understand why your right and Nochex is wrong. Your asking me to talk to Nochex, and they keep saying I need SSL support, its good just saying no I dont to them. That just leads to the circular arguments we have been seeing all week, and ever since this problem was posted back in......2004?

Thank you for the anser, I'm off to think this though.
Cheers
Pete

[petesouthwest]

Pete,

I think you are over complicating this. There is no need of SSL support on the merchant's server, Actinic perl module will provide the SSL support. This is done by calling on scxxxxxx.pm in PostOCCNOCHEX.fil, as you have posted above. This script provides the SSL module. You do not need SSL port 443 turned on.

Kind regards,

Just a thought:

Does that module require MD5 Perl module? What would happen if the MD5 module is not installed?

Pete

[caite]

Please, for your own sanity, and for ease of application of the eventual fix, just leave well alone for now.

That made me laugh

I'm stepping well away

And your point is proven anyway, because my latest email from nochex suggests it should work either way. Although apparently it should really be https - so I maybe that's a little tweak that needs to go on the list. But presumably wouldn't solve this on its own. But why mine says http rather than https if everyone else's says https is a mystery to me - I've not modified anything other than going into the business settings window and adding nochex. I wouldn't know how to if I wanted to!

However my host company are saying that if Nochex want to try and send a post back to me using https then I'll need to be SSL enabled. Well since Bruce says SSL enabling is not neccessary I'll stand back from that for now as well. And to be fair I don't think it's quite a circular argument there - more of a clarification. Bruce isn't arguing that SSL is neccessary, he's just saying that it's dealt with by Actinic rather than by the server.

[petesouthwest]

Pete,

I think you are over complicating this. There is no need of SSL support on the merchant's server, Actinic perl module will provide the SSL support. This is done by calling on scxxxxxx.pm in PostOCCNOCHEX.fil, as you have posted above. This script provides the SSL module. You do not need SSL port 443 turned on.

Kind regards,

Hi Bruce

So using the new information you have given me. I assume your function HTTPS_SendAndReceive is a replacement for the high level POST function that should use its own SSL module to implement the SSL protocol?

so
HTTPS_SendAndReceive:

#
# Second attempt: ActinicSSL connection
if ($@)									# Error occured - the SSL library is probably not available
			{
			require sc000001;
			($nResult, $sMessage, $ssl_socket) = new ActinicSSL($sServer, $sPort);
			}
		}

Notice

# Error occured - the SSL library is probably not available

Which SSL library is this referring to? Is it the Actinic library or a standard Perl library?
From the way the code is written, I am assuming that the connection is first tried using the standard Perl module, and if this fails, the Actinic module is called to make the connection and implement the SSL protocol using the line:

($nResult, $sMessage, $ssl_socket) = new ActinicSSL($sServer, $sPort);

I have asked several times whether Actinic and Nochex have been tested on a system with the bare requirements ie Perl 5.004 or later; MD5 Perl module recommended.
As I see it if the test was done on a system with SSL support this would result in the Actinic SSL module not being tested as part of the system?

Can you confirm that whether Actinic and Nochex have been tested on a system with the bare requirements ie Perl 5.004 or later?

Are we now finding that rather than ‘recommended’ the MD5 module is in fact REQUIRED to allow Actinic and Nochex to integrate seamlessly?

Pete

[petesouthwest]

And to be fair I don't think it's quite a circular argument there - more of a clarification. Bruce isn't arguing that SSL is neccessary, he's just saying that it's dealt with by Actinic rather than by the server.

Hi Caite

Sorry to hear its still not working.

Bruce has helped immensly and I wasnt suggesting that he was providing a circular argument, so sorry Bruce and all if it sounded like that. What I was saying was before I started asking technical questions, and in Bruce's opinion over complicating the issues, I was in a circular argument because Actinic was saying SSL isnt needed and Nochex was saying it is.

Now had Actinic replied initially saying SSL support is not required by the server, as their is an Actinic module providing that functionality it would have saved a day of posts asking about it. For example if Actinic are correct, had they said this initially I could have checked with my server whether the MD5 Perl module, that seems to be required by the Actinic SSL module, was actually installed. It would also have also been usefull information for Nochex.

Pete

[wjcampbe]

Is there a danger in exposing in inticate detail on this very public and well indexed web forum, the internal workings of communication between an ecommerce software package and a payment service provider.

I am disturbed to see this being pursued in open forum rather that by private email exchange.

[petesouthwest]

Is there a danger in exposing in inticate detail on this very public and well indexed web forum, the internal workings of communication between an ecommerce software package and a payment service provider.

I am disturbed to see this being pursued in open forum rather that by private email exchange.

Hi Bill

Anything i can work out, a cracker/hacker will work out in half the time so i shouldnt worry too much. If what we are seeing is correct the SSL data is encrypted using MD5 and SHA algorythms that are virtually impossible to break into by anyone anway.

I appear to get detailed answers on her much faster than I do by email.

As i'm sure you will appreciate (or anyone else whoes website is their only source of income) the faster we get to the bottom of this the better. I appreciate you feel I should sit back and leave it to the 'experts' but I'm sure you wouldnt be so relaxed if you were in my position and relied on the income we are loosing.

If only I could tell my mortgage company to chill when their payment is late this month!

Pete

[Duncan Rounding]

I'm still a bit confused why you have to loose income while this is being resolved (and I'm as interested as anyone to see it resolved because my standard account is working fine) but cann't you still manually recon your orders with payments in the interim. I know it's a pain, can take extra effort, and is a temporary step backwards but it would keep the money coming in.

[petesouthwest]

I'm still a bit confused why you have to loose income while this is being resolved (and I'm as interested as anyone to see it resolved because my standard account is working fine) but cann't you still manually recon your orders with payments in the interim. I know it's a pain, can take extra effort, and is a temporary step backwards but it would keep the money coming in.

The original post over this issue was back in 05-Oct-2004, 03:34 PM by loumart, when I emailed him I believe (I have sent so many emails I'm getting lost) that he replied saying the issue was still un-resolved for him. Another responded by saying that he had got it fixed but only with the help of Nochex not Actinic. They too were probably told to manually reconcile while Actinic worked on the problem.

Exactly why should I trust that anyone else is going to fix this for me when it hasn’t been fixed for anyone else? As Actinic keep saying Nochex are wrong, why should I blindly follow the Nochex recommendation?

Had I have not spent the last 6 days working on this problem 18 hours a day to understand what is happening and asking questions, would my post just have disappeared like it did for those people?

Ignoring the fact that we are simply not getting what we have paid for, even though we have done our best to ensure a smooth change, when exactly do you suggest I process 20 orders a day?

Further, in my opinion it is better to have a website down for a single length of time, rather than keep messing with it and have it seen as unreliable. Can anyone guarantee that the final fix wont involve the website going down again?

Actinic have finally today given me a sensible answer to a question I asked on 02-Aug-2006. As they couldn’t seem to answer it properly when first asked, we had no choice but to believe Nochex and do as they have suggested, ie swap host. Which we are doing.

However, now I have a more detailed answer to my question regarding SSL, it is possible that following Nochex's reasoning may have been wrong. Had Actinic replied straight away saying something like 'your server does not require SSL support, as a custom function is used to send the data via SSL, that uses an Actinic module to generate the SSL protocol', when I initially asked, I would have been able to put this to Nochex and maybe the problem would have been resolved by now. One thing is for certain I would have tried testing whether the MD5 module that appears to be required by the Actinic SSL module is actually functioning correctly on my server. As it is the swap may have been unnecessary, it may simply be this standard module that wasn’t working for us. If this turns out to be the case we would have been up and running on the 2nd!

What should have happened is that when this initial question was asked, someone at Actinic should have appreciated that their SSL support, could be the problem if the MD5 module isn’t installed, (I’m assuming that, still waiting for an official answer). Given that the Actinic web page only says this module is recommended (rather than required), I would have thought that this would have been a standard question for anyone with Nochex/Actinic problems.

The whole point in us upgrading to Actinic and Sage is to reduce our workload so we can cope with the ever increasing number of orders we are getting. Based on the lack of information given, until I ask more and more detailed questions, I cant see how this problem would ever get solved. So if I had processed orders and not spent 18hrs a day working on this problem, so I could ask those detailed questions, I feel that this would never have been looked at in any depth.

Pete

[petesouthwest]

Ok here is the latest:

I have written a basic script to test whether the Perl MD5 module is installed and working on the previous host.

It worked

#!/usr/bin/perl
use MD5;
print "Content-type: text/html\n\n";
print "<html><head><title>Hello World!! </title></head>\n";
print "<body><h1>Hello world</h1></body></html>\n";
$digest = MD5->hash('This is a test message');
print "digest=$digest\n";

http://www.pureskincare.co.uk/cgi-bin/md5a.pl

This establishes that the MD5 Perl module is working.

So lets think how that effects what I know:

the comment in the HTTPS_SendAndReceive function
Notice

# Error occured - the SSL library is probably not available

My hypothesis: The SSL library referred to is the standard Perl module. I am assuming that the connection is first tried using functions from the standard Perl module, and if this fails, the functions from the Actinic module are called to make the connection and implement the SSL protocol via the actinicSSL object.
In most cases people have SSL support so the error condition is never encountered and the actinicSSL object is never created and used However, for a small number of people, ie me and Caite, who dont have SSL support, the Actinic SSL module gets called.

As I have now confirmed that my host’s MD5 module works, it would suggest a possible bug in the actinicSSL object.

I have asked this several times but It is imperative that someone in actinic checks to see whether Actinic and Nochex have been tested on a system with the bare requirements ie Linux box, Perl 5.004 or later; MD5 Perl module installed.

As I see it if the test was done on a system with SSL support this would result in the ActinicSSL object not being tested as part of the system?

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???

My next step is to get a linux box up and running as websever and test it myself, but if anyone beats me to it I would be well happy.

I appreciate you guys at Actinic think I’m wrong about the whole SSL thing but can you explain what you think the problems may be? I haven’t heard any suggestions for possible causes for ages? The last thing I heard was on the 3rd at 5pm saying your developers feel that there is some problem on the server, could you give me more details? What do they think the problems may be?

Pete

[wjcampbe]

It still seems to be escaping your grasp, that NOCHEX introduced a new product since NOCHEX wrote the NOCHEX integration script, and that the most likely cause of your problem is that NOCHEX did not test the new NOCHEX product against the integration script that NOCHEX wrote.

It also seems to be escaping your grasp, that there are many other payment providers out there, and that having multiple providers gives your customer choice.

You have also stated more than once that you had a working store using another shopping product in concert with NOCHEX - why would you ever have shut that down before your new solution was developed, tried and tested?

And even now, you would rather spend your time playing amateur detective to try and outguess the people (NOCHEX and Actinic) who do know what they are doing, and how the integration (and internet communication) works, than put your old setup back in place or use an additional provider or a proven manual work around that would provide you with the income you state is your aim?

If you were working for me, I'd have fired you on the second day.

[petesouthwest]

It still seems to be escaping your grasp, that NOCHEX introduced a new product since NOCHEX wrote the NOCHEX integration script, and that the most likely cause of your problem is that NOCHEX did not test the new NOCHEX product against the integration script that NOCHEX wrote.

It also seems to be escaping your grasp, that there are many other payment providers out there, and that having multiple providers gives your customer choice.

You have also stated more than once that you had a working store using another shopping product in concert with NOCHEX - why would you ever have shut that down before your new solution was developed, tried and tested?

And even now, you would rather spend your time playing amateur detective to try and outguess the people (NOCHEX and Actinic) who do know what they are doing, and how the integration (and internet communication) works, than put your old setup back in place or use an additional provider or a proven manual work around that would provide you with the income you state is your aim?

If you were working for me, I'd have fired you on the second day.

With all due respect Bill, I’m sure your understanding of using the Actinic software is very good, but you obviously don’t have a clue regarding this problem. Could I respectfully ask in this case that you keep comments and opinions like that to yourself as they do nothing but infuriate me, and detract the thread from the main purpose of solving the problem.

All of your suggestions I have answered in past postings, please refer to them. Simply reposting the same suggestions does not help. Can I ask that any further posts suggesting work-arounds to this problem go on a separate thread? That would keep this thread involved with solving the problem.

If you have a sensible suggestion as to the cause of this problem then I obviously welcome your comments, but at the moment your posts show you understand little of the concepts involved and simply post because in some way you feel that you must defend any suggestion that Actinic may have a bug in their code.

Regards
Pete

[petesouthwest]

Any Actinic staff know the latest?

Pete

[Bruce]

Hi Pete,

After checking things through, we have found that you do not need to change anything on your system to make this work. I would suggest going back to an original set of the Act_OCCNOCHEXTemplate.html and OCCNOCHEXScriptTemplate.pl, you can find these in C:\Program Files\Actinic v7\OCCUpgrade\CommonOCC, copy from here and paste into the 'CommonOCC' folder within your Site1 folder. In the Payments and Security area, enter your Merchant ID by clicking on the 'Configure Method' button.

You don't need to make any changes, this is what we are already doing. i.e. we are already supporting APC it's just never been called APC before. We call it the Authorisation Callback. The Authorisation Callback for Nochex is handled by PostOCCNOCHEX.fil as per the intergration written by Nochex.

HTTPS_SendAndReceive checks, if the NET::SSL package exist on the server. If not then it loads the Actinic package, which is always there. This is a performance issue.

About the SSL connection. In the case the request is initiated from your server (Client) to the target Nochex server (Server).

For the client to be able to make a connection, it needs a socket. So it requests a socket from the system. When the socket is provided by the system, it will assign a port to it, which is not used momentarily by the system, above number 1024. Let's assume it is 1358 in our case. Then, when the socket is ready, the routine sets some parameters in the socket, then tries to make a connection to www.nochex.com:443, which means, target IP address = 62.105.93.97 and the target port is 443. When the request is accepted at nochex server, it will assign a socket for this connection, as port 443 is just a listening port, so it will assign a free port for it let's say 2476.

When the connection is established, the socket will contain the following connection data:

source ip address = 213.232.107.228 (www.pureskincare.co.uk)
source port = 1358
destination IP address = 62.105.93.97 (www.nochex.com)
destination port = 2476

The actual data stream will be delivered via these ports above.

When the conversation is done between the client and server then the connection is closed and the ports are released. So, you can see the port 443 on your server is not involved at all. SSL support for the connection is provided by NET::SSL or ActinicSSL.pm on client side and by the web server module on server side.

If the connection can not be made between the client and server, then it is caused by a firewall, a content filter or internet connection problem.

Kind regards,