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.
Related
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
I have a web application that has form based authentication.
the application has registration functionality also. Since last few weeks, i have observed that some users with specific domain is making fake entries into the website and getting the benefits as We do not have any approval workflow.
this user either do it manually or run some script. We thought that we can restrict the registration process as per IP based, however this is not possible to get the visitor exact IP address using C# (please correct if i am wrong).
Can we do it using some other techniques. our requirement is - single registration from a machine per 2 days.
unfortunately I would call this mission impossible.
Idea 1: IP address. The user can use a proxy to register multiple accounts depending on how many proxy he can find (there are a bunch on the internet for free)
OR they could just fake the ip package by putting a random ip in the header. Since all they need is to register so it doesn't matter if the confirmation message was sent to another random guy
Idea 2: one registration per machine. I could fake as many machines as I want with virtual machine and you will have no way to tell from http request.
Alternatively I could just fake all the information with raw http request and I can do that with a script with no issue.
And from what I know you don't have the system right to read hardware id from js (correct me if im wrong)
No method is guarantee to restrict 2 registration per day but IP based method should work against most normal users. Do keep in mind that everyone using the same router could have the same IP (example school, public wifi in apartment)
You could find out the user's IP address within HttpContext object
Whatever your restriction would be - it will be based on the data the browser sends (as long you restrict a specific computer).
Your main desire is to create a "footprint" on that machine in order to use it later - per request.
Whatever your manipulation would be, you should also obfuscate your JS code.
for example, on pageload code you can request for httpheaders dedicated to that machine and save them in cache, then you generate a guid for the client which it suppose to use in order to register.
another option is to use AES to encrypt the data before sending it "on the wire", that way you won't be able to manipulate it.
the most important thing is that once you "drop" a js code on the client he can do whatever he wants, the question is how hard it would be.
**edit:
a more secured way but more complicated that i have once used is creating a sync-key.
an async ajax call to the server requesting an encryption key.
the server call will save the new guid-key in memory and will generate a new one for each request.
you can use this idea to keep track of user debug and browser behavior.
as debuging will hold the code from running the sync key will be change and you can "catch" him.
Neither cookies nor IP can protect against fake entries.
You should look at it from another side. You get unwanted entries and you don't know if it's an automated bot, or spammer, or someone who just doesn't care about your data. Instead of banning entries you should think how to validate them. For example, if you get "aaaaa" as a name and "bbbbb" as an email address - add, at least, regexp validation on client and server side to ensure you get data in a required format. Next level would be to verify the email address by querying the mail server or sending validation email. This will not only help to stop spammers, but also people who doesn't care. If you think it's an automated bot - add a captcha. In case of emergency - ban IP in the web.config (See ASP.Net How to limit access to a particular IP address to a particular page through web.config file (.htaccess similar)?)
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'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.
I am building a website for a customer who may not be very computer literate. This person knows how to use email. How can I build a website (purely html, javascript) where he can email his latest prices and the website automatically updates itself. I dont think he would be literate enough to FTP file some where. Is it possible?
How to build a secure login page and redirect to order page using only javascript and html?
How to create secure administrative section on javascript/html only website?
I would advise you to create a nice admin web interface, and teach him how to use it. Or, agree some kind of Excel format for product prices, and teach the steps of uploading a csv file. Doing things by email would complicate things in my opinion.
As in the website receives the email as data input? That's probably not going to work very well. Also, if the client is as you imply, expect those emails to be poorly formatted, filled with typos, etc. It's not a very good data entry medium by any means.
The ideal solution would be to build an admin page into the website where the client can enter the information in as controlled a manner as possible, validating the information on the spot rather than through an email (would the server send a reply email for invalid data? that would get infuriating quickly). A simple and intuitive UI should be able to overcome any computer literacy issues he may have.
I don't think this can be done purely in HTML/Javascript. It would need a server component. You would have to set up some sort of POP3 or IMAP listener that polls a mail server for correctly formatted email then dumps that into a database to update the site. Certainly not trivial.
I would build an administration portion of the site to allow the customer to log in and enter the data...no matter how illiterate, they certainly can be trained. ;-)
You could make the mail your prices thing work by just regulary checking a specific mailbox (over POP3 for example).
But that's something you won't be able to do in only pure html / javascript (and consider this: you would also need to store the mailbox credentials in client side code then!)
Email is a store-and-forward, asynchronous transport. You can use it to transport:
plain text (the body of an email)
styled text (the html body of a MIME email)
attached files
But none of those options will work well in your use case. You'd have to try to parse the body of the email if you were looking in the body for update information. -- Bad idea
And if you're using email to transport ordered data such as csv or Excel files, uploading the files directly to the website would enable a much better user interface.
You shouldn't use Excel files either since it will be too complicated for your user--he'd need to get the column (field) names exactly right, the content cells would also need to be exactly right, etc. Eg I use an excel file for input on one of my systems and a constant problem is zip/postal codes since they look like numbers but can have significant leading zeroes. Few users know how to enter them...
Recommendation create a set of web forms in the administrative section of the website. Your customer will be happy and you'll be even happier due to lower volume of support calls.