Is it anyhow possible to check from a website with paypal js client lib and API's whether a user/customer has already payed for a digital downloadable good?
Is it possible to check whether the user has a valid subscription (which is payed)?
Is it possible to allow a purchase only once and paypal redirects the user back with a notice he already has purchased it?
What I like to achieve:
If the user has already payed for a document/subscription, he should not need to
pay a second time but rather directly get the download. My idea, if
the user previously payed for it, I'd like to replace the paypal pay
button with a download button.
The whole check should happen from the Website and not
server-to-server communication.
Download must no be secured if not payed. I do know this may NOT be secure and the user may be able to download the document without paying. That is okay, because this is a test whether the user is willing to pay for something and implementation should be as simple as possible for now.
I lack to find the functionality within the PayPal API's. I found the list payments, but for me this seems more like a server to server API or?
How do you know who the "user" is when they visit your site? Are you proposing having them log in to your site with their PayPal account? (Connect with PayPal integration?). That would be very unusual, and unsuitable for people who paid with PayPal as a guest.
So what you are proposing is somewhere between impractical and not possible.
Instead, you need to authenticate the user yourself -- provide them with a username/password to login, for example, or a unique link, though be warned such links could be shared. Then, once authenticated, check your own database as to whether they paid/subscribed or not. You need to maintain your own records.
Expecting a payment processing service to somehow do any of this for you is a misplaced expectation.
Typical implementations are to send an email with the download link, or to use a digital product delivery service such as for example e-junkie
Related
I am trying to figure out if it is possible to click on a button on the Amazon website from outside of the website.
For Example: At the bottom of every product review is a "Helpful" button. If a review was helpful, the reader/shopper can click this button to let the reviewer (and Amazon) know that the review was helpful. (It's basically a "Like" button).
What I'm trying to accomplish:
I want to post my reviews on my own website/blog and still obtain "Likes" without asking readers to click a link to a product page, then search for my review, then click the button.
You probably won't be able to do what you have in mind.
JavaScript can generally access information on another domain except if specifically configured in the origin website through CORS. Unless you own amazon.com, you won't be able to configure amazon's CORS headers to make them accessible to some JS running on your website.
You can however, from your website front-end, make a request to your website back-end that would be able to access amazon's data just like your browser does. Using a browser emulator like Puppeteer, you'll be able to launch an amazon page and programmatically retrieve infos, click on things and do other stuff.
However, the page that Puppeteer will be able to spin up will include credentials (cookies, localstorage content, auth token, etc) provided by your server, so Puppeteer will not see the same amazon.com your user sees on his browser, unless your user agrees to give you its amazon credentials, and at this point I'm pretty sure no user would do that, and that would not be authorized by amazon's terms of services.
TL;DR even if what you have in mind is not impossible, it would weeks for your and your team to code a system that would potentially allow you to do that, and that's provided the law is on your side, which is probably not the case.
I am trying to understand what Apple is imposing as its new policy to ask developers to use Apple's own authentication mechanism.
Apparently Apple is using a different method compared to other authorization providers, such as Facebook and Google.
Apple's approach is, you receive the name and email at first login (say sign in). And after that you only receive a user id (something like 001134.432857YEASUREe274bxy231b3.0884 which means nothing unless you save it along with email and user name at the sign up).
Up to now everything seems fine.
The part that makes me confused starts here.
According to GDPR, as far as I know, you have to provide users a right to delete all their data from your servers.
And in this case, once we delete a user's all data then the correlation between "email+fullname vs user id" is lost for ever.
If the same user decides to reactivate herself, this time Apple will not send you email+fullname and this will impact the user experience.
Is my understanding correct? What is the solution for this problem?
References:
https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_rest_api/authenticating_users_with_sign_in_with_apple
https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_rest_api/verifying_a_user
https://docs.expo.io/versions/latest/sdk/apple-authentication/
I am making an image gallery, and I wish to have a vote up button people can press to increment the number of votes an image has received. Obviously I don't want people spamming the vote up button, so I want to limit each user to 1 vote up.
I do not have access to any kind of database (except writing to files), and a login system would not be good for my target audience.
What is the best way to store whether a user has visited the page before? Would it be better to use PHP or JavaScript or something else for this?
Without an authentication system, you can limit the action of a user temporarily, but the user can trick your system to vote multiple times.
Here are solutions not using a login/auth system (and their drawbacks) :
You can store the upvote action client-side with cookies, localstorage or any other mean, but the user can clear all off that to regain the right to vote again. For most people it can be ok (depends on your audience), but any techy guy wanting to cheat the system will be able to do it.
You can store the update action server-side with a reference such as the user-agent or the IP adress. But these "authentication" system are not reliable : user can share the same user-agent and change them easily. Several user can share the same IP adress and use proxy to change their IP adress.
The third solution is to use an external system : a facebook +1 voting system (facebook uses its own auth system) or google+ or other external services. User won't be able to trick the system, but you don't own the upvote count on you side and someone without a facebook or google+ account will not be able to vote.
Personally I would go and find myself a database... but if you don’t want to use one, you can still write to a file. For example: Create an array and store the IP address of the user in it. Than write this array as JSON code to a file (json_encode) and store it. When a user clicks the like button, read the file, decode the json (json_decode) and check if the IP address exists in the file. If not: add to array and store to the file. The amount of likes, is equal to the amount of IP addresses in the JSON object.
The best way to implement this, is to make an ajax call when the like button is pressed. Than the visitor won’t see a page load.
Note: Technically you can set a cookie, to "remember" that the user already clicked the button. That would save you some reading of the file in which the likes are stored.
I have a site with a tool on it. The tool is an HTML form that clients will save a local PDF after filing out. The form works. PayPal can be integrated for payment.
All of the code is run on the client side via javascript. I do NOT want to store any data or credentials on my server.
What I don't understand is how to protect this particular HTML file until someone has paid for it. I was hoping for maybe a randomized string for the file name that lasts 48 hours or something. Just not sure what to search for at this point.
The site backend is node.js and using Foundation CSS if that helps.
Thanks in advance.
If you use a unique/random filename as you mentioned, and have it expire after x amount of time, that will obfuscate, but not protect/secure. Obfuscation is probably more than enough for your needs, but not something that we should be providing as an official StackOverflow answer... so I continue.
It roughly sounds like you have one of those, excuse my wording here, "cheap self-help/how-to/etc pdf for sale that should really be free and probably is somewhere" type of websites. I am sure your product is fantastic and is of the utmost quality, but if you know the sites i'm referring to, and my assumptions are correct, the information below should be helpful.
As far as I understand your needs, you want a version of business logic similar to this:
User fills out form on your site
User gets redirected to paypal, or is "called to action" with a paypal button.
User pays or doesn't pay
User downloads/accesses file only if they paid.
There are a few options you can do:
If every user is getting the same file, the below methods should be similar, but simpler
Ensure you set the CUSTOM value for whatever PayPal payment method you're using to the unique ID you created for the user, and an email address if you can collect that from them. Then use PayPal's IPN to wait until a payment has been received. This IPN notification will have the CUSTOM value for the payment, which is unique per user per payment per file, and you just email them the appropriate file.
Use PayPal's Encrypted Website Payments API to create a secure button (pass BUTTONCODE=ENCRYPTED) using node.js. Secure buttons do not expose the form variables, so the client would never have access to the RETURNURL which is where your secret file is at, so there is no way they can attempt to download it. If they did find some way to decrypt the button, it would have taken them much longer than your 48 hour expiration. Either way, I doubt (no offense intended) users would be this interested in your product.
There are more ways to do this without storing user credentials on your server, but no way to do this without storing some type of data (see: code) on your server.
I'd like to securely save a user's credentials to related web sites and automatically log them into those sites when they log onto ours. I understand there are some security implications to this, so I'd like others' feedback and see what has been successful for others in the past.
What technique have you used to auto-log the users in? I'd prefer not to have to duplicate the HTML form and submit it through javascript. This seems error-prone if the form ever changes. I tried putting the login form inside an iframe, but it seems like the owners of the site are able to block this (see attached screenshot). Do you know how they do this?
Secondly, what was your approach to save the credentials so that they were "safe".
...Peter
I would suggest using cookies to save a session certificate to the users machine. A good value for such a cookie would be;
userid, timestamp, hash(userid . timestamp . global_secret)
The value of global_secret needs to be very long (40 characters or so), to avoid people cracking the hash, as doing so would allow them to create their own credentials with other peoples user ids!
The 'other sites' would check for this cookie, calculate the hash using the cleartext values of userid, timestamp and the global_secret (which all sites know), check it against the hash supplied, if they match, then this is a valid certificate.
You would then need to check the timestamp and decide if this was a 'new' enough certificate to allow access.
This is the standard method.
Do not do this. Read the terms of services for each site (ie facebook):
https://www.facebook.com/terms.php?ref=pf
(3.2) You will not collect users' content or information, or otherwise access Facebook, using automated means (such as harvesting bots, robots, spiders, or scrapers) without our permission.
(3.5) You will not solicit login information or access an account belonging to someone else.
(4.8) You will not share your password, (or in the case of developers, your secret key), let anyone else access your account, or do anything else that might jeopardize the security of your account.
You put yourself and the user at risk.
These sites have an API for a reason, so I suggest you looking using those as a more "legal" approach.
So if you're trying to retrieve a facebook user's information, create an app, have them authorize your app, then retrieve the information through facebook's api (example). You can also post to their wall with this method.
https://developers.facebook.com/
https://dev.twitter.com/
https://developers.google.com/
The common method to auto login a user is to set an cookie with an random string. It have to be that the random string isn't guessable. At the server you check the cookie and if it matches then you login the user. But if your site isn't completely served with https everyone who can listen to the traffic can pretend to be the user. To increase the security a little bit you could implement that a random string is only valid for a view days and then the user has to login again and a new random string is generated. So if someone steals the cookie-id the attacker has only for a certain time access to the account.