We Keep Coding

Avoid URL parameter Manipulation

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)

How to create a new page on form submit?

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.

How to paginate a search result using same query with different skip and limit values

Some of you might argue that this is a question for programmers.stackexchange.com but, having read through Help Center of Stack Overflow I believe this is a specific programming problem and I am more likely to get a response here.
I have a webapp that uses ExpressJS with Neo4j database as backend. I have a search screen, where I would like to use the power of Neo4j's relationships. The search screen accepts one or more values (i.e. manufacture year, fuel type, gearbox, etc etc) and then make a post request to ExpressJS where I construct a cypher query using the parameters of POST request as shown below as an example:
MATCH
(v:VEHICLE),(v)-[:VGEARBOX_IS]->(:VGBOX{type:'MANUAL'}),
(v)-[:VCONDITION_IS]->(:VCONDITION{condition:'USED'})
WITH DISTINCT v
WHERE v.manufacture_year = 1990
MATCH (v)-[r]->(info)
RETURN v AS vehicle, COLLECT({type:type(r), data:info}) AS details
Let's say that running above query, returns the following three vehicles and its properties
If more than 20 vehicles in result then I want to paginate the result and I know how that works, we make use of SKIP and LIMIT as shown below:
MATCH
(v:VEHICLE)
OPTIONAL MATCH (v)-[r:VFUEL_TYPE|:VGEARBOX_IS|:VHAVING_COLOR|...]->(info)
RETURN
v.vehicle_id AS vehicle_id,
v.engine_size AS engine_size,
v.published_date AS published_date,
COUNT(v) AS count,
COLLECT({type:type(r), data:info}) as data
ORDER BY v.published_date DESC
SKIP 20
LIMIT 16
Here is the workflow,
User navigates to search screen which is a form with POST method and various input fields.
User selects some options based on which he/she wish to search.
User then submits the form, which makes a post request to the server.
This request is handled by a ROUTE which uses the parameters of the request to construct a cypher query shown above. It runs the cypher against the Neo4j database and receive the result.
Let's assume, there are 200 vehicles that match the search result. I then want to display only 20 of those results and provide a next/previous button.
When user is done seeing the first 20, he/she wants to see the next 20, that is when I have to re-run the same query that user submitted initially but, with SKIP value of 20 (SKIP value keeps incrementing 20 as user navigates to next page, and decrement 20 as your moves to previous page).
My question is, what is the best approach to save search request (or the cypher generated by original request) so that when user clicks next/previous page, I re-run the original search cypher query with different SKIP value? I don't want to make a fresh POST request every time the user goes to next/previous page. This problem can be resolved in the following manner but, not sure which is more performance-friendly?
Every time the user clicks next or previous page, I make a new POST request with preserved values of original request and rebuild the cypher query (POSTs can be costly - I want to avoid this, please suggest why this is better option)
I store the original cypher query in Redis and whenever the user clicks next or previous, I retrieve the query specific to that user (need to handle this either via cookie, session or some sort of hidden uuid) from Redis, supply the new value for SKIP and re-run it (somehow I have to handle when I should delete this entry from Redis - deletion should happen when user change his search or abandon the page/site).
I store the query in session (user does not have to be logged in) or some other temporary storage (than Redis) that provide fast access (not sure if that is safe and efficient)
I am sure somebody came across this issue and it in an efficient manner which is why I post the question here. Please advise how I can best resolve this problem.

As far as performance goes, the first thing that you should absolutely do is to use Cypher parameters. This is a way to separate your query string from your dynamic data. This has the advantage that you are guarded against injection attacks, but it also is more performance because if your query string doesn't change, Neo4j can cache a query plan for your query and use it over and over again. With parameters your first query would look like this:
MATCH
(v:VEHICLE),(v)-[:VGEARBOX_IS]->(:VGBOX{type: {vgearbox_type}}),
(v)-[:VCONDITION_IS]->(:VCONDITION{condition: {vcondition}})
WITH DISTINCT v
WHERE v.manufacture_year = {manufacture_year}
MATCH (v)-[r]->(info)
RETURN v AS vehicle, COLLECT({type:type(r), data:info}) AS details
SKIP ({page} - 1) * {per_page}
LIMIT {per_page}
Your javascript library for Neo4j should allow you to pass down a separate object. Here is what the object would look like represented in json:
{
"vgearbox_type": "MANUAL",
"vcondition": "USED",
"manufacture_year": 1990,
"page": 1,
"per_page": 20
}
I don't really see much of a problem with making a fresh query to the database from Node each time. You should benchmark how long it actually takes to see if it really is a problem.
If it is something that you want to address with caching, it depends on your server setup. If the Node app and the DB are on the same machine or very close to each other, probably it's not important. Otherwise you could use redis to cache based on a key which is a composite of the values that you are querying for. If you are thinking of caching on a per-user basis, you could even use the browser's local storage, but are users often re-visiting the same pages over and over? How static is your data and does the data vary from user to user?

Ajax Messaging system Questions

I'm working on a messaging system like Facebook. I do have on left a list of conversation, and on right a box where i load the messages, just like facebook does.
The basic system is complete (PHP/MySQL), and here some information on how it is structured:
messages.php - Main page, based on url parameters. Rewrited with.htaccess:
Examples:
URL = http://www.domain.com/messages/ - Right Box: Display form to send new message.
URL = http://www.domain.com/messages/Username - Ajax call to getUserMessages.php to load Messages between Logged in user and
Username and show them on the Right Box.
getUserMessages.php - Get from database messages between Logged in user and user selected. It does Output HTML ready to be displayed.
Now the system is partially Ajaxified, and i want it to be, just like Facebook does.
At the moment the Ajaxified part is:
When a user is vieweing a conversation, it display automatically new messages, and also update the conversation list with the last message.
If the user is not viewing a conversation, it does get new messages received and update the conversation list.
This is done with a PUSH service, to give Real Time experience to users.
I want to improve this, and make it to act like that:
The user click on the Conversation List, and it load the messages on the right Box, and also change the URL on the Address Bar, withut reload the entire page.
I can easily do the part to load messages when user click a conversation, but before i start i have two question:
1. How i do change the Address URL while displaying a User Conversation WITHOUT reload the page?
I found the answer.
2. How i do cache the conversations ? So if a user switch between two conversation, it does not call again the php file and query the database for all the messages, but appending only new messages (Maybe via another php File to fetch only Unread Messages)
EDIT
I comed up with a solution:
When a user open a conversation, i cache the entire Ajax response (that is HTML) in a variable, like messages-n, Where n is the user_id of the conversation selected, then if the user click again on that conversation, i check if messages-n is set, if it is, i print it and run an ajax request to get only unread message and append them.
That's only in my mind i didn't made it to actual code.
Could work well?

Solved 1/2 :
1. To change Address URL i'm using the HTML5 .pushState() event.
Since HTML5 Browsers implement the pushState method in different way, to have a Cross-Browser solution, and have support for HTML4 browsers with hash Fallback, i used Hystory.js.
2. To cache messages, i haven't found a solution yet, nor i tried to do it for now.
But as #Christopher suggested, i changed the Ajax response from HTML to Json.
If i find it i will update my answer.

Shall I use javascript for page submission?

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>