Jump to content

Recommended Posts

What types of occasions would ctype_digit not validate a string(1) "0"?

 

My script is getting a posted variable from an outside source which is string(1) "0" and while it is set, it chooses not to validate.  The field names are correct, the $_POST is written correct.  There are no spelling mistakes or errors in the script, but I cannot get the ctype to validate using either ctype_digit or ctype_alnum.

 

When would a posted value not be resolved to TRUE using ctype_digit or ctype_alnum?

 

Edit: The last question revolves around the posted value being a string with the value of 0.

 

Edit 2: For argument's sake let's say I have the brand newest of new PHP Version, there is no errors in the script, and what I am posting is actually occurring.  I am checking that it isset and that ctype_digit === true, this works with everything else and still for some BS reason it won't validate this one posted variable.  Let's also say that the chances of you recreating it are likely 0, so even if I posted the actual code it wouldn't really help anyway.

Link to comment
https://forums.phpfreaks.com/topic/253021-possible-ctype_digit-issue/
Share on other sites

You are thinking I have an error in my code, because 99.9% of all errors are generated from a typo.  I've been over my code 100 times and I can assure you that there isn't any error.  The $_POST [ "this" ] is typed in right, verified by it actually spitting out the value in the else of the if.  The format of that section is the exact same, copy and paste, of another section which is directly above it and the one above it works.

 

I am using Notepad++ and all of the syntax highlighting is correct, php isn't spitting out any errors for parsing errors.  There is absolutely no mysql involved at this point so that is out of the question.

 

But if you want it, I've tried to recreate it using the exact same "copy and paste" changing the class / function out for ctype_digit itself, but I cannot recreate the problem.

 

<?php
	if ( isset ( $_POST [ "x_trans_id" ] ) && Functions :: Data_Validation ( $_POST [ "x_trans_id" ] , 3 ) === TRUE )
	{
		self :: $_CLEAN [ "TransactionID" ] = $_POST [ "x_trans_id" ] ;
	}
	else
	{
		if ( _ERROR_VERBROSE_ === 1 )
		{
			die ( "Purchase Process ( Line Number: " . __LINE__ . " ): Transaction ID is Invalid! -- {$_POST [ "x_trans_id" ]}!" ) ;
		}
		else
		{
			return FALSE ;
		}
	}
?>

 

Prove me wrong though I would love an end to finally come of this stupid error.

 

As an added bonus I will even give you the error it generated in the else!

 

Purchase Process ( Line Number: 121 ): Transaction ID is Invalid! -- 0!

 

See the 0?  I see it, it's so pretty sitting at the end of that error... but the Data_Validations function in the Functions class ( 3 ) is ctype_digit and it works everywhere else in the entire application, except for this one location.  Anything at this point towards a resolution would be awesome.

if ( _ERROR_VERBROSE_ === 1 )

 

it is typo here?  VERBROSE or VERBOSE?

 

Obviously if it is spitting out the error it is a typo that has seemed to have followed me from it's conception.  I tend to copy and paste a lot as to not deal with errors later on, but in this case the copying and pasting has saved me the typo from being a problem.  A simple fix, but still not a resolution to this problem.

Since

 

<?php

$string = '0';

var_dump( ctype_digit($string) );

?>

 

Outputs

 

bool(true)

 

I can only assume there's an issue with your code.

 

Same result from

 

<?php 

if( isset($_POST['input']) ) {

var_dump( $_POST['input'] ); echo '<br>';
var_dump( ctype_digit($_POST['input']) );

} else {
?>
<form action="" method="post">
<input type="text" name="input">
<input type="submit">
</form>
<?php 
}
?>

 

When '0' is submitted

 

string(1) "0"
<br>bool(true)

Since

 

<?php

$string = '0';

var_dump( ctype_digit($string) );

?>

 

Outputs

 

bool(true)

 

Let me point out something: Functions :: Data_Validation ( $_POST [ "x_trans_id" ] , 3 ) === TRUE

 

