So I am looking at the latest osCommerce 2.3.1 version and I see various new parameters injected with the release. Few years ago there was a debate specifically with the 2.2 RC versions about affiliated links injected into the core code. This made several members unhappy including me. Not because of the osCommerce promotion as a whole but because these parameters were mangled with source code.

It is time consuming with every update to go through each line of code searching and removing various promotion elements, before deploying the code to a site. It's also the main reason of my absence from the forum for the past several years.

The reasons for removing them are obvious. On the one hand I don't want to argue with anyone who may discover them sometime in the future, and at the same time it seems misleading and suspicious despite the good intentions of promoting the osC project. It just seems like spam the way it is done. In my view when you want to promote a project you need to do it in a a transparent and legitimate way and at the same time document it.

Back to the topic now, apart of the RC affiliated parameters and links I now see new parameters injected into payment module handlers. I don't think they were left for testing purposes. Looking at file admin/ext/modules/payment/moneybookers/activation.php I see two instances.

$result = $mb->sendTransactionToGateway('https://www.moneybookers.com/app/email_check.pl', 'email=' . $HTTP_POST_VARS['mb_email'] . '&cust_id=2167348&password=281f2d9f44066eab75db5afb063952b1');
//...
$result = $mb->sendTransactionToGateway('https://www.moneybookers.com/app/secret_word_check.pl', 'email=' . MODULE_PAYMENT_MONEYBOOKERS_PAY_TO . '&secret=' . md5('281f2d9f44066eab75db5afb063952b1' . md5(MODULE_PAYMENT_MONEYBOOKERS_SECRET_WORD)) . '&cust_id=2167348');

cust_id and password parameters are hard-coded. What does it mean? Is it some sort of simple affiliation? Left over code? If I have to integrate the moneybookers at some point I guess I will find out. And this leads to lack of trust at least on my end. It will take long time to review the various payment modules and to figure out what they're hiding. What the module configuration defaults are and go through each spec before cleaning them up.

Maybe you would say why bothered? But I will be the one who integrates osCommerce for somebody. If the code has problems or the site owner doesn't like what he sees I will be the one to do code changes.

I had customers in the past who wanted to me to remove the copyright notices of osC from the admin end and I refused. There is a copyright policy about it and is going to stay not matter of the customizations in place. It is also beyond my understanding why the various affiliate parameters are hidden in the code this way, instead documenting them and expose them in a proper way for instance with banners or other promotion/resource materials.

The older affiliate links are still in the latest versions of the RC releases. They are located inside the includes/languages/english/modules/payment many under the description definition with an explanation about the osCommerce credit but hidden by default. You will have to click a link to open up the explanation text from the admin end.

As I mentioned on the osC forum on my last post (it is now removed) the osC team should lead by example. If the example towards the community is to hide various unknown parameters for profit the likelihood of others doing the same is very high. Imagine now what happens when you have to check every contribution you download for hidden code, or if you're on the "wrong" side you simply change all these parameters to service your own interests and nobody could say a thing because after all that is the prime example.

And why complicating things and not just put affiliate info in the checkout process. It was done several years ago by another member and was heavily criticized by the osC team. Seems the opposite is now in effect.

For those who deploying osC my recommendation is remove unused modules in general. They're still security issues even with 2.3.1 from the included modules and is much easier than reviewing the whole code tree figuring out what each of the parameters really does.

Personally I prefer to deploy custom versions based on the older MS2.2 simpler to manage and customize. And in terms of security they're more secure. Seeing the admin wide open right after install and the first thing you going to do is to lock it down from the host. That's the proper way of protecting a directory.

Don't be fooled by the osC admin login dialog built in the latest RC releases, Files can still be accessed from outsiders because there are way too many parameters, servers and configurations.

Going back in history a little bit here are the relevant quotes from the 2007 discussion on the osCommerce 2.2 RC1 release.

Web Host [Jul 8 2007, 02:35 PM]

In catalog/includes/languages/(language)/modules/payment/paypal_ipn.php and catalog/includes/languages/(language)/modules/payment/paypal.php Threre is the line

<a href="https://www.paypal.com/mrb/pal=PS2X9Q773CKG4">Visit PayPal Website</a>

Is

PS2X9Q773CKG4

a referrer link? If so who does it belong to? (osCommerce, Harald, someone pulling a fast one)

enigma1 [Jul 8 2007, 05:27 PM]

I wasn't aware of that. It belongs to Harald.

I checked the referal with the regular osc ms2.2 by paypal email address to the referral id PS2X9Q773CKG4 then I activated the std paypal and checked out. Was that slipped-in by mistake with IPN testing?

I cannot find references in the documentation.

dynamoeffects [Jul 8 2007, 08:54 PM]

Also note that there are referral links in the 2checkout language files. In /includes/languages/LANGUAGE/modules/payment/pm2checkout.php:

<a href="https://www.2checkout.com/2co/signup?affiliate=1255821">Visit 2Checkout Website</a>

Credit Card Test Info:

CC#: 4111111111111111

Expiry: Any');

Vger [Jul 8 2007, 09:58 PM]

I'm sure it is a mistake (double mistake) which will be rectified - especially after the heavy criticism that Greg Baboolian got for inserting a referall id into his version of the Pay Pal IPN module without telling people it was there. Vger

Harald Ponce de Leon [Jul 9 2007, 03:52 PM]

There are indeed referrer and partner IDs embedded in the "Visit [Module] Website" links shown on the Administration Tool -> Modules -> Payment Modules page to help increase our finances for when new store owners signup with a payment service provider. This is the only place our referrer and partner IDs are being used in the source code. Some payment modules pass the shop installation version along with the transaction (eg, "osCommerce Online Merchant v2.2 RC1") to help identify issues when a problem with the transaction has occurred, and has no relation with any sort of partner program.

enigma1 [Jul 9 2007, 06:09 PM]

I quite frankly disagree with this notion as there are side effects I see, among others:

1. By having referral links, ids or other undocumented marketing methods with the source code, forces, whoever deploys RC1, to have to review and revalidate the entire framework, leading to deployment complications and code modifications.

2. You lead by example with the osCommerce source code releases and so the developers and contributors who upload modules, code segments and post technical articles to the contributions section and/or the forum could follow the same paradigm. In other words enclose/wrap source code with referal ids or other hidden methods to promote their own interests. For instance someone could post the exact same osC php code with a different referral on a topic. This may lead to non-technical discussions across the forums, strange contribution updates with the sole purpose of changing/inserting referrals. In addition it makes it extremely hard to filter such posts/topics or contribution updates.

3. Developers who contributed packages may have their own contribution/thread manipulated by someone inserting similar marketing methods in the code and therefore may have no interest to follow up or to assist members with technical issues.

In the past you strongly opposed this same approach, (was criticised as "spam" to say the least). Since you have full control of the osC site and forums increasing the financial support of osC could be done in a transparent and documented manner. If there are financial issues that cause problems with the forum operation, osC code releases etc., please state them so the community members are aware and can assist in the most effective way.

And that was my last post in the osCommerce forum haven't posted there since

What follows is few more quotes from the particular discussion

Harald Ponce de Leon [Jul 10 2007, 01:15 AM]

[1] That is the advantage of an open development model where the changes we make to the source code can be publicly seen on our development site. There is no need to "review" or "validate" the "entire framework" due to a non-hidden referral ID existing in a link only the store owner can click on when wanting to go to the website of the payment service provider.

Linking to the website of the payment service provider with a referral ID does not harm the source code or harm the privacy of the store owner in any way whatsoever. It is the same link used in our documentation (for 3.0) and on our website (eg, our gateways page).

[2] We still believe in ethical coding and business practices. There are also already many contribution authors who add their PayPal links in their documentation. Any sort of "hidden methods" are not allowed where the contribution is removed once an issue has been forwarded to the team.

[3] This is usually noticed by the original contribution author. If such changes occur the uploaded file in question will be removed from the contributions section.

Vger [Jul 10 2007, 01:27 AM]

Maybe I'm being a little dim. Or maybe I'm being a "believer" (took a lot of searching to find out what that meant and that it was not intended kindly).

I just can't see the difference between this and the Pay Pal Referrer Id that Greg Baboolian used in his Pay Pal IPN module. It caused so much fuss that the 'Official osCommerce Pay Pal IPN Module' was brought out as a possible replacement for it.

Vger

Harald Ponce de Leon [Jul 10 2007, 01:35 AM]

Hi Rhea..

Gregory had embedded his PayPal referrer ID into the payment module itself and was being passed in each financial transaction made with the PayPal payment method without informing the store owner about this in any form. We don't allow this hidden practice as it breaches the privacy of store owners and their customers.

RL2000 [Jul 10 2007, 08:21 AM]

I'm going to have to side with Vger and Monika on this one, putting referrals into links is just a little too indecent in my book.

I would indeed strongly discourage this behavior, Harald, that's just not kosher.

Hi Rene..

It would be great if you could provide reasons why you think having referral IDs in the payment service providers website link is indecent.

Thanks,

RL2000 [Jul 10 2007, 08:33 AM]

The reason for this is that even though you might believe it to be transparent, it really isn't for your core users. Now, if you were to make a link stating that if people used this link to enter the site they would be supporting the project, then I would have no problems with it, hell, I wouldn't even have a problem with a DONATE! paypal button posted all over the admin module, but no matter how you cut this, it's a hidden referral and that's just not cool.

Monika in Germany [Jul 10 2007, 09:20 AM]

I couldn't agree more. I have paypal links for account opening on some stores, especially those that have many customers that may not be a paypal member yet. In such a case, I ask my clients if they want to set up a merchant ID for referrals. Not once in my carreer has it occured to me yet to not ask and add mine or to add links always in any case and use my referral ID. Probably a "believer" also, shake hands, Rhea. Obviously, I charge for work, I even accept donations, but all transparent.

Harald Ponce de Leon [Jul 10 2007, 09:50 AM]

Hi Rene..

Thanks for explaining your reasoning.

The link is not a donation link nor a form of advertisement. We know we can add donation links and even banners throughout the Catalog and Administration Tool pages however this is something we do not want to do simply due to our principles. That we have embedded a referrer ID in a link linking to the website of the payment service provider gives us a bonus that would otherwise not be provided and be thrown away. This is not even a hidden referral link but we obviously have different thoughts on what a hidden referral link is.

We will be sure to note this in the documentation for the final 2.2 release to have an official explanation.

RL2000 [Jul 10 2007, 10:14 AM]

Harald, I know it's not a donation link, I know what a referral is. I baffled that you can't see that it's hidden from view, regular people don't look at the href but only the link text. I just find stuff like that very unpleasent and let me tell you this, if I downloaded some open source software for the first time and saw something like that, it would definately make me suspicious of the entire code. Now, I know the project and have spoken to you on several occasions(like on skype etc), I know you're not a bad guy, I just think this practice is indecent at best. If you made a "Click here to go to the site and give osC a referral bonus" link then I would have no problems with it, it's the WAY it's done, not that you would want the referral.

And right now, in this very moment, isn't "we" you?

This is just a part of the original thread most refernced my comments. As you see in several points was mentioned that the link is not part of the "code". To our view it always was and still is. And in fact with 2.3.1 is now also part of the payment handlers used with every transaction. So much for this debate.

As of the side effects, here are they are:

http://code.google.com/p/oscmax2/source/browse/branches/dev/2.1/catalog/includes/languages/english/paypal_express.php?spec=svn1030&r=1030

And they are many more. Others just twisted the affiliated links replacing it with their own  It's the lead by example effect, as I mentioned several years ago.