I have multiple pages, say:
wedding catering
party catering
house warming catering
ETC
All pages use the same form
When the form is submitted the user gets directed to thank you.php which does the processing mail the form etc.
MY QUESTION
I would like to find out which page the submitted form came from, is there any simple way to do this?
The simplest ways are:
use the referrer header ($_SERVER['HTTP_REFERER'], with the typo missing R) or
use a hidden form field that differs from one page to another.
Whichever you use, just check the value on the page that processes the submission and go from there.
As frz3993 suggested, using $_SERVER['HTTP_REFERER'] is one option; however, I'd use this more for finding out what other sites users came from. Since this is your own site and you have control over the form generation, I would definitely go with a hidden field or something similar rather than trusting the user's browser to tell you which page submitted the form.
Never trust the client! :)
You can use here a hidden field for all different pages with all different values to trace the page.
for example you can use field name "came_from"
1.wedding catering
<input type="hidden" name="came_from" value="wedding catering">
2. party catering
<input type="hidden" name="came_from" value="party catering">
so on.
Related
Is there a way to search on www.qantas.com.au or other sites that don't use GET method, from my own form?
I mean something like this : http://site.com/search.php?data=myData
I don't want to return result on my webpage, I just want to send data with a href
Depending on the website, many forms may contain CSRF tokens intended to prevent this behavior (imagine if a third party site could 'submit' a form for you to another site, perhaps to trans fer money or write embarassing posts)
That said, for sites that don't implement this feature, it should be possible just to copy their form (from <form> to </form>) including the action="/their/website/controller" and method="POST" (if you want it posted)
If you want to design your own form that submits the same data, just make sure the input fields have a name="blah" the same as the form data value that you want to submit
AJAX is also an option if you dont want to use a form. (see http://api.jquery.com/jQuery.post/)
I'm considering using random input names for registration form. It would be done this way:
User requests register form site.
Create random names for input fields and save them to user's session.
Render form and display it to the user.
I just wonder if that method gives me anything. If session driver is a cookie - it's
encrypted and secured in the best possible way using third party library which I consider as save enough. If user don't except cookies I can refuse registration.
To remove cookies as potential security risk I can store sessions in database. This seems more secure but also might overload the server(?).
My question is quite simple. Is there any sense to implement such feature?
The standard approach is to have a hidden text field. That is a field with type=text, but with CSS rules applied to it so that it's invisible.
markup:
<input type="text" name="put_some_innocuous_name_here" class="some_innocuous_css_class_name_here" value="" />
CSS:
input.some_innocuous_css_class_name_here {
display: none;
}
PHP:
if ((isset ($_POST ['put_some_innocuous_name_here']))
&& ($_POST ['put_some_innocuous_name_here'] != ''))
{
throw new Exception ('Suspected bot!');
}
The way this works is quite simple. A normal user will never see your hidden text field because CSS rules will keep it hidden. therefore a real user will never fill it out.
However, most spambots aren't aware of CSS. They just parse the form markup and they see a text field that appears to need filling out. So they fill the field out with some random data. Because a form field that should never be seen by a normal user has been filled out, this means you're probably dealing with a bot.
Don't use input type=hidden for this, because most spambots are smart enough to notice them and ignore them.
A little late but I have created an class file which does exactly what you need you can find it here.
You just need to pass the name of the form through a function example.
<input type="text" name="<?php echo $obj->DynamicName("fieldName")?>"/>
and once the form is submitted it will populate $_POST['fieldName'] with appropriate data as soon as you create its object.
Try checking the IP against known spammers lists, it's very effective. Good examples would be Botscout and Spambusted. I've tried both, and they reduced my spammer bot registrations.
Potentially silly question, but I'm looking for the most sensible mechanism by which to maintain and "resubmit" POST variables. Basically the workflow is as follows:
STEP 1) Select charges to pay, and enter payment info
STEP 2) Display confirmation/summary page with option to "PROCEED WITH PAYMENT" or "EDIT INFO"
STEP 3) Return to "edit" form or send data to be processed.
I'm currently using a single page for all actions (just one giant SWITCH based on an "action" var) and submitting the information. The problem I'm having is that between the "confirmation page" and either option, I'm losing my POST data (which I understand). What I need now is a way to preserve that data without duplicating the input fields in each SWITCH section. Below are a few options I've considered. Feel free to comment on the merits or stupidity of each:
1) serialize it to a SESSION var then unserialize it?
2) simply key/value it into a SESSION array?
3) recreate every INPUT for each "form" presented and refill the values
4) put the SWITCH inside a single form and only display relevant portions
5) I would handle it all with Javascript (sort of a faux submission technique), but there is currently processing that occurs between the initial form and the summary and ajaxifying that would be a beast atm.
What's the recommended course of action for the classic INPUT->CONFIRM->PROCESS process? It'd be amazing if I were just missing something über obvious/simple.
FYI: Currently using PHP 5.1.6
Best!
EDIT 1
Clearly using individual pages for the various functionality is desired. The only reason I'm not using separate pages is because other pages are dependent on this one page and management won't allow a clean break at this point in time. It was poorly constructed over 3 years ago and is just now being partially addressed.
At this point I'm using:
foreach($_POST as $key=>$value)
<input type="hidden">.......
...in order to achieve the desired goal.
serialize it to a SESSION var then unserialize it?
simply key/value it into a SESSION array?
Very bad. Clicking "Confirm" should always confirm what is being displayed on the page, not what happens to be in some nebulous session stored on some server somewhere (which may not be the same server that served the previous request if you have a load-balanced cluster).
There are plenty of websites out there which will try to detect when you press the back button and display an error page, probably for related reasons.
recreate every INPUT for each "form" presented and refill the values
You need to do this anyway for the "go back to editing" page.
What's hard about <input type="hidden" ... /> in a loop on the confirmation page?
put the SWITCH inside a single form and only display relevant portions
You mean stick all the inputs in display:none for the confirmation page? That feels ugly too.
Firstly, breaking it up into multiple pages might be a good solution but I don't know your specific needs.
1 and 2 are bad ideas. That being said, I don't know what you gain out of serializing and unserializing to a session variable that you don't get with simple key value pairs in the session. Session management gets pretty hairy if you are running multiple servers behind load balancers
4 Just sounds odd. I don't know what the switch gives you here. If you ever have to use conditional logic to display a completely different functionality to the user, it is probably better of being on a separate page.
5 Faux submission? Just sounds like a kludge. You mean send the data back to the server and return the same data back and display the confirmation div? Why not just use Javascript and manipulate the DOM at that point? Nevertheless bad idea.
Just repost the parameters to the confirmation form and populate the confirmation fields accordingly. (Standard process). I think that is what 3 is but I suggest you use a different page for each step. Just keeps things clean.
I actually ended up using
<?$forward_post_data = base64_encode(serialize($_POST));?>
<input type="hidden" value="<?=$forward_post_data?>"/>
...I then decode it as necessary. It works perfectly.
In HTML5, an input without name is also valid
e.g.
<input type="text" id="user" />
But what is the point if I cannot access the form element in my backend PHP code?
Not all input is used server-side. In many cases it's used for form submission via AJAX. Additionally, a JavaScript app can make use of user input without ever needing to use a form.
Click the "link" button on any question or answer here on Stack Overflow, you will see an example of an <input> without a name or associated form.
Granted, this particular input is created with javascript - but it's pretty common to see an input field or textarea for copy/paste purposes, for one example.
..and it's also useful for basically anything to do with javascript.
One non-AJAX example I am currently using:
I have a spreadsheet for several dollar amounts to be filled in. I use an <input> field with no name to display the total amount of each column with javascript. On the server side, I don't need a "total amount" field coming through, and I sure as hell wouldn't trust it. The real total amount is calculated on the server side based on the other inputs, but we still show it in real time on the front end for the user.
I'm setting up a contact form, but I have some saved information in some spans (It's an ecommerce shopping basket) and the built in checkout is awful so we're just slapping together an easy solution: turn it into an email form and email us the order instead of losing customers.
Anyway, can I use the info in the span, taking the id or name or do I have to turn it into an input? And if I do, how can I disable the input field?
Example of code I want to take into the email is in this jsFiddle, I want the spans with name="ACTUAL PRICE" etc emailed. Is this possible?
Thanks :)
Maybe you want to use a hidden input field.
<input type="hidden" name="key" value="foobar" />
It is not displayed, but can be used to submit information with the form.
You'd be far better off using hidden form fields if possible. Else if the user has JS disabled you may run in to issues down the line. Rare but possible.