Unresolvable issues regarding integrating the PayflowPro SDK (fwd)

Hey folks- This is a copy of the letter I sent to Verisign Payment Services (formerly known as Signio). I sent it about a week and a half ago and have received no reply. The extension that David Croft and I wrote is somewhat crippled as a result of their closed-source shared object library being linked against (what appears to be) OpenSSL (a more thorough description is in the letter). The pfpro extension still has a wide application for backend batch transaction processing, but unless you want to take credit cards from customers over HTTP, it can't be used in a webserver environment. Their bundled Perl SDK vforks and calls the compiled C client. This is really a pathetic implementation for bigger sites to have to deal with. This is how anyone who uses PHP has to do it as well, currently, without the extension fully functional. Anyways, I'm forwarding this in hopes that some of you who may also be interested in getting this extension fully functional will write support@signio.com and complain. I'm surprised that a company would thumb its nose at PHP without even the courtesy of a response to one of its customers. Thanks John ---------- Forwarded message ---------- Date: Mon, 6 Nov 2000 14:48:51 -0500 (EST) From: John Donagher <john@webmeta.com> To: support@signio.com Subject: Unresolvable issues regarding integrating the PayflowPro SDK To whom it may concern- What follows is a detailed explanation of the steps we (a Signio/Verisign customer) have taken to integrate the pfpro SDK into our application, and a problem which I've spent more than a month trying to solve. I'm looking for some feedback from one of your technical people who is familiar with webserver mechanics and security (ideally someone who is/was involved in the development of the pfpro client library). I work for a company called Intacct. We provide a web-based accounting application, written in PHP, which runs on Apache on i386 Linux servers. We use Signio for our internal billing. We also were looking at the possibility of recommending that our customers use Signio for their own billing purposes and to offer online bill-payment to their own customers, which could be proxied through our application (so that the corresponding accounting entries can be made automatically). Having used Signio at my prior company for that company's billing system, I was eager to recommend Signio to my new employer. We have a fairly tight system configuration here. So, I began writing a PHP extension (in C) that would be linked against libpfpro.so and make direct library calls as opposed to vforking and calling the executable, which is not allowed in our setup for security reasons. This extension also provides some wrapper functions exposed to the programmer, such as the ability to maintain fine control over the pfpro_init() and cleanup() functions, as well as the ability to pass in an associative array of paramaters as opposed to the HTTP GET style request that the 'pfpro' executable requires. The extension works great, except for one serious problem. You have already linked the pfpro library against an SSL implementation (presumably OpenSSL). This may be necessary for standalone operation, but when compiled as part of an SSL-enabled webserver, it causes the webserver to crash on runtime due to conflicting strings. I've verified this problem many times, and tried many different combinations of .so's and .a's (both Apache's mod-ssl and the PHP module) in an attempt to work around the problem. But the problem remains, and as I see it is completely unsolvable without some help from Verisign. The PHP extension has already been contributed to the PHP codebase (http://www.php.net/pfpro), has been distributed in the past 2 or 3 releases, and I have already received numerous inquiries from people wanting to use it who are disappointed when I tell them that it probably will not work for what they want it to. But this is not a problem that is specific to PHP, it is a problem that I believe will show up whenever anyone tries to use your SDK to write an application which will also link against an SSL library. So, I look for some assistance from you. Is there any chance of either providing an open-source library as opposed to only closed-source binaries? It looks as though you are simply using HTTPS request-response semantics for your server, and I can't imagine that it would be strategically detrimental to open-source that kind of a client. Failing that, perhaps providing a .a instead of a .so would allow us to overwrite your SSL implementation with ours at linking-time? Do you have any other suggestions that may help us? Thanks in advance for any assistance you can provide. -John -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com -----pgpenvelope information----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org pgpenvelope_decrypt: importing a keyblock gpg: key EEBE8DDD: not changed gpg: Total number processed: 1 gpg: unchanged: 1 pgpenvelope_decrypt: message processed at Thu Nov 16 01:28:58 2000 -----end pgpenvelope information-----