(2012-10-15, 09:49 PM)Pirata Nervo Wrote: [ -> ]Not a good idea in my opinion. They could easily post the link somewhere else and everyone could download.
This is how I did it on my website:
- Every subscriber can add up to X websites to their "My Websites" page. Each website gets a private key (to prove that it is your website you must upload a file to the root of your website, otherwise it won't validate).
- The user must install MyUpdates on their forum. From there, they can either enter the private key in the settings or when MyUpdates requests it. The private key + url that sends the data is what is used to figure out which user it is. It is requested when: browsing the list of plugins we provide (to check for updates); recommending plugins; downloading plugins.
- (for download plugins only) However, we can't risk someone faking the URL and having a key from someone else and still download the plugins, so we ask for remote authentication. If the login details don't match the owner of the website URL that sent the data, there's an authentication error. (of course, if the other user wanted someone else to download illegally, they could just give them their account details as well - but hell, it would be easier to login on the forums than downloading through this system then)
- (for download plugins only) To make it even more secure, we're going to provide a PHP extension to be installed on the users's servers which will provide a small API to do the remote calls to our server giving a higher abstraction level to the process - this makes it even harder to fake the URL.
The login authentication is only requested when downloading plugins - a session is created so you won't have to login four times to download four plugins.
The two last points are not available to the public yet and may only be available to those who can install the PHP extension on their website or those who can use an ionCube encoded version of MyUpdates (the latter option is still in an early stage).
If the link is restricted to just the user that purchased it, they couldn't go posting it anywhere. If spork985 purchased a plugin, a link was generated for him, if he gives that link to Pirata Nervo, he would get an error.
I feel like your solution has a lot of overhead, especially requiring a new php extension. If you're going to go the ioncube route, why not just make the plugin "call home" on occasion and the server can validate if the domain is authorized to use the plugin. If it's encrypted, nobody will be able to remove that portion of the code.
I have piracy prevention methods, but won't mention them in public. If you want to know them you can PM me.
(2012-10-15, 09:54 PM)spork985 Wrote: [ -> ] (2012-10-15, 09:49 PM)Pirata Nervo Wrote: [ -> ]Not a good idea in my opinion. They could easily post the link somewhere else and everyone could download.
This is how I did it on my website:
- Every subscriber can add up to X websites to their "My Websites" page. Each website gets a private key (to prove that it is your website you must upload a file to the root of your website, otherwise it won't validate).
- The user must install MyUpdates on their forum. From there, they can either enter the private key in the settings or when MyUpdates requests it. The private key + url that sends the data is what is used to figure out which user it is. It is requested when: browsing the list of plugins we provide (to check for updates); recommending plugins; downloading plugins.
- (for download plugins only) However, we can't risk someone faking the URL and having a key from someone else and still download the plugins, so we ask for remote authentication. If the login details don't match the owner of the website URL that sent the data, there's an authentication error. (of course, if the other user wanted someone else to download illegally, they could just give them their account details as well - but hell, it would be easier to login on the forums than downloading through this system then)
- (for download plugins only) To make it even more secure, we're going to provide a PHP extension to be installed on the users's servers which will provide a small API to do the remote calls to our server giving a higher abstraction level to the process - this makes it even harder to fake the URL.
The login authentication is only requested when downloading plugins - a session is created so you won't have to login four times to download four plugins.
The two last points are not available to the public yet and may only be available to those who can install the PHP extension on their website or those who can use an ionCube encoded version of MyUpdates (the latter option is still in an early stage).
If the link is restricted to just the user that purchased it, they couldn't go posting it anywhere. If spork985 purchased a plugin, a link was generated for him, if he gives that link to Pirata Nervo, he would get an error.
I feel like your solution has a lot of overhead, especially requiring a new php extension. If you're going to go the ioncube route, why not just make the plugin "call home" on occasion and the server can validate if the domain is authorized to use the plugin. If it's encrypted, nobody will be able to remove that portion of the code.
Unless the link is a page which requires authentication besides the key, it could be used by anyone else.
The problem with ionCube is that it's decryptable (there are many applications on the internet to do it, at least for older versions) and any incoming information can be easily forged as well, so relying on that is not exactly bulletproof.
Edit: Plus, remember that you suggested a plugin to do everything. The user receiving a link and going to that link was supposedly out of question.
My idea assumes the user is authenticated already, if they aren't, it wouldn't work. I wasn't aware there were ways to decrypt ioncube-encrypted code, should have done some Googling I guess. I see no reason why the plugin couldn't do it, you could ioncube encode the plugin.
Anyway, just trying to throw ideas out there
InfernoSoft contacted me, wanting me to provide some feedback on the idea, so here it is.
I'm not going to delve into too much detail here, I have in the past and I have provided reasons as to why this won't succeed in the future unless several changes are made to the overall community. Before ShopMyBB opened, approximately ten designers and developers were recruited to join and help populate the marketplace before an official launch. Out of the ten that were recruited, about four or five of them fell through before the launch, other contributed shortly after, and those that didn't had second thoughts on the model. ShopMyBB had a slow start but with some marketing and some motivation, it picked up. Plugins weren't hot items over at ShopMyBB, despite having some awesome exclusive plugins available for purchase. Rather, the marketplace picked up for themes and was successful for that. With the themes success, it led to authors having enough popularity to leave the marketplace, open up their own subscription based site, and do their own thing. Which is what ShopMyBB tried to eliminate in the first place.
I've mentioned this before, but I'll mention it again since it seems to be stirring in this thread. A commission was taken to account for the fees that were being paid per deposit. The commission rates set in place were perfect and scaled well with the fees that were being paid and with the amount of back charges I had to deal with every month - about 1 out of 2 were successful and in my favor (a fail on PayPal's fault really that effects the merchant). As one of the perks of selling at ShopMyBB, the authors weren't effected by such happenings.
It seems that a pattern arose, people knew that PayPal was the weak link, they exploited its poor support for intangible goods by depositing a given amount, purchasing a product, downloading it, then opening up a PayPal case claiming that they never received the product. PayPal, despite I providing definitive proof and evidence, seemed to not decide in the favor of the merchant, rather, the buyer, who every single time provided no proof against the evidence I would provide for each case. Of course, through experience, I in the end, near ShopMyBB's closure, managed to win more cases through different approaches than I did in the beginning, but this was still a problem.
For companies such as Envato, I'm sure they've worked something out with PayPal to handle this. It would be poor on PayPal's part to ignore a company such as Envato that deals high amounts of transactions and of course, money. This is beyond the scope of this post however.
Not to make this longer than what it already is, if such a marketplace is to work with MyBB plugins and themes, the majority of the authors have to agree to sell only on that marketplace for a given period of time. A single subscription fee for dozens of plugins, even from multiple providers, is still cheaper than through such a marketplace. For themes however, the concept worked, and I'm confident it can continue to work depending on how the issue is approached. During and after ShopMyBB's existence, I have contemplated what ideas could work for both plugins and themes to coexist with only one distributor and the answer was hardly easy to reach and certainly not easy to implement.
ShopMyBB for those involved and for the community as a whole, was an experiment that answered questions that were posed before its existence and offered a baseline for tomorrow's solutions.
If I were to go back and tackle this problem again, I wouldn't replicate ShopMyBB nor only address minor issues such as commission rates as discussed in this thread. Before I would go about creating another system, whatever it may be, I would first address the community issues we have today with extension distributions (i.e, plugins and themes). Creating a new baseline with the community is key for any such system to succeed, this is how I see it anyway.
Good luck!
All the best,
Imad Jomaa.