| # |
Apr 12th 2021, 20:58 |
 kevin.pfeifer |
thats why you get a ID to tell PHP which data you already have |
| # |
Apr 12th 2021, 20:58 |
kevin.pfeifer |
aren’t sessions the PHP native way to actually save data between requests? HTTP per se is stateless. |
| # |
Apr 12th 2021, 20:54 |
greg138 |
I only have about 120 more important things than that to do right now... ;) |
| # |
Apr 12th 2021, 20:54 |
greg138 |
I'm going to have to dig into this more at some point. Isn't the session ID regenerated on basically every page load now? If the session ID is included in the form tamper protection somehow, that would seem to mean you couldn't load a form in one tab, visit a different page, then come back to the form, but that works fine. |
| # |
Apr 12th 2021, 20:52 |
kevin.pfeifer |
https://book.cakephp.org/4/en/controllers/components/security.html#disabling-form-tampering-for-specific-actions |
| # |
Apr 12th 2021, 20:52 |
kevin.pfeifer |
you can do that with this line |
| # |
Apr 12th 2021, 20:51 |
kevin.pfeifer |
if your OK with having a form thats dedicated to not have these security features enabled then sure, that can be configured |
| # |
Apr 12th 2021, 20:50 |
greg138 |
If you have a form you don't want *any* security on, I think that's easily configured. |
| # |
Apr 12th 2021, 20:50 |
kevin.pfeifer |
how you cirtumvent that with an AJAX call, i have no idea |
| # |
Apr 12th 2021, 20:48 |
kevin.pfeifer |
so if the hash of the forms in the “old” form (mixed up with the current session) don’t match up with the sent form then you get that error |
| # |
Apr 12th 2021, 20:47 |
kevin.pfeifer |
https://github.com/cakephp/cakephp/blob/master/src/Controller/Component/SecurityComponent.php#L295 |
| # |
Apr 12th 2021, 20:47 |
kevin.pfeifer |
in this function it uses sessions |
| # |
Apr 12th 2021, 20:47 |
kevin.pfeifer |
https://github.com/cakephp/cakephp/blob/master/src/Controller/Component/SecurityComponent.php#L230 |
| # |
Apr 12th 2021, 20:47 |
kevin.pfeifer |
_validatePost uses the method _hashParts |
| # |
Apr 12th 2021, 20:46 |
kevin.pfeifer |
well i think i know whats the problem |
| # |
Apr 12th 2021, 20:45 |
khalil |
I’ll check and if i figure it out i’ll let you guys know |
| # |
Apr 12th 2021, 20:45 |
khalil |
Perfect thanks Kevin! |
| # |
Apr 12th 2021, 20:44 |
kevin.pfeifer |
https://github.com/cakephp/cakephp/blob/master/src/Controller/Component/SecurityComponent.php#L242 |
| # |
Apr 12th 2021, 20:44 |
kevin.pfeifer |
if you get a AuthSecurityException its this line |
| # |
Apr 12th 2021, 20:43 |
kevin.pfeifer |
if your get a BadRequestException its this line https://github.com/cakephp/cakephp/blob/master/src/Controller/Component/SecurityComponent.php#L188 |
| # |
Apr 12th 2021, 20:43 |
khalil |
Next challenge is to make it happen haha |
| # |
Apr 12th 2021, 20:43 |
khalil |
I’m setting up a local dev with a debugger |
| # |
Apr 12th 2021, 20:08 |
kevin.pfeifer |
there are only a few places where that error is being triggered. If you got a local setup and/or xdebug you could pretty easily track down what causes that error |
| # |
Apr 12th 2021, 20:05 |
greg138 |
I can't find specifics of what I'm talking about now, so I'm wondering whether I've got it wrong and that's not an explicit thing but rather a side effect of CSRF or session timeout? If you have an integrated debugger, it should be pretty easy to step through the security component's form checking to find what, specifically, is triggering the issue for you. |
| # |
Apr 12th 2021, 19:52 |
khalil |
And Kevin my form doesn’t fall under any of these criteria’s |
| # |
Apr 12th 2021, 19:51 |
khalil |
Blackhole is annoying :$ |
| # |
Apr 12th 2021, 19:51 |
khalil |
I need to read more if we can extend the time |
| # |
Apr 12th 2021, 19:50 |
khalil |
The timeout thing i mean |
| # |
Apr 12th 2021, 19:50 |
khalil |
I think what you’re saying makes sense, but it’s really annoying |
| # |
Apr 12th 2021, 19:50 |
khalil |
Thanks for the feedback guys! |
| # |
Apr 12th 2021, 17:05 |
greg138 |
I need to spend some time wrapping my head around what forms it might be okay to skip that check, and where it's not, to replace the unfriendly black-hole message with something about a timeout and maybe regenerate the form with the data preserved. |
| # |
Apr 12th 2021, 17:03 |
greg138 |
I haven't come to a good conclusion on how best to handle that situation yet myself. :( |
| # |
Apr 12th 2021, 17:03 |
greg138 |
If I could witness your profile edit form, I could re-send it but with my own password or email address. |
| # |
Apr 12th 2021, 17:03 |
kevin.pfeifer |
"betterr" => easier |
| # |
Apr 12th 2021, 17:03 |
kevin.pfeifer |
so basicall it would be better to just show a notice after X minutes to just refresh instead of trying to fix the onscreen form :) |
| # |
Apr 12th 2021, 17:02 |
kevin.pfeifer |
ah ok |
| # |
Apr 12th 2021, 17:02 |
greg138 |
i.e. re-using the token, etc. to make the form appear legitimate to the rest of the form security. |
| # |
Apr 12th 2021, 17:01 |
greg138 |
It's not a super robust replay prevention scheme. It just assumes that any form submitted more than X minutes after it was generated is probably not from a real user, but someone replaying form contents they somehow captured earlier (but with different values to benefit themselves). |
| # |
Apr 12th 2021, 17:00 |
kevin.pfeifer |
well how does it check if its a replay attack then :thinking_face: |
| # |
Apr 12th 2021, 16:52 |
greg138 |
There's also a timeout in there, to avoid replay attacks. Not sure where that's covered in the docs. |
| # |
Apr 12th 2021, 16:49 |
kevin.pfeifer |
seems like your form falls into one of these conditions • Unknown fields cannot be added to the form. • Fields cannot be removed from the form. • Values in hidden inputs cannot be modified. https://book.cakephp.org/4/en/controllers/components/security.html#form-tampering-prevention |