Functions :: Data_Validation is basically ctype_digit with error messaging to be displayed out in a Message display system.  It isn't intended for debugging, only to give an indication to the user what is wrong.  var_dump the ctype all you want it is suppose to spit out TRUE or FALSE, which is why that portion is coded into the script.  ctype_digit doesn't change the input you spit to it, just checks to see if it is a digit.  ctype_digit also expects the input to be a string, which I have type casted all input to ctype_digit to ( string ).  No that isn't a correct assumption, you are attempting to find a flaw with something I already have knowledge of and expect the outcome of ctype_digit to be a bool.

 

I can only assume there's an issue with your code.

 

No, unless there is an issue with the code I have provided then there isn't a problem with my code and may be an issue as I have mentioned in the Original Post.

 

Same result from

 

<?php 

if( isset($_POST['input']) ) {

var_dump( $_POST['input'] ); echo '<br>';
var_dump( ctype_digit($_POST['input']) );

} else {
?>
<form action="" method="post">
<input type="text" name="input">
<input type="submit">
</form>
<?php 
}
?>

 

When '0' is submitted

 

string(1) "0"
<br>bool(true)

 

Correct the $_POST [ "input" ] is always going to be a string because HTML Submitted Input will always be a string.  Also ctype_digit is a validation method to check to see whether or not the "string" being submitted to it is comprised of digits.  As per the PHP Manual, the result of ctype_digit will be True or False.  http://php.net/manual/en/function.ctype-digit.php, I have not implemented this function incorrectly.

 

What's the code for Functions::Data_Validation()?

 

I think I know what you're thinking, and if you're thinking what I'm thinking you're thinking, I'm thinking the same thing, I think  : )

Cast to boolean?

 

The code to Functions :: Data_Validation() has been working for the last 2 months across the entire application without any similar result.  It is not a concern and when used with anything else except for this one particular posted value, it works as it should.

 

Now since there isn't a easy fix that can be spotted in the code I posted, because it is the only portion of the entire application that isn't working as it should, could we start pointing out reasons as to why ctype_digit wouldn't validate ( result in TRUE ) a string(1) "0" that is posted from an outside source.

 

If we want, I am using an Authorize.net Test Account to set up an Authorize.net payment system.  The site posts to Authorize.net using the SIM ( Server Integration Method ) as it should to the Authorize.net Payment Form, I fill out a bunch of information and hit submit.  The transaction is successful, but because I have it set on Test Mode the x_trans_id sends back 0.  It sends back 0 because there is no Transaction actually taking place, and I had considered that maybe somehow the $_POST [ "x_trans_id" ] was submitting back a different type besides a string.

 

In the DIE, notice the error message I posted the 0 is actually displayed, I did a var_dump of the $_POST [ "x_trans_id" ] and it echo'd out string(1) "0".  I've tried ctype_digit and ctype_alnum and both of them both resulted in the else ( the die ).  The Functions :: Data_Validation ( $input , 3 ) validates a ton of shit across the entire application that is completely functional after a very thorough Alpha Test, so I know for a damn fact it isn't that function.

 

I know when dealing with problems a ton of the time there is a solution that is very easily spotted.  I've taken the Functions :: Data_Validation ( ) out and replaced it directly with ctype_digit and it still resulted in the same result.  Any other suggestions?

 

I do appreciate everyone's help, but a little less thinking I am brand new at this would be very much appreciated.  As I said I have gone over this several times, I cannot recreate it and it only occurs with x_trans_id, which from the DIE in the ELSE it still spits out the value of x_trans_id so I do know that it is in fact set.

Sorry for my hostility, but the Data_Validation function was coded months ago and has yet been a problem anywhere I have utilized it.  Since no one has been able to find an error with the code I posted let's try this again.

 

I just ran another test and split the isset and the Data_Validation and received:

 

x_trans_id isset and equals 0
Purchase Process ( Line Number: 129 ): Transaction ID is not a Digit! -- 0!

 

So it is definitely the ctype_digit which is failing.

 

Yes I am absolutely 100% sure it isn't the function that I set up that is failing.  The Input going to it is not being validated as a digit, even though 0 is suppose to be validated as a digit.  Yes the $_POST [ "x_trans_id" ] is type cast to ( string ) even though it comes already assembled as a string before going through ctype_digit ( ).

 

I am going to test something else and then I will be absolutely certain that "0" isn't being validated as a string.

 

We're trying to tell you, there's no scenario where ctype_digit would return false for (string) '0'.

 

It's not validating because the variable either isn't a string, or it contains non-digit characters.

 

POST data should always parse into the string datatype.

 

Known bugs:

https://bugs.php.net/bug.php?id=29226

https://bugs.php.net/bug.php?id=60103

https://bugs.php.net/bug.php?id=34645

https://bugs.php.net/bug.php?id=30378

 

All involve passing an INT to the function, or old versions of PHP4 returning different results on empty strings.

 

Have you copy-pasted my code to your server? Does it work? If it's working, then there's an issue somewhere in your script.

 

Since your script contains functions we don't have access to, we can't test it.

 

 

Don't suppose

Functions::Data_Validation

runs anything along these lines?

 

 

private static function Data_Validation($in)
{
   // check some shit
   if ( empty($in) || !ctype_digit($in) )
      return 'Transaction ID is not a digit.';
}

 

 

:confused:

Don't suppose

Functions::Data_Validation

runs anything along these lines?

 

 

private static function Data_Validation($in)
{
   // check some shit
   if ( empty($in) || !ctype_digit($in) )
      return 'Transaction ID is not a digit.';
}

 

 

:confused:

 

No I do not have an empty in it because anything that would be empty would resolve to be false in the ctype_digit anyway.  The function primarily works like

 

<?php
if ( ctype_digit ( ( string ) $input ) )
{
   return TRUE ;
}
else
{
   return FALSE ;
}
?>

 

The only difference is before the True or False it puts a message into the session to spit out to the user.  I do know that empty will find 0, even if it was a string, to be empty, but I require 0 for other portions of the application so it was not something I implemented into the Data_Validator.

 

We're trying to tell you, there's no scenario where ctype_digit would return false for (string) '0'.

 

It's not validating because the variable either isn't a string, or it contains non-digit characters.

 

POST data should always parse into the string datatype.

 

Known bugs:

https://bugs.php.net/bug.php?id=29226

https://bugs.php.net/bug.php?id=60103

https://bugs.php.net/bug.php?id=34645

https://bugs.php.net/bug.php?id=30378

 

All involve passing an INT to the function, or old versions of PHP4 returning different results on empty strings.

 

Have you copy-pasted my code to your server? Does it work? If it's working, then there's an issue somewhere in your script.

 

Since your script contains functions we don't have access to, we can't test it.

 

 

 

I am running PHP 5, I do not know the exact version but I did however find those bugs on my initial search.  https://bugs.php.net/bug.php?id=34645 specifically is what I thought was happening, but the value is still echoed out afterwards.

 

I was really hoping I was just dyslexic with the $_POST [ "x_trans_id" ] and posted something like $_POST [ "x_trnas_id" ], which would make me feel better.  This thing has been agitating me all day long and I am quite fed up with it.  I think I am going to take a nap and come back at this tomorrow.  Thank you all for your help and I apologize for getting agitated.

What is the code block that works, right above the offending code, that you copied/modified to get the block of code that does not work, because seeing some code that works (I assume that means you tested it with a '0' value?), might indicate why the posted code does not work.

 

Also, the offending code is inside of a class, seeing the working block of code vs the non-working might show something specific to oh let's say super-global variables, or perhaps specifically names super-global variables, that would give us some information to use to suggest things to find the problem.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • 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.