Jump to content

ahphpnz

New Members
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

0 Neutral

About ahphpnz

  • Rank
    Newbie
  1. Hey all, trying to figure out a logic flaw in this validation script. Basically if I use !preg_match or the preg_match examples (noted below), I do not get the correct results. My interpretation of preg_match and my current understanding of the logic is noted below (please correct me if I'm wrong). 1. If I use alternate attempt !preg_match, the regex would be compared against the "string" in the $email variable. If the regex expression matches, error will be thrown and script would stop. 2. If I use alternate attempt !preg_match, the condition would be not true and move to else where the string contained within $email variable would be run through the vld function. 3. If I maintain the current script using preg_match, if the string matches the match, the condition would be true and therefore string of $email variable runs through VLD function else cleanup and throw error... Are my statements above correct in this context? I think I'm pretty close to cracking it but seem to be missing something simple. The current script is referenced below, forgive me if I've lost the plot. Long hours attempting to understand this language, from what I've seen so far its great. Thanks in advance, A //Alternate attempt if (!preg_match("/^[^@]+@[^@.]+\.[^@]*\w\w/", $email)) { $error = "Please enter a valid email address"; } else { $email = vld($_POST['email']); } Current code that doens't work: if (empty($_POST['email'])) { $error = "Email is required"; } else { if (strlen($_POST['email']) < 5) { $error = "Email is too short!"; } else { if (strlen($_POST['email']) > 30) { $error = "Email is too long!"; } else { if (preg_match("/[\(\)\<\>\,\;\:\\\"\[\]]/", $email)) { $error = "The email address contains illegal characters"; } else { if (preg_match("/^[^@]+@[^@.]+\.[^@]*\w\w/", $email)) { $email = vld($_POST['email']); } else { $error = "Please enter a valid email address"; } } } } } }
  2. Kicken, you raise a very valid point. I'll drop the code back in on the develoment server within the container with the google captcha code enabled and see if I see the same result. Likewise I'll also disable it after the fact and post the results. This might come in handy for others if they stumble across it. Completely missed that! Will post back here to validate that this was the beahaviour that was experienced.
  3. So I have eliminated the code as being the issue by moving the code on to the Production host outside of the LXC container. The processing issue is either server side or on the interconnect between the Host and the container. This forum isn't the best place to tackle the root cause of the issue, at least PHP/Inefficient coding has been ruled out. I'll mark this as either a OS or Networking fault on the server side and rule out PHP as root cause. Works a charm outside of the container.
  4. I'm not convinced, why would standard HTTP GET requests be instant yet a POST with content is rediculously delayed. Seems like there is some major processing delay on the client side before it sends the POST out on the wire. TCP connections to all other services internal and external are fine, its just this development web service that has the issue and it only occurs when sending a POST with content. A POST with no form data (other than blank fields) arrive instantly on the server so that appears to be a client side issue. I've tried from multiple clients and its the same issue. I've never seen an issue like this, it's not making a lot of sense. Surely this couldn't be a network issue if everything else is functioning as expected with no latency/delay?
  5. Hi All, I'm hoping somebody would be able to help me with a performance issue I'm having with a bit of code I've written. The setup: Client request arrives on Apache2 reverse proxy over HTTPS. SSL is offloaded and proxy initiates connection to backend development web server over standard HTTP. The website is being developed using HTML5 syled with CSS, Javascript (to dynamically show counters on message text area, perform client side validation for browsers that do not support the build in HTML5 input validation) and PHP for server side validation and form submission (sends email to webadmin). The development web server is located in a LXC container on the production web server. The host server presents the "public" IP address to the physical network and uses UFW to NAT all traffic inbound and outbound from the development website to trick the network into thinking that the server is on the physical network (Only way to get it routeable across the rest of the network). The problem: On form submission, if I intentionally leave the fields blank and turn off client side validation, the script echos "An error occured in your form, please check to make sure that all relevent fields are filled in!!!". This response returns in 16.50ms with a latency of 34.92ms. The POST appears instantly in the Apache2 logs less than a second after I submit the form. If I submit the form with all fields (Name, Email, Phone, Website, Subject and Message), it takes 60 - 65 seconds before Apache logs the POST has arrived. I'm not entirely sure why its taking this long for the server to receive the content. GET Requests are pretty much instant as I would expect. Could this be an issue with inefficient scripting that maye be causing this type of delay? This issue occurs regardless of whether I use firefox or Safari. Could this be a result of inefficient scripting? Using timelines in Safari and on form submission with content, I get 1.0min latency with an actual duration/script run time of 5.336ms. Where would this latency be coming from? Standard GET requests for HTML and CSS content is instant, next to no latency but once the Payload increases in size, it seems like I run into the issue. Any views, thoughts or possible things to try would be hugely appreciated. I'm learning the ropes with scriping at the moment but this high latency, as a hunch, appears to be server related. Happy to upload the submit.php script and web form if it will help. Many Thanks, A
  6. Hi Jacques, that is indeed the problem. The Saffari browsers do not support HTML5 so the validation on the server side needs to happen. From a HTML5 perspective, the client side validation is working fine, its Saffari, Apple and Android devices that dont support the HTML5 validation. So I figured I would look in to a work around fix by applying the server side validation. Is there a way to pass a set variable back to the web page in the web response and append to an element ID or name so that its dynamically displayed on the same web page? similar to what you would do with the document.getElementId('element ID').innerHTML method in javascript? Just trying to keep away from multiple languages if its possible to avoid.
  7. Hi All, I'm very new to PHP and have been reading forums for the better half of two days trying to get ot the bottom of an issue I'm having with Contact form validation. Problem: When submitting the form data, the information stored in a variable is not outputted to the webpage. What I think I'm expecting: On form submission, the HTML5 elements should be checked to see if they are empty. If they are empty, the "string" that I'm storing in the *Err variables should then be outputted on the page to advise the use that the field has not been filled in. Things I've tried: I've confirmed that Apache server is configured to allow HTML pages to be parsed as PHP and have verified that it's working by confirming that PHP scripts do run in the page, PHP includes within the HTML documents apply and that when I use <?php echo "Blah";?> on the page, it outputs correctly. When using a statement such as <?php echo $blah;?> or <?php echo "$blah";?> or <?php echo "{$blah}";?>, the content of the variable is not displayed to the user submitting the form. What am I doing wrong here? I'm trying to do this with just CSS, HTML5 and PHP - I've read about jquery and javascript but preference is to stay with the three above unless what I'm trying to do is not possible. Any pointers/assistance would be hugely appreciated - I mustn't be understanding something correctly. Cheers, A PHP Script: (P.S... I've intentionally left the mail component out until I get the form validating correctly). <?php htmlspecialchars($_SERVER["PHP_SELF"]); if ($_SERVER["REQUEST_METHOD"] == "POST") { if (empty($_POST["name"])) { $nameErr = "Name is required"; echo $nameErr; } else { $name = test_input($_POST["name"]); } if (empty($_POST["email"])) { $emailErr = "Email is required"; } else { $email = test_input($_POST["email"]); } if (empty($_POST["website"])) { $website = ""; } else { $website = test_input($_POST["website"]); } if (empty($_POST["phone"])) { $website = ""; } else { $website = test_input($_POST["phone"]); } if (empty($_POST["message"])) { $comment = ""; } else { $comment = test_input($_POST["message"]); } } function test_input($data) { $data = trim($data); $data = stripslashes($data); $data = htmlspecialchars($data); return $data; } ?> Markup: <form class="form-style-9" method="post" enctype="multipart/form-data"> <ul> <li>Contact Form</li> <li> <input type="text" name="name" required class="field-style field-split align-left" placeholder="Name"><span class="error">*<?php echo $nameErr;?></span> <input type="email" name="email" required class="field-style field-split align-right" placeholder="Email"> </li> <li> <input type="tel" name="phone" required class="field-style field-split align-left" placeholder="Phone"> <input type="url" name="website" class="field-style field-split align-right" placeholder="Website"> </li> <li> <input type="text" maxlength="20" min="5" name="subject" required class="field-style field-full align-none" placeholder="Subject"> </li> <li> <textarea name="message" maxlength="200" required class="field-style" placeholder="Message"></textarea> </li> <li> <input id="submit" name="submit" type="submit" value="Send Message"> </li> </ul> </form>
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.