GoodForNothing Product Manager [Paid] [Deleted]

So here is my first very dirty hack, sure there will be many more to come and at some point I can gain the honour of actually calling it a proper mod.. lol

Code:
public function createLicense($userId, $productId)
    {
        $db = XenForo_Application::get('db');
       
//Ross mod - START - 22/10/2013
       
        //$newLicense = GFNCoders_ProductManager_Helper::generateLicenseKey();
        //while($db->fetchOne("SELECT COUNT(*) AS count FROM gfnpm_license WHERE license_key='$newLicense'"))
        //{
        //    $newLicense = GFNCoders_ProductManager_Helper::generateLicenseKey();
        //}
       
        //get licence from table instead of randomly generating from helper         
        $used = 0;
        $row = $this->_getDb()->fetchRow("SELECT * FROM `gfnpm_license_import` WHERE Used = ? ORDER BY LicenceID", $used);   
        $newLicense = $row['LicenceKey'];
        $newLicenseID = $row['LicenceID'];   
           
        //update fetched license       
        $db->query("UPDATE gfnpm_license_import SET Used = 1 WHERE LicenceID = '$newLicenseID'");
        
//Ross mod - END - 22/10/2013
       
        $db->query("INSERT INTO gfnpm_license (license_key, product_id, user_id, domain, olddomains, active) VALUES (?, ?, ?, '', '', 1)", array($newLicense, $productId, $userId));       
        $recentlyAdded = $this->_getDb()->fetchRow("SELECT * FROM `gfnpm_license` ORDER BY license_id DESC");
        return $recentlyAdded['license_id'];
    }

So what I've done is modded the GFNProduct manager so that rather than generating random license keys it will instead fetch a key from a table of pre-existing keys which I'm batch generating from an external licencing application.

One small concern I have is regards the way that threads work on the server side.

So what happens in this scenario?

Lets say User A clicks buy and User B click buy like a millisecond behind him. If User A thread populates newLicense with the fetchrow statement, is there any chance that a thread can come in behind it from User B and grab the same license key before the first thread has updated the table record to being used status (Used = 1) ? Do I need to implement some form of thread or row locking on this?
 
I've done another small hack on this that allows it to send a thank you and welcome email to the purchaser based on an email template and includes the licence key as well as a few links for support etc.

Regards the security error this thing seems to be a catch all that throws on this mod every time something for whatever reason fails. I've managed to nail down all of them and the last one which was intermittent
and a real pain I've figured out but haven't found a resolution.

Has anyone else had the problem whereby if a purchaser manages to return back to your site before the paypal IPN confirms as being paid it throws this security error? This seems to be what's happening. If I sit on the paypal
screen for a few seconds extra, allow the IPN to complete and then return. All hunky dory, no problems, the combo drop down is available with the license.

However, if you jump back to quickly, before the IPN clears - bang, your looking at the security error issue again.

I would imagine the same would occur if the person paid with an echeque and the payment wasn't immediately cleared.

Anyone encountered this, found a way to resolve?
 
Is there anyone still using this mod? I know it's pretty much unsupported but one thing I'm finding a bit baffling is I've been told this works and based on the latest code set I got through purchase direct from the site it doesn't appear to be complete:

This security error that I've been on about is essentially this below:

Code:
public function actionDownload()
    {
        if (!($versionDetails = $this->_getProductModel()->getFileById($this->_input->filterSingle('product_id', XenForo_Input::UINT))))
            return $this->responseError(new XenForo_Phrase('requested_product_not_found'), 404);
        if(!($this->_hasPermission($this->_input->filterSingle('product_id', XenForo_Input::UINT))))
            return $this->responseNoPermission();
        if(($subscriptionId = $this->_input->filterSingle('subscription_id', XenForo_Input::UINT)) && $subscriptionId != 0)
        {
            $licenseDetails = $this->getModelFromCache('GFNCoders_ProductManager_Model_License')->getDetailsFromSubscription($subscriptionId);
            $viewParams = array('fileDetails' => $versionDetails, 'licenseDetails' => $licenseDetails);
            $this->_routeMatch->setResponseType('raw');
            return $this->responseView('GFNCoders_ProductManager_ViewPublic_Product_DownloadStart', '', $viewParams);
        }else
        {
            $productDetails = $this->_getProductModel()->getDetailsById($this->_input->filterSingle('product_id', XenForo_Input::UINT));
            $subscriptionDetails = $this->getModelFromCache('GFNCoders_ProductManager_Model_Subscription')->getAvailableSubscriptionByProduct($this->_input->filterSingle('product_id', XenForo_Input::UINT));
            $viewParams = array('product' => $productDetails, 'availableSubscriptions' => $subscriptionDetails);
            return $this->responseView('GFNCoders_ProductManager_ViewPublic_Product_Download', 'GFNProductManager_Product_Download', $viewParams);
        }
    }

The intermittent issue I was having was because sometimes I get a return from paypal before the IPN processes to completeion. Meaning that GFN doesn't at that point have the licence processed. When this page is called back after purhcase this actionDownload() is called and the code in blue fires to check the _hasPermission function. What this code does is checks that there is a valid record for this product/User ID in the GFN_ProductSubscription table. Now because the IPN from paypal hasn't cleared, there cannot be a record in that table. So the check fails and this snippet from above

Code:
if(!($this->_hasPermission($this->_input->filterSingle('product_id', XenForo_Input::UINT))))
            return $this->responseNoPermission();

throws back the responseNoPermission which is the security error I mentioned.

Another way to check this is to put through a test payment that doesn't clear instantly, so when you get to the paypal screen and log in, click payment method and change to echeque which doesn't have an instant clearance. Then push it through. This will fire this same code.

As far as I can see this is not a bug but incomplete code as no handler has been coded for the situation to inform customer that the Paypal payment is yet to clear and that the product will be available on clearance.

I can't figure why there is no mention of this on the thread as it seems a fairly obvious issue. Or perhaps my version of the code I got from the dead GFN product site is old or something. Scratching my head at the minute.
 
The site you purchased from uses the very same add-on to process and deliver the product. As I've said before my site, http://xenmediagallery.com uses it also and you had no issues there. I only made very minor customisations on my version but nothing at all to do with the download or purchase of the product.

Do standard XenForo paid user upgrades work or do you get similar errors?

Have you tried installing the add-on on a different server or XenForo installation? With no other add-ons? No custom style or modified templates? Essentially you really should try this with a fully clean XenForo installation. As others seem to be using this without issue it, sadly, suggests a configuration problem or similar from your end.

Hope you get it sorted soon.
 
Yes paid upgrades work no bother.

I've debugged the code and in my version it is plain as day. I don't see how it can be a config error given the code that I just posted. Either I have a different version from everyone else. Or not everyone has tested this as thoroughly as I have.

I agree the normal payment process works yes but this is not the normal process I'm talking about. I'm referring to the issue that can arise if a customer pays for their product and for whatever reason the IPN doesn't clear before the paypal redirect sends the customer back to the /download page.

The download action is doing a validation based on the licence subscription record that can only exist after IPN confirmation clears. If it doesn't exist it cannot make the confirmation and so it throws a security error. The reason I suspect it happens to me more frequently is because I've made a poor choice of host (my site seems unusually slow at times). When I test this on my dev box which I've set up through the paypal sandbox and have the full call back working through my router which redirects the request to my internal http address, it works every single time but only because there is no delay and my local box processed the callback before I can get back to the download page.

If I enter a payment that is not instant clearing, like an ECheque it fails every single time regardless of local or host because it doesn't matter how fast or how slow the return is. The IPN will not process until it's cleared a few days down the line.

See pic one for the response:

Snap 2013-10-25 at 16.32.33.webp

I can get the same error up on your site and am assuming it will be the same if I had to run the use case through paypal. I haven't done it via the paypal route as I don't want to mess around with your stuff but I know what kicks the error up so assumed a direct link to the download without a licence subscription would generate the same error which it does.

Snap 2013-10-25 at 16.31.53.webp

For me that is not an acceptable message to show a customer when they've just purchased my product regardless of whether their payment has cleared or not.

I have changed it to respond like this on mine:

Snap 2013-10-25 at 16.45.45.webp

I can't see any other way around it or how others do not get reports from customers about this issue. Perhaps it's like I said I'm the only one with the slow host.

If you want me to test it on yours Chris let me know and I will put through an ECheque on a new account and see what yours responds with and let you know. (So long as you cancel it).

It's up to you. I'm going with what I've done here although as suggested I will set up a totally complete vanilla install on my laptop right now and test it for piece of mind but I don't think it will be different from what I've found already.

Ross
 
Last edited:
For me, it's edge case enough to not worry about.

I would guess that, in theory, it is possible for you to trigger the same thing on any site. But the chances of doing so during normal usage are slim enough for me to not worry about it.

Besides, this product is just a stop-gap until I have time to write my own.
 
For me, it's edge case enough to not worry about.

I would guess that, in theory, it is possible for you to trigger the same thing on any site. But the chances of doing so during normal usage are slim enough for me to not worry about it.

Besides, this product is just a stop-gap until I have time to write my own.

image.webp
Chop chop....


:p
 
From this site: http://7dollarforum.com/YaBB/YaBB.pl?num=1197957510/1

"Whether you call it the "Waiting for PayPal" thing, the PayPal timeout, the 55-second loop, or whatever, if there's one thing that hangs up new users of the scripts more than any other, it's this issue.

Why this happens

When your customer returns to your site after clicking "Return to Merchant," the script immediately looks for a valid purchase record based on the IP address of the user's connection. This IP address was recorded when the user was sent to PayPal and, if the payment was recorded, the address is included with the transaction.

If a purchase record cannot be found with the user's IP address, the script begins a one-minute countdown, checking for a valid purchase record every five seconds.
If after one minute the purchase record cannot be found, the script displays an error message with some suggested reasons for the problem."


Seems to be the issue. So the GFNProductManager doesn't look to be following standard practice as it seems delayed IPN's can happen frequently enough and there is no count down / checker as a fail safe.

I'm going to try and implement this because I'm getting this message often enough that it's a hindrance.

The other route is I might try and get my installation working on google app server over the weekend and see if the speed improvement helps circumvent it all together.
 
I am still using this - and attempting to fix some of the issues up - it has just made it harder now that his website has gone.

Think we need to turn around and turn this into a community project in order to ensure it works for all of us for 1.2

@Chris Deeming you stated that you had hacked the code in order to have the product images working - are you able to share this?

Anyone have any ideas for the best way to have license keys for xf styles/themes?
 
@Mr. Goodie2Shoes any update with this product dude?, or you refund my money?

Wait what, do XenForo addon purchases now function as subscriptions? Cause if not I don't see how you have anything to complain about, let alone ask for your money back.

If you didn't like the addon in the form that it was in when you bought it you should not have bought it. Done.
 
As mentioned in the resource description the development of this add-on has been shut down. The development of a complete store front add-on is still in the table and once the first private beta starts, everyone who once bought this product will be eligible to participate.

Well, I purchased this product... ;)

LICENSE CERTIFICATE
==============================================

This document certifies the purchase of:
Product Name: Product Manager ( https://www.gfncoders.com/products/product-manager.3/ )
 
Top Bottom