In the PHP documentation for session_unset() there is no hint that this function is deprecated so I think it's fine to use it. But then I read through the documentation about session_destroy() where I found this hint:
Note:
Only use session_unset() for older deprecated code that does not use $_SESSION.
I know that the session_unset() function is an equivalent for $_SESSION = array();. So what should I use now? Why is on one site a hint that this function is deprecated but on the other hand in the documentation about the function itselfs there is not deprecated note. What's the truth about this function now?
I don't know the exact reason, too, but it can be found here I guess: https://github.com/php/php-src/blob/master/ext/session/session.c
PHP handles variables in ZVAL pointers and I think they just wanted the _SESSION superglobal to be handled the same way as any other variable, and not with a "special" command session_unset().
Another benefit is better garbage collection handling I think.
Sometimes, "deprecated" does not mean its a bad function, but you should not use it because code might be removed in future packages simply because it is not neccessary.
If you want to close the session you must use session_destroy().
session_destroy();
If you want to clear the variables of the session you must use:
$_SESSION = array();
And if you want to clear only one variable of the session you must use:
unset($_SESSION['example']);
Related
As far as I am concerned session_unset() has no hidden features. The behavior is identical to $_SESSION = [];. Why was this function added to PHP 4? Why has it not been deprecated yet if its use is not recommended and there is no benefit to using it? Does it affect the GC in some way?
PHP C code where the function is defined: https://github.com/php/php-src/blob/master/ext/session/session.c#L2519
It would matter to you if you were using a deprecated session variable, namely $HTTP_SESSION_VARS.
Version Description
4.1.0 Introduced $_SESSION that deprecated $HTTP_SESSION_VARS.
1
session_unset() is used to clear all of the Session info $HTTP_SESSION_VARS contains without destroying the Session itself. However,
(Note that $HTTP_SESSION_VARS and $_SESSION are different variables and that PHP handles them as such)
Hence why session_unset() is useless when using the $_SESSION superglobal instead. I can't say it's that surprising that the session_unset() function is not deprecated while $HTTP_SESSION_VARS is, although I couldn't tell you exactly why that is.
Is $row a predefined variable in php (or does it have some other built-in functionality)? I have several times seen it used without prior reference in the code, but haven't found any documentation or explanation about it yet.
This is just a convention, you can use any name you want, however is good to use something simple, clear that make sense...
No, there is no such a predefined variable, you've just seen a variable declaration/initialization.
I have something like:
if(isset($_POST['submit']))
{
$linktitle=strtolower(str_replace(" ","-",$title));
etc.
$linktitle and $title are actually variables from $_POST - ie $_POST['linktitle'] and $_POST['title'].
Somehow, even though (as far as I can see!) I haven't extract()ed $_POST at this stage in the code, it is still working - PHP is understanding that $title is referring to $_POST['title']. Could anyone please explain why this might be?
Thanks!
ps. Sorry, but I really can't get this inline code quote formatting thing to work...!
register_globals is enabled in your PHP instance. See here for more info.
This is behaviour that should be relied upon as it's use is now deprecated. You will find that you can still use $_POST['keyname'] as well as $keyname, and that is what you should refer to in your code.
Your php.ini file must have register_globals enabled, so GPC variables are being added to the symbol table. This is why you see this behaviour. See the security risks of such a feature here
You have register globals activated in your webserver (php.ini), so PHP replace the unknoe variables with the corresponding GET or POST value. This option is deprecated and dangerous! Disable it if you can!
I'm a little confused with the benefit of using filter_has_var($_POST['id']) over isset($_POST['id']).
Can Somebody please tell me if it's simply an alias function?
Not alot ;) According to the manual page for filter_has_var one user finds filter_has_var a little quicker. Also worth noting... filter_has_var isn't working on the live array ($_POST) but on the actual provided input... if you ever add/remove/update what's in that array you won't see those changes with a filter_has_var call (while isset will reflect the current state)
By the way the usage is filter_has_var(INPUT_POST,"id");
Update: Perhaps worth mentioning, filter_has_var was introduced in PHP 5.2.0 (somewhat new) while isset has been around for all of PHP4+5. Most servers keep up to date on this, but isset will always work (no one still runs PHP3 do they?)
First of all, it's not
filter_has_var($_POST['id'])
It's
filter_has_var(INPUT_POST, 'id')
Secondly, it doesn't actually query the $_POST superglobal. It analyzes the request parameter that came in with the request, so it's a better method to use in case $_POST gets dirtied in some way by the PHP script.
I think you mean filter_has_var(INPUT_POST, 'id') over isset($_POST['id']).
There is a small difference in that isset returns false if $_POST['id'] is NULL; you'd have to use key_exists('id', $_POST) to have similar behavior in that regard.
Besides that, the only difference is that filter_has_var doesn't consider modifications to the $_POST array (see this comment).
Function doesn't check live array
<?php
$_GET['a'] = 1;
echo filter_has_var(INPUT_GET, 'a') ? 'Exist' : 'Not exist';
will print Not exist
Ok I cannot remember the details on this but on some servers you can use
$var instead of $_GET['var'] to access a variable in the URL, I know this is BAD but I can't remember why it is bad?
I think you mean Register Globals.
You shouldn’t use them because you cannot distinguish the source of that variable values since they can come from any source of the EGPCS variables (Environment, GET, POST, Cookie, Server).
So if you have a the $var, you cannot say if the value is either from $_ENV['var'], $_GET['var'], $_POST['var'], $_COOKIE['var'] or $_SERVER['var'].
The feature is called Register Globals and it allows people to inject variables into your code. See the documentation for examples; here's one:
<?php
// define $authorized = true only if user is authenticated
if (authenticated_user()) {
$authorized = true;
}
// Because we didn't first initialize $authorized as false, this might be
// defined through register_globals, like from GET auth.php?authorized=1
// So, anyone can be seen as authenticated!
if ($authorized) {
include "/highly/sensitive/data.php";
}
?>
You can use that if your server has register_globals set to 1 (or true) on the php.ini file.
At some point, this started to be off by default, and applications started to break, which is a reason why this is a bad practice.
You can see a list of php.ini variables here.
It's also bad because you can confuse yourself with the way that PHP will scope your variables. You may wind up overwriting data if you aren't careful. Also, using $_GET is much clearer as to what you are attempting to accomplish.
Because letting people inject values into arbitrary variables is a very bad thing. You could be storing anything there and they could overwrite some value that compromises your security. Remember to use isset to check that a value has been set before trying to use it.
It's bad because if you're not careful to initialize every variable before you use it (something that PHP won't force you to do), people can easily cause your code to do Very Bad Things with a request as simple as /myapp/index.php?admin_privileges=1.
The setting is called REGISTER_GLOBALS and it was discussed here:
Why is REGISTER_GLOBALS so bad?
If you can do that, then "register_globals" is turned on. This is bad because you won't know where a variable came from, and it mixes your variables with the ones any user can inject via the URL. Read more here: http://www.php.net/manual/en/security.globals.php
Once you get used to using $_POST, $_GET, etc your code's purpose will be easier to read and much, much easier to maintain.
Register globals would work but it's going to go away in a future version of PHP. Not to mention that it really is wrong to have it enabled.
You can use extract() for a more controlled behavior. It will extract the keys from an array (in this case, $_GET) into the local context as variables. You can give them a common prefix so that they don't collide with your existing variables. And you can filter the array beforehand to make sure you're only getting the expected variables.
int extract( $var_array [, $type = EXTR_OVERWRITE [, $prefix ]] )
Import variables from an array into the current symbol table.