Re: Unresolvable issues regarding integrating the PayflowPro SDK (fwd)

I will try to poke them at a higher level. On Thu, 16 Nov 2000, Zak Greant wrote: > I wrote them at roughly the same time looking for more information (for a > book project that I am working on) and have not heard from them either... > > You would think that they would be smart (or at least selfish) enough to > realize that more support/visibility will increase their customer base. > > I will send them another message.. > > Zak Greant > > At 02:03 AM 11/16/00 -0500, John Donagher wrote: > > >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----- > > > > > > > >-- > >PHP Development Mailing List <http://www.php.net/> > >To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > >For additional commands, e-mail: php-dev-help@lists.php.net > >To contact the list administrators, e-mail: php-list-admin@lists.php.net > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >