I was thinking a lot about plugin protection and it seems there isn’t a way to actually check the validity of user and/or host, is there? Basically, if your plugin is purchased one time, anyone can copy it and use on some cracked versions of Photoshop, right? 
First thing I can think of is some kind of a login system, ie hosting all registered users in a db on your server and require them to login before they can access the funcionality.
But yeah, this requires an internet connection, so I don’t know if this would be an option.
I don’t really care about internet connection being required. But even your suggested approach doesn’t protect from invalid users, because there’s nothing to validate them against 
I mean, anyone can enter any email or whatever and there’s nothing to check if that user actually bought your plugin or using it on some cracked version. Unless of course you implement the purchase yourself on your own server, but in such case there’s no need for Adobe Marketplace
I remember that on cep there was the possibility of checking that if photoshop did not have a license it would not be installed. I don’t know if uxp can do this?
What about this userId? You can implement a license key activation system and provide a bunch of keys to Adobe to distribute upon each purchase. And when a key is used, you can bind it to the userId that made the request.
Does anyone know what this user ID actually gives? Is it tied to a machine? I’m quite sure cracked software returns some kind of ID too. It might even change on every start, IDK. Is there a way to validate if it’s a legit ID?
Would you mind explaining how would this work? What does this mean? What keys and whom to exactly I should provide these keys? How would I know the key was used and which user? At which end this activation system would happen if there’s no API to validate any keys or purchases?
I just saw this related request
6 years…! Crickets…
I meant creating your own server, generate a list of license keys using a library like uuid, and store them in your database. Then, provide these keys to Adobe support, who will pass them to FastSpring for distribution. When a user purchases your plugin, they receive a key. Upon first use, prompt the user to enter their key, then validate it against your server and link it to their userId (you can collect other user specific information like cpu, gpu, …etc and make use of them to create a more unique userId). your server will respond with a token, which you can store in secureStorage. Each time the plugin loads, send this token to your backend to verify its signature and ensure the user remains authenticated.
This part doesn’t make sense to me at all. Is there some API for that or do you mean I’d need to generate a random unknown amount of keys and send them via email and wait unknown amount of time until they’re synced with FastSpring? If so, that’s not an option in this century 
Also, this requires double the work, which might break at any time if Adobe decides to switch from Fastspring at some point.
There must be an API on Adobe side to validate license keys, which should be generated on every purchase
I think it’s mentioned on the last dialog box before you submit a listing. you generate around 100 keys and send it to them via email as .txt file or something. And you’ll be notified when those keys are about to run out to provide some more
Allow me to express my humble opinion.
Basically in all approaches to UXP Plug-in security, I haven’t found anything that really makes it safe, (I mean, in case there isn’t a way to crack it). I myself receive several third-party plugins sent by customers saying that the plugin is free for the simple fact that someone probably; He went there, got the installation files, copied them to a specific folder, compressed them, changed the file extension to ccx and that was it.
Sorry for my frankness, but I didn’t even intend to sell it, my plug-in is for personal use and I developed it due to a very extensive demand for work in the photography field.
I have already sold to some professionals using user and machine recognition with a time variable for subscription, but every time it ends I have to create a new installation, which in this case can only be supported personally and which makes the idea of selling on a large scale unfeasible.
I’m not really worried about the use of the plugin on legal versions of Photoshop. I believe I now have implemented the layer of protection sufficient enough, that it’s not worth the trouble cracking it, considering the price of the plugin. I have also implemented the LemonSqueezy verification and intend to start selling actual dowloadable CCX files using their platform. They basically take care of the server side verification.
My main issue is, that there’s absolutely no way to protect plugins sold on Adobe Marketplace to be later used on a cracked version of Photoshop (even if there’s no direct CCX download), without implementing verification both plugin side and server side, which again you have to develop yourself…
1 Like
@Karmalakas read this:
Share a License
“Some plugins require users to enter a license key before use. If the same is to be done for your plugin and FastSpring is used to handle your payments, you should share 100 license keys with the review team via the ‘Notes to Adobe reviewers’ section…”
If you don’t mind me asking, what approach did you take to implement the security layer?
As I mentioned before, that’s not how license keys should be shared in the 21st century. Also this requires your own server infrastructure to validate the license. And this approach doesn’t provide any other license management. If you want to limit license usage only to one or two machines - even more development. And don’t get me started on different discount models management… Honestly - why bother, when there already are ready to use full feature solutions to choose from?
Basic idea (thanks @Jarda 
):
- Code obfuscation
- Files checksum generataion
- If any of the plugin files are tampered with, plugin is deleted with only the manifest and index.js files ramaining, showing just a static HTML
1 Like
If you really wanna have full control over this, implementing your own security and not relying on API’s is the best, I did my own platform / server since the beginning when I had CEP and 200% worth it. Do it in your own server and build a good software architecture to make it work as you want.
Pros:
- No limitations. You have full control over how you want to validate if the user is using or not the plugin.
- Data collection. You collect the necessary data and handle it in your server to make the best user experience as possible.
Cons:
- Takes some time to build the logic and requires experience about server validation.
Your issue was the cause of decision why I prefer to build my own server, took time but learned SO MUCH from there and user feedback with their experience using my software.
I encourage you to develop it your self, it is fun and you’ll learn a lot through it. It is not for everyone or lazy people for sure, but if you are very passionate enough about code you’ll find very fun to build your server structure and security, plus you’ll have full control without limitations.
About payments in your server, Stripe and PayPal have amazing API’s to handle it.
I’m a one man army who build the entire full stack of my server and platform, security and all my plugins back and front end, the marketing and built a community that is growing everyday. The knowledge I’ve built in few years is immense and I have lot of fun implementing ideas without depending on anyone or anything, I can build whatever I imagine and it really worth it. Indeed is a hard work but as I said, I’m very passionate about this so for me this is playing with code every day that I wake up and I love it.
You can do it 
!
3 Likes
I’m a full-stack PHP web dev myself, and I know exactly how much it takes to build a reliable system from scratch 
For now, LemonSqueezy offers much more than I need, so I’ll stay there (hopefully they’ll aprove my store soon) and see how it goes. Maybe some day I’ll build something myself (maybe even share full code, because if I decide to build, I’d do it on Opens Source CMS, which I’m familiar with), but not yet 
1 Like
Has anyone checked how UXP handles sending and receiving data from a remote server, such as how it sends headers and cookies? Does this even work in UXP? I mean, they can’t properly implement CSS, let alone the rest.
Did you try with the fetch API?