It took me forever to figure out that if you set the config to auto check the csrf token then if you MANUALLY check it it will fail because its already been checked.
My question is this, is there a way to perform some sort of logic to stop or redirect a script if the autocheck fails.
For example manually you'd do something like
if(!Security::check_token()){
//bad token halt script or forward
}
The only thing I can think of is to alter the security class. Any ideas?
I also check manually in my forms controller, and I don't see any difference in behaviour whether or not I've set 'csrf_autoload' in the config. false or true, the code works.
As for the autoload, I think this needs to be reviewed, as the check is a bit pointless because it doesn't do anything, and there is no way to retrieve the result of the check either.
I'm against auto-failing because you can't control it and always end up in the default error template.
Autoload CSRF is to have the CSRF key generated even when it's not used in PHP, it's not pointless and I'm actively using it.
I was merely wondering why the check in _init, as the result of the check is never used. I didn't mean I was in favour of auto-failing (which is magic, and we don't want magic).
I don't seem to notice any difference in application behaviour, whether or not the autoload is activated. Looks like fetch_token() does a fine job in generating a token if needed, even without the autoload?
@wanwizard in terms of autochecking, whenever a value is checked a new token is generated correct? Therefore if autoload is set to true then check_token will run. But if later on in the script you have a manual check it will fail because a new token has been generated? That's how I understood it atleast. Regardless I think i'll just go back to manually checking and turning autoload off.
I like the idea that if a check fails then you are redirected to a static page or whatever that can be defined in the config.
Apprearently not, because in my app it doesn't make any difference whether I autoload or not.
I use fetch_token() in my forms, and check_token() in my controller, and that works as advertised. I can remember having similar issues in the beginning, but I can't remember what caused them.
I agree with Jelmer that the Security class should not play a part in application logic. Your controller should check if a form is posted, if so validate the forum (including the csrf check), and act upon the result.
Besides that, that only works if you want your application to behave that way. In my case, I (miss-)use the token also to check for double submission (which would submit an invalid token), and reload the form with a message saying the form data has expired. So every form has a different redirect. Which I can't define, because the Security class is loaded way before my application loading has a change to define something...
As I said: autoloading makes sure the token is generated even when it's not yet been requested by PHP. Which I need because many forms may be loaded by AJAX calls and take their token from the cookie, which wouldn't exist yet if CSRF isn't autoloaded. It uses check_token(), which you should be able to use as many times as you want (like fetch_token()) without fearing it won't work a second time. Neither the old, nor the new token will change during a HTTP request (the first is read once and cached in the class, the second is generated once and cached within the class as well).
Donate
