Php documentation

[davej]

Looking at... (maybe my griping here was a bit excessive)... http://www.php.net/manual/en/function.bin2hex.php ...with confused content provided by confused users...this is wikification?

Edited January 7, 2014 by davej

[Ingolme]

I don't believe there's much more to say about the function than what they have there.

[davej]

In fewer words they could have said: "Returns hex representation of string. Example: "0123Aa" returns "303132334161"

[davej]

I'm currently re-learning Php and getting into more of the details so I apologize for the dumb questions. Here is another documentation situation. All I want to know is whether $_POST[] will ever return anything but a string? This...http://www.php.net/manual/en/reserved.variables.post.php...does not tell me.Next do I need to sanitize or length-limit it or check with is_numeric() or anything before attempting intval() ? This...http://us3.php.net/manual/en/function.intval.php ...does not tell me.

Edited January 7, 2014 by davej

[justsomeguy]

Data submitted as post data (or get data, for that matter) does not include a data type. When you send data to the server, you don't tell it that it is an integer, or a boolean, or a string, you just send a name and a value. So, all data is treated as a string. That doesn't mean that $_POST is always an array of string name/value pairs, though. It's possible to format a request such that PHP will create arrays inside $_POST or $_GET. So, in general without any modification, $_POST and $_GET will be an associative multi-dimensional array of strings. The vast majority of the time they are not multi-dimensional though.

 

Next do I need to sanitize or length-limit it or check with is_numeric() or anything before attempting intval() ?

You don't *need* to do anything, if you're fine with the documented behavior that intval will return 0 if the value cannot be cast to an integer (with the exception of objects and arrays, which follow the same rules for casting to boolean). If you want your data to follow other rules, then validate it however you want before converting it. Since you can't distinguish a successful versus a failed cast to 0, you might want to do some other validation first depending on what data you're working with. In other cases, if 0 is not a valid value for your data anyway then there's no reason to check before converting.

[davej]

If I destroy the session variables then why would I care about destroying the session cookie?http://www.php.net/manual/en/function.session-destroy.php

[justsomeguy]

I'm not sure what you're asking. If you want to remove the session cookie prematurely for whatever reason then you can do that with setcookie. I haven't had a reason to do that.

[davej]

I am confused almost every time I look something up and the Php doc says just the bare minimum definition and then all the user comments try to explain what it means and how it should be used. In the case of session_destroy() the users are keen to explain that a proper log-out must also include statements to kill the session cookie. My question is: why? Why would I care if the session cookie continues to exist? It points to a blank session and will eventually timeout and die.

[justsomeguy]

Yeah, you're right. Removing the session cookie would only guard against the case where a new session happens to get created with the same ID.

[davej]

They indeed warn here to destroy the cookie...https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet#Invalidate_Session_IDWhere it says... "You should invalidate (unset cookie, unset session storage, remove traces) of a session..."But I don't know why.

Edited January 13, 2014 by davej

[justsomeguy]

They're just saying to consider a certain session ID invalid if a security violation occurs with that session, and one way to invalidate the session ID would be to unset the cookie. That would be an additional step to take for PHP, for PHP you would want to remove all of the session data and maybe even set a value to indicate that there was a violation.