I'm attempting to create a new page every time a form is submitted. It'll be an order status page- one that'll be updated periodically. Basically, I want the user to see a form confirmation page, and I want it to be permanent link (that they can visit later).
My first thought was using variables in the URL, like so:
http://www.example.org/member.php?id=123
And then calling the id using GET
echo $_GET['id'];
http://www.example.org/member.php would be a template, just waiting for the few details which are specific to the user.
Once I have this in place, I could use a simple if statement to check their order status.
For example,
if ($id === "user_id") {
echo "Your order is: Pending";
}
However, this seems like a bad idea, just for the security aspect of it. If someone else guesses a user ID, they can view their order status. Going off of that, here's my first question.
If the user ID is long enough, is this a secure practice?
Otherwise, what are some other methods of doing this? Creating a new page every time the form is submitted feels like a bad practice- people could spam it, and there's a possibility that someone could exploit this to create malicious pages on the site.
Any suggestions? Most major retail sites have order confirmation pages (think ebay.com)- how do they do it? Also, is my suggested URL format secure?
The most ideal scenario is you force users to login prior to submitting the form then provide them with a list of their past orders of which they can check the status providing the user_id of the order matches the id from the session of the logged in user. Give each order in the list a link like yoursite.com/orders/1 then query for an order with an id of one with a user_id matching the logged in users id to ensure they're the only ones that can view it.
If you don't want to have to do any of that and just provide a permanent link to the status page I'd save a long randomly generated string against the order and provide it to the user to check in the future, e.g
yoursite.com/orders/wUk1DhfxMh if you're using a framework with some routing
or yoursite.com/orders.php?code=wUk1DhfxMh if you're not.
Query the database to select the order with the matching code, ensure you prevent MySQL injection and sanitize the $_GET input.
Are you sure you need to make a new page?
You could just have a basic "confirm" page (ex. http://yoursite.com/order/confirm) which uses PHP sessions to create a customized confirm page–
Other than that, IF you make a new page, you should use ID's in the URL and ALSO check the session id. (ex. http://yoursite.com/order/confirm/ABsisnEALnsoSK?yyyy=xxxx) and then ALSO check if the user is logged in.
Lastly, cymath has a good example of async page-creation; although it isn't exactly what you are looking for.
EDIT: It is not page creation, it's like what I said before: one page with extra parameters in the url: a permanent link, just using PHP.
I understood that you are having some doubts about how to make the algorithm of your app, here's what i thought to this case:
Insert the order at your database, get the id of the insertion and give it to the user.
Set the page where the user will check the status to receive a $_GET['id'], check (SELECT) if this id exists in the database.
(if the user exists): get the information you need from the table
you store them. (FETCH_ASSOC or FETCH_OBJECT)
(if the user don't exist):show an error.
If you are experiencing some doubts about how to code CodeSchool is offering free trial on all courses this weekend.
If the user ID is long enough, is this a secure practice?
R: To improve the security of the transactions, try to understand/learn about PDO Class, i think it will get your code to next level if you aggregate some Good Practices and Design Patterns.
For more information, visit PHP's Documentation.
Related
So in my case, after a user chooses a certain room, the number of nights he will stay and the number of guests, the price gets calculated (depending on certain factors) and then they are redirected to the payment page where they will see the total price, which the user can change by manipulating the price parameter in the url.
on the booking page :
<Link to={"/book?pricetotal="+total_prices+"&title="+title+"&img="+img+"&price="+price+"&checkin="+checkkin+"&checkout="+checkkout+"&idr="+idroom} >
and on the paiment page i am using
const windowUrl = window.location.search;
const params = new URLSearchParams(windowUrl);
and then i get the parameter using
params.get('price')
The solution i found is to encrypt the content of the Url parameter and then decrypt it.
Is the solution effective enough or are there other ways to implement it?
Anything on the client can potentially be intercepted and manipulated by someone interested enough. Encryption likely isn't enough if you're really worried about security because the user could examine the code that generates the link and perhaps reverse-engineer it.
You can't trust anything done on the client. Instead, when the user makes their choices:
after a user chooses a certain room, the number of nights he will stay and the number of guests
Save this data server-side, and give the user a session ID if they don't already have one. Then when it comes time for them to check out, you can calculate the total server-side, and then show it to the user somehow. Yeah, don't put it in URL parameters, because that's too easy for someone to mess up, even unintentionally - but putting it, for example, in response to a fetch request, or in a data element on the page would work.
When the user enters their payment info and submits it, use their session ID to determine what the price for what they chose was. Using this approach, even if someone decides to mess with the client-side script to display something else, it won't affect the final price - they'll only be messing up their view (and if they do that, any confusion that results is on them).
That isn't going to work, since you are encrypting and decrypting on the frontend.
A viable solution would be to send the products instead of the price of the products. Then, when you send the request to the backend for payment, also send the products, and in the backend calculate how much to charge the user.
My solution was to pass props in link react-router
<Link to={{pathname:`/book`,state: { total_prices,title,img,price,checkkin,checkkout,idroom },}} >
and access them in my other function component using
const location = useLocation()
console.log(location.state)
Basically my question is similar to this one:
How to secure php scripts?
with one slight difference, the other side is Shopify.
Background info:
Shopify user bought some credits (Audible style), and wants to know how many he has available. He logs in into his account, and it says there that he has X credits.
That number comes from AJAX call to my server (I have full control), where there is a simple php script which checks the value in db (which is updated using webhooks from Shopify, each of which needs to be verified so they are secure, I think).
The script uses customers ID for a look up, and that value needs to be passed to the script somehow, and that allows someone external to just keep running it until he has all IDs and corresponding credits values.
So, my questions is, how do I stop that? How do I ensure that only authenticated users can check it, and only for their IDs.
There is plenty of info on Shopify docs about securing the connections the other way, i.e. to make sure only correct scripts have access to the Shopify db, but nothing about my problem.
As far as I know I only I only have access to JS on Shopify, which creates the problem, because everything I send to my server is visible to all.
Thanks
EDIT: I just read up on CSRF. I can easily implement checks for origin and headers, but these can be faked, right?
EDIT 2: I got around this problem by using metafields. So, instead of storing all that info on my server's db, I just use Customer Metafields to store the available credits. Webhooks are secure so that's brilliant. It still doesn't solve a problem with the next stage though. Customers will still need to be able to use their credits and get digital products, which are generated by my server. So I still need to verify the requests.
EDIT 3: Comment by #deceze and answer by #Jilu got me thinking. Yes, you are correct, I need to do that, but I don't have access to back-end on Shopify, so I cannot create session. However, what I could do (if I figure out how in js) is hash it. PHP login scripts operate on password_hash. That way you do not store a password in the db. Password get's verified again hash (or whatever you call) in the db, and it's either true or false. If true, you are logged in. So I could try to generate a token using a specific string (make it very long) and user id. Send it with the request, and using password_verify or what not, check it against the users. The one that pops positive is logged in user who requested the information. That is assuming I can hide the string in the Shopify...
Step1: Do a session login system.
Step2: Before the Ajax, generate a random token in your form or request page, put it into a input display none, send it with POST.
Verify each time if the token is set and is the same that you got.
You have now verified if the user is really logged in with session.
And you checked that he is from the right page.
You create a token out of shared secret (both Shopify and server have it), and client ID.
On Shopify:
{% assign my_secret_string = "ShopifyIsAwesome!" | hmac_sha256: "secret_key" %}
My encoded string is: {{ my_secret_string }}
On server:
We gonna be checking received hash value against values in our db, so we need to hash local client IDs using the same algo and key (that probably should be done on receiving the Customer Creation webhook).
Hash IDs using: http://php.net/manual/en/function.hash-hmac.php
$hashed_id = hash_hmac('sha256', '$client_id', 'secret_key');
Compare hash using: http://php.net/manual/en/function.hash-equals.php
$check = hash_equals($hashed_id, $received_id);
Then all that's requires is to loop through the db until you find a match. There may be quicker ways of doing it.
I need to share the username and password information to the right next HTML page after succeeding the login. Because the items in the second HTML page will appear according to the user identity and privilege.
I tried sharing the same js file between the 2 HTML pages. The first set the variables and the second get them, but they don't get passed. How do I do it? javascript? jquery? on the server side??
Thanks in advance :)
It can be done in many ways, but as the first language you mentioned is javascript, I will show you in it. So saving data across pages there are variable called session variable and the process of saving/retrieving them is called session management. There are many ways for session management, one most common way is using cookie. You can save the values in cookie, like this:
setCookie("key", "value", expire_time(integer));
And now on next page to get this value you can use:
var val = getCookie("key");
Hope this helps.
Username and password is a sensitive information you have to share it form Server side in these ways:
Use post method to share this information.
Set session on first page For user type and retrieve on very next page.
As your question says second page will appear according to the user identity and privilege. You can set user identity (User Type) and its privileges.
We have a problem with users double-clicking on buttons within our application to proceed from screen to screen.
We have implemented the ( onclick="this.disabled=true" ) on our buttons but we are convinced that it is not always sufficient to stop the fast-fingered double-click.
A simple example :-
Screen A has four input fields and a proceed button. When the proceed button is pressed, control is passed to server-side routine to validate info, set some session vars and call screen B.
What appears to happen occasionally is :-
On first click the server-side routine is called and begins validating info and setting session vars. Second-click takes control and again calls the server-side routine and begins validating info and setting session vars -> for us, the session vars are already set and this highlights the problem.
We have looked at tokens but don't think they will solve our problem.
We think that since every PHP application must be vulnerable to this double-click issue there has to be a standard method for resolving it but we have yet to find one.
If you have resolved this issue then we would be grateful if you would like to give us some insights into how we might overcome the problem.
* Thanks for the replies. Loic and Brian Nickel - hard to separate as both going for the token method via timestamp or GUID. We will have to go back and take another look at tokens. After discussion - as a preferred solution for us, we would go with the GUID token concept.
Since double click will basically submit the same form twice you can check the timestamp between two submits.
I'll take the example of stackoverflow because this site is awesome.
Let's say I vote this question up, server side, if my POST request is valid, then my POST request will be treated, and saved.
Then server side, before treating a request, they will check if this same form hasn't been posted in last few seconds (don't they?).
Anyway, my point is, give your forms a name, and when validated, put a timestamp in your users session so you can refuse their post of the same form given a defined amount of time.
Best of luck.
This is a very common problem with a fairly standard solution. Whenever you generate your form, you should generate a unique token like a GUID and stick it in SQL, redis, memcached, the session, or any short term persistent store you have. Stick it in a hidden field. You should be doing one token for each generated form.
When the form gets submitted, atomically check for and remove the token from the store. If it's there the form was submitted for the first time. If not, it's a duplicate.
For bonus points, instead of showing an error on the second submission, you can store the token with the successful result data and use it to render the same success page as you would have if they clicked once.
1) Put a for the eye hidden div (or other element) on z-top of button (opacity:0.01)
2) when once clicked (mousedown) remove div
or:
1) Remove click event when once clicked
I am working on a big site, and in the site there is a search module. Searching is done by using a a lot of user submitted values, so in pagination I must pass all these data to the next page, appending the values to url make the url very big.
Sso how can I solve this issue? I am planning to use a javascript based page submission (POST) with all the values in hidden fields to the next page the read all the values from the next page.
Will it cause any problems? Or should I use database to keep the search criterias?
I would create a server side object, possibly with a database backend which is updated by the different pages.
It is at my opinion the most clear and easy solution. Giving parameters from page to page, either by post or javascript or cookie will work too but it's more of a quirk in my experience.
Also if a search query is so complex that it needs multiple pages to create it, it might be helpfull for the user to have all the data stored on the server so he can change it more easily by switching back and forth between the different pages.
I would store all the search criterias in some kind of session-store on the server when the initial search is being triggered.
For pagination I would retrieve the criterias from the session-store and then just show the appropriate results. Also I would append some kind of key to the pagination links (so this would be the only hidden post-field) under which the search criterieas can be found.
Even though the session is per user, you might have several search windows open within the same session, and you don't want to mess them up with the pagination.
In order to make a reliable search with pagination, we need to do a bit more than normal.
We need to handle the following cases.
Once search is done, user may choose to do browser back and forward. Here, if you are doing form submission on every page, it would be an overload. Also, if user presses browser refresh button, it will unnecessarily warn him that data is being submitted.
Searching on a large database with lots of criteria is costly. Hence, optimization is important.
So you should NOT do the following:
Submit data on every page change
Not store data in cookie. (This is not secure and not even reliable.)
For large database with complex query, cache the result in session.
In case, you need very up-to-date and real-time result, ignore point (3) and try doing partial search for every page.
Thus, for your case, you can do the following:
When user searches first time, make the form POST data to a search page.
This search page will store the search query in session and generate a unique id for it.
Now render the result page. The result page will be passed the search id (generated in point 2) and the page number. Example result.aspx?searchId=5372947645&page=2
The result page will puck up the query from session using the searchId and then provide result based on the page number sent.
Using hidden fields and POST method should be fine too unless you are able to get them on the next page right.
To supplement Sarfraz's answer...
It's not necessary to use Javascript to make a POST.
<form action="destination_url" method="POST">
...
</form>