Code: Select all
$pkid = (int)$_GET['pkid'];Whereas if I didn't cast it might be possible for an attacker to re-construct the path by passing something like:templates/somredir/layouts/$pkid/index.tpl
index.php?pkid=../../../some/secretpath/
Moderator: General Moderators
Code: Select all
$pkid = (int)$_GET['pkid'];Whereas if I didn't cast it might be possible for an attacker to re-construct the path by passing something like:templates/somredir/layouts/$pkid/index.tpl
index.php?pkid=../../../some/secretpath/
This is a common approach, however I disagree with it. The reason I disagree with it is because rather than verifying that the data is what was expected, you force it to be something you expect. This can only lead to unexpected behaviour or unusual bugs. I would definitely discourage this practice.PCSpectra wrote:Why bother doing explicit checks, when you can just cast the variable upon initialization and ensure it's 'type' and safety.
Code: Select all
$pkid = (int)$_GET['pkid'];
Sorry, but that's bull. It's not about "creating a contract" (again with this inappropriate jargon) it's about restricting future development and possible uses. I'm betting the 'reasons' listed for using type-hinting have never, ever been an issue before type-hinting was introduced, but tick a "that could be nice" box instead.jgadrow wrote:It's about coding a contract that client code must adhere to.
Yes, you can cast at initialization. However, I frequently write code that must (at some later date) be used by OTHER programmers down the line. I need to make sure that they don't silently break the system by trying to send some funky variable that the function (or method as is usually the case) never expected. Since I never know exactly WHO is calling the code, I can't exactly trust them to always have their data correct. This is why I validate the data I receive in the function.
Now, by allowing type-hinting for objects and arrays, they've basically allowed me the same ability as 'casting' a variable upon initialization. I can ensure that the information I receive will either be proper, or will throw an error that will need to be handled by the client code. However, since they only allow it for arrays and objects, I'm still left manually verifying the other variable types.
Casting is only one or several stages of sanitizing/security checks that I exeucte, I still:This is a common approach, however I disagree with it. The reason I disagree with it is because rather than verifying that the data is what was expected, you force it to be something you expect.
Code: Select all
1. Filter
2. Validate
3. Escape
Prior to the availability of type-hinting, I had to manually verify ALL incoming function data. I started using PHP after first being grounded in a 'typed' language. I don't know how simply validating the type of your incoming data is 'restricting future development' it can always be changed, if necessary, in the next version. However, simply running your code without bothering to know what data was sent to your function is a VERY good way to introduce logic errors.Jenk wrote:Sorry, but that's bull. It's not about "creating a contract" (again with this inappropriate jargon) it's about restricting future development and possible uses. I'm betting the 'reasons' listed for using type-hinting have never, ever been an issue before type-hinting was introduced, but tick a "that could be nice" box instead.
No. You might think it does, but type verifying every incoming parameter is nothing but paranoia. I'm yet to see any proof for it being problematic to not have type restrictions. The difference between it breaking because of no interface, compared to not answering to a method is nil. Your tests will capture any misaligned behaviour. You've also provided the perfect point to my argument. You are using them because you have only ever used them. You've never even tried not using them, so you have no basis for an argument.jgadrow wrote:Prior to the availability of type-hinting, I had to manually verify ALL incoming function data. I started using PHP after first being grounded in a 'typed' language. I don't know how simply validating the type of your incoming data is 'restricting future development' it can always be changed, if necessary, in the next version. However, simply running your code without bothering to know what data was sent to your function is a VERY good way to introduce logic errors.Jenk wrote:Sorry, but that's bull. It's not about "creating a contract" (again with this inappropriate jargon) it's about restricting future development and possible uses. I'm betting the 'reasons' listed for using type-hinting have never, ever been an issue before type-hinting was introduced, but tick a "that could be nice" box instead.
Whilst at the same time saying "Hey, I'm going to break if you are not implementing this arbitrary interface, even if you actually do answer to my demands."Type hinting allows the definition of an interface that can say right in the function argument list, "Hey! If you send me something other than an A object instance you're going to break me!"
That's is quite frankly a laughable comparison.Do you also leave your SQL statements un-validated and un-escaped because you're preventing the user from a 'possible use' of, say, outputting or deleting all of your database table? There MUST be limitations or you introduce possible system ABUSES.
Let's say we have a method of a class which takes an integer parameter. If you throw an exception due to a non-integer parameter, then another developer will actually become notified and will realize that he supplied an improper value. In case of type casting, everything would happen silently and that might cause unexpectable bugs.PCSpectra wrote:Why bother doing explicit checks, when you can just cast the variable upon initialization and ensure it's 'type' and safety.
But that developers tests will highlight incorrect behaviour, so there really is no need for any form of hint/cast/checkkaisellgren wrote:Let's say we have a method of a class which takes an integer parameter. If you throw an exception due to a non-integer parameter, then another developer will actually become notified and will realize that he supplied an improper value. In case of type casting, everything would happen silently and that might cause unexpectable bugs.PCSpectra wrote:Why bother doing explicit checks, when you can just cast the variable upon initialization and ensure it's 'type' and safety.
I know. The point is, maybe that applies to you, but no all developers test well and most developers I have seen test for bugs manually by using the software which will miss a load of unexpected things. The reason why I wouldn't using Public properties for non-public properties is not just the fact that it makes sense but also the fact that leaving it public assumes the developer will catch all bugs. I want to avoid that. I want to avoid bugs at all costs. Both software bugs and real life ones drive me nuts.Jenk wrote:But that developers tests will highlight incorrect behaviour, so there really is no need for any form of hint/cast/check
the true root of a problem is not typing of any sort. it's when we do/pass the wrong thing. it seems everything after that to try and prevent errors (and there's a lot, including fixing errors you'll make doing it) had better be worth it.When I came to the realization what had happened (like all errors) I sit down and try and discover the true root of the problem and employ practices which prevent that from ever happening again (if I wasn't so diligent in testing that error may not have been discovered for quite some time).