CiviCRM Community Forums (archive)

OK, so Google's IPN needs configuration in the merchant admin. Thanks Donald for the reminder

I might have missed something here ... first time I've played with extensions.

As far as I can tell, the CiviCRM extensions directory is intended to be writeable to your webserver, so that extensions can be retrieved and installed automatically. But the extensions dir may also contain IPN callback files, and this combination rings alarm bells for me - executable code in a webserver-writeable directory.

It means there's a place where any exploit of the webserver can store and execute code later. Generally I use Apache's sethandler to prevent execution in any directory which the webserver may write to for this reason.

I can live without CiviCRM being able to install extensions itself. But I wonder if we can find a way to do this which doesn't mean CiviCRM is encouraging writeable, executable directories.

If extensions can add their own callback paths to CiviCRM (eg: ?q=civicrm/googleNotify or ?q=civicrm/ipn/PayPal) then we can handle this in the extension. That way the extensions directory could include PHP classes only, and we can prevent exec entirely via sethandler.

As I said ... it's possible I'm missing something. I had a go with the PayFlow extension as well, but it looked like it was going to take a bit of work before I'd be able to test out IPN there either.

Two ideas on how extensions might remove the need for adding separate scripts to the extern/ folder -

• Allow extensions to provide custom callbacks, eg ?q=civicrm/googleNotify style. This offers a lot more flexibility for extensions generally, and it's quite possible this is already available but I haven't found it yet.
• Create an IPN interface which payment processor extensions can implement (eg defined method like CRM_Core_Payment_myprocessor::handleNotify()), and have CiviCRM expose ?q=civicrm/notify which the processor would call with a parameter to specify the appropriate class to call that method in (?q=civicrm/notify&processor=myprocessor&blah=blah).

But if what you say is true, I expect there's already a means to work around the issue I'm having. And *maybe* it's one of the above! I'll go re-read the "implementing a payment processor extension" page again

u definitely should not place the extensions folder under modules/civicrm to avoid upgrade / delete issues

maybe the recommended place could be modules/civicrm.extensions

Since extension install / uninstall will not be too often, how about recommending that (if u have shell access)

1. People only make them web-writable when installing/un-installing an extension

2. if the extension directory is writable, we emit a warning on the admin page stating so

I think we might want to consider making the IPN part of the civicrm url structure (and this invoked via the CMS). This will solve the issue of: "where is the civicrm directory located etc"

lobo

Wow, tons of great thinking in this thread. :-)

From what I remember, original idea was to have an extern/ script, which would be always called by payment processor with a parameter identifying its type - so practically the same as you propose (not counting your improvement around IPN interface). I even thought it was actually implemented, but from quick look at the repository code, I don't see it anywhere. There were three of us digging around "extensioning" payment processors and it was during code sprint, so maybe this part slipped somewhere in between conversations/work division.

I would love to take a closer look at this as soon as possible, but I'm a bit behind with projects and need time until end of this week to catch up. Seems like I have raising queue of extensions issues (which means more people start using them, hurray) and plan to spend some uninterrupted time on fixing problems/introducing improvements at the beginning of next week. Part of that would be checking what's going on with IPN thingy and making it work.

Thx,
m

Thanks. I like to call it "peerless programming" when I'm yakking away to myself in public.

OK, so accepting that this not yet available in 3.4/4.0, I've done a couple of things -

In Flo2CashDonate class, I've added a paymentNotify() method which is really just a wrapper for Flo2CashDonateIPN::main(). I think we want to have this go via the processor, so CiviCRM has a clean interface against the payment processor rather than expecting a second file with magic 'IPN' suffix.

I'd love to talk further about whether we can / should standardise such a method for payment processors to implement. Eileen I think I saw in PayFlow that you had different notification handler for single and recurrent contribs, for example?

Here's what I've kicked off with anyway - a two-line wrapper

https://github.com/GiantRobot/nz.co.giantrobot.flo2cashdonate/blob/master/Flo2CashDonate.php#L276

Also, in the processor's __construct(), I added a check to see if the notify handler has been copied to extern/ ... This means admins will get a pointer in the right direction, at least until we handle this better. I was expecting this would trigger a warning on the payment processor notification page, but seems it only does it on the actual contribution page (and again in demo mode). Warning is for admin eyes only.

https://github.com/GiantRobot/nz.co.giantrobot.flo2cashdonate/blob/master/Flo2CashDonate.php#L81

Keen to discuss the best way to add a handler eg: civicrm/paymentnotify which we can use to fire the paymentNotify() method in the relevant extension as well.

"two ideas" here: http://forum.civicrm.org/index.php/topic,21543.msg90361.html#msg90361

Then sll the different parts sit inside ::paymentnotify()

If someone has their heart set on combining a hosting environment without mod_rewrite/clean url support *and* a payment processor which doesn't handle params, they will need to use something like this f2c_ipn.php which is just a file wrapper for something::paymentNotify() anyway.