One submit button to processed two forms

[f1rew4ll]

Hello Everyone
My question is quite simple but more difficult to convert into the PHP and HTML code.
The idea is to upload a file to the server and email data from the form using one submit button.
The HTML Body looks like this:

 <form  "upload.php" method = "post" enctype = "multipart/form-data">
 <input type="file" name="file">
 <input type="submit" name="submit" value="Submit">
</form>

and PHP like this:

if(isset($_FILES['file']) OR ($_POST['email']))
{
   code for upload a file......
   code for email data......
  
   if(empty($errors)==true)
      {        
        move_uploaded_file($file_tmp,"/path/".$file_name);
 <input type="email" id="email" name="email">
        mail($recipient, $subject, $email_content, $email_headers);
        echo "File uploaded";
      }
}

So, How to now trigger to different issets, when one handle a ‘file’ that works only with $_FILES and another ‘email’ that works only with $_POST ?

[Martyr2]

I am not sure what you mean. When you submit the form that contains an upload, both the $_FILES and the $_POST arrays are populated at the same time. It is not one or the other. You can upload the file, accessing $_FILES to do that, and then when it comes to emailing the data, you access $_POST.

Just make sure that you have an input field called “email” in the upload form. If the email is fixed and you don’t want to show it even adding it as a hidden field will work…

<form action="upload.php" method = “post” enctype = “multipart/form-data”>
<input type="hidden" name="email" value="test@test.com"> <!-- Hidden email field -->
<input type=“file” name=“file”>
<input type=“submit” name=“submit” value=“Submit”>
</form>

So to your question, both $_FILES and $_POST are populated with the one button click. $_FILES is not at all tied to the method being “post”.

Edit: Also you can test to see if $_FILES is set, then inside that if, test if $_POST['email"] isset.

[f1rew4ll]

Hey. You are right!
(isset($_POST[‘email’])) works for upload files too as same as (isset($FILE[‘file’])) but (isset($_POST[‘file’])) doesn’t.
At least can use a _POST now so hopefully I will be at home shortly.

Thanks man

[droopsnoot]

A lot of people will recommend that you check for a form submission using

if ($_SERVER['REQUEST_METHOD'] == "POST") {

rather than looking for specific form variables being set. I forget why, it’s almost as much of a reflex response as suggesting that people don’t use the mail() function, and don’t concatenate variables into SQL queries.

[Martyr2]

I think sitepoint’s editor was stripping off the dollar signs. It should always be $_POST and not _POST. Same with FILES

[Martyr2]

I think I dug into that recommendation a year or two ago and found that the reasoning behind was more a preference than a security thing. As long as you understand how isset() works and make sure you sanitize all input, whichever way you want to do it is fine. I wouldn’t say one is a slam dunk over the other.

Even if you do use the REQUEST_METHOD trick, you still have to check that individual post field to see if it is set.

[benanamen]

@Martyr2

Even if you do use the REQUEST_METHOD trick, you still have to check that individual post field to see if it is set.

I would have to disagree with calling it a “trick”. It is just THE (thee) way to do it.

Additionally, checking that a field is isset is incorrect. On a properly coded form, all fields, save for checkboxes, will ALWAYS be isset, therefore checking for isset is pointless.

What you need to do is trim the POST array and then check for empty.

[f1rew4ll]

Thanks Gents
The final solution for me was to split two forms and cheat a little bit. A user need to click button “attach” to send a file to my server without (echo) information about what he/she did, then fill a contact form(name, email, message) and click “submit”. On the end I’ve got a file on the server and received an email with data.

[SamA74]

@benanamen

all fields, save for checkboxes, will ALWAYS be isset , therefore checking for isset is pointless.

A bit off-topic but…
That is actually why I routinely check isset on all inputs as part of my validation. If anything is not set, that should be set, it is a sign that something is amiss, and processing is halted. Reporting shows sometimes the bots do trip that wire. Just another invisible captcha for the armoury.

[benanamen]

The empty check still takes care if it.

A variable is considered empty if it does not exist or if its value equals false.
https://www.php.net/manual/en/function.empty.php

[SamA74]

I’ll give you that, I took empty as it literally implies, value set to an empty string.
Though in the context I’m using isset, I’ll word it as “captcha” instead of validation, empty isn’t suitable.
I would treat an empty (which I would use in validation) differently to a !isset.
Eg, an empty (literally an empty string) may result in a friendly “Please fill in all required fields”.
Where an !isset may result in a less friendly “Be gone foul robot, tampering with my form”, or at least an action to that effect.

[benanamen]

I get what you are saying. When it comes to a malicious submission does it really matter what message the “bot” gets? The important thing is that the submission does not succeed.

And what of the case of a bot not missing any of the fields? We are still back to isset doing nothing whatsoever even though it is a bot submission. All we have done is clutter the code base.

When it comes to a malicious submission, the concern should be that unexpected fields are provided. Simple solution to that is a white list of expected fields which I would highly recommend implementing. It is at this place where I would put the “be gone foul entity” message since a field not white listed is clearly a fraudulent/invalid submission.

This would be my recommended flow:

<?php
if ($_SERVER['REQUEST_METHOD'] == "POST") {
    CSRFCheck();
    whiteListCheck();
    trimPostArray();
    requiredFieldsCheck();
//Process Form
}

[SamA74]

Rambling a bit off topic here, but it looks solved, so…

@benanamen

The important thing is that the submission does not succeed.

Yes, I don’t actually message the bots like that, there isn’t much point to it, it’s bot.
Anything wrong that indicates bot, it stops dead and reports the problem to me, which is interesting to see which wires they trip on.

@benanamen

And what of the case of a bot not missing any of the fields? We are still back to isset doing nothing whatsoever even though it is a bot submission. All we have done is clutter the code base.

You could say the same for any form of captcha that a bot passes. When it does not work, it is redundant code, but when it does, it serves a purpose. I use it as just one part of a multi level strategy to catch form-bots, without inconveniencing real users, and for some it works. So with multiple tests, a bot may pass one, but maybe not the next. If you throw enough different obstacles in its path, you will stop it.

In the context of your reply to the OP, I 100% agree about the use of isset there. I was merely mentioning my own use case for isset on form fields.

@benanamen

Simple solution to that is a white list of expected fields which I would highly recommend implementing.

That is exactly what I do. In my latest forms, I have a form table in the database and an input table, then form and input classes that take care of all the messy business of building the form, then validating, sanitising, etc, using the list of known inputs for a particular form, so any additional inputs that may appear are ignored, and those that should be there are checked to be present and correct.
Any anomaly that indicates a bot, does not pass validation.
Admittedly my form processing can be a bit elaborate, some may call it clutter, but the way I see it, when you make a form, you open a window in your code, into which anyone can throw anything. So you better make sure what it the other side of the window can cope with anything that is thrown at it, and if anything that comes in smells bad, the window gets closed immediately. I don’t skimp on security with forms.
For some time this has been working well, with a 100% record of no spam and no hacks.