preg_match error

[gish]

I am using preg_match to protect my scripts.

I have two questions,

One Is this going to protect the server?

Two As it enters the script it sees that the username and password are empty. but I need them to be empty. So how do I get preg_match to let empty strings through.

 

<?phps
include("inc/security.inc");
//object security this test to see if the login script is has any scripting issues
$script_protector = new security($_POST['username'] , $_POST['password']);
$script_protector ->preg_match_0to9($_POST['username'] , $_POST['password']);
//security needs to return a 1 to enable the next function
if ($script_protector->security_checked() == 1){
include("inc/login.inc");
} else {
//needs to return to last figures
$_SESSION['information']['error']= 2;
include("inc/error.inc");
}
?>

 

<?php
class security
{
private $username;
private $password;
private $past_string;	
// this method(function) is setup for numbers only 0 to 9 and a maxium of 40 numbers	
  public function preg_match_0to9 ($username , $password){
		if (( preg_match('/^[A-Za-z0-9]+$/',$username) ) or (preg_match('/^[A-Za-z0-9]+$/',$password)) ){ 
		//this is make sure the string is not to long
				strlen($username); strlen($password); 
				if (($username >= 40) or ($password >= 40) ){
					$this->past_string = 0;
					//the security test is incorrect
					} else { 
					$this->past_string = 1;
					//the security test is correct
					}
		} else { 
		$this->past_string = 0;
		//the security test is incorrect
		}			
}
// this is function is a return value for the method (function) called   
   public function security_checked() {
            return $this->past_string;        
   }
}
?>

[uniflare]

Why would you need post values to be empty? if your checking the values then its because they want to login?

 

<?php

if(!isset($_POST['login'])){
  // display form
}else{
  // Check Input Data
}

?>

[gish]

thanks

The to answer your question is the  file include("inc/login.inc");has three headers to chose from. The problem is that when I run the script it gets sent to include("inc/error.inc"); automatically. I need preg_match to recognizes  empty strings so that I can stop the error.

 

how do I do that? I googled and can't find anything?

[redarrow]

<?php

//using empty command.

$name="";

if(empty($name)){

echo "\$name is empty";
}

?>

 

<?php

$names="";

if(!preg_match("/[a-z0-9]/i",$names)){

echo"\$names is empty";
}else{
echo "$names";
}

?>

[.josh]

chage the + to * in your patterns. + is 1 or more characters. * is 0 or more.

 

Alternatively, if you want to further remove those extra strlen conditions afterward, just make your patterns 

 

'/^[A-Za-z0-9]{0,40}$/'

[uniflare]

also note, ^ is an apache assert symbol, for cross platform development use \A instead.

[.josh]

umm, are you sure about that?  preg_xx functions are part of php.  I don't think the regex engine makes system or platform calls in order to do its job... it should do the same thing regardless of what system php is running on.

[uniflare]

Trust me, have a look on Perl Regex Syntax on the php.net website, look for the Assert and its respective partner \A.

 

You will see what i mean.

 

PS; i believe PERL is from the specific installation of the webserver installed. Therefor whichever version of PERL the system has will use that regex, i believe. Someone help me out on this on 1? lol.

 

http://uk3.php.net/manual/en/regexp.reference.php - look 

 

^

    assert start of subject (or line, in multiline mode)

 

\A

    start of subject (independent of multiline mode)

-------

 

The reason i said this is i've noticed before when people's regex dit work with ^, the \A anchor seemed to fix their problem lol. I think it is more how multiline mode is affected.

[.josh]

Even if perl has that restriction (which I don't know that it does, but I'm not an expert in perl), the preg_xx engine is pcre compatible, not pcre dependent.  It is a separate engine that is modeled after the pcre engine, compiled in c and part of php's internal core. I looked around in the manual and sorry, I'm just not seeing any evidence to support your claims.

 

so...as they say in the gaming world: screenshot or it didn't happen!  In other words, you're going to have to pony up some links about that.

[.josh]

I posted after your edit, so to respond to your edit:

 

Right.  There was never a bug or compatibility issue.  ^ just behaves differently, depending on what modifier(s) you use.  I suppose you could possibly argue that they should have made ^ stay the same no matter what, and have \A be the 'start of line' in multi-line mode.  At face value, that does seem more consistent; I have no idea why it's not done like that.  But I think it's stretching it to say it's some kind of bug that was fixed (or more accurately, bandaided).