Skip Navigation

[Resolved] Did you change the $_POST Keys for the CRED Forms nonces?

This support ticket is created 2 years, 8 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 -
- 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 -

Supporter timezone: Europe/London (GMT+01:00)

This topic contains 5 replies, has 2 voices.

Last updated by Nigel 2 years, 8 months ago.

Assisted by: Nigel.

Author
Posts
#2138403

Under CRED 2.6.9 the $_POSTed data by a Post form held a key "_cred_cred_wpnonce_cred_form_5" (where 5 is the Form ID), holding the Form Nonce.

Now under CRED 2.6.10, that key changed to "_cred_cred_wpnonce_cred_form_5_1" where 5 is the Form ID and 1 (hopefully) the value of _cred_cred_prefix_form_count

It is a tad annoying having to discover over a "forms do not work anymore" and performing an hours long debug, after reading the changelog of CRED sand seeing nothing whatsoever mentioning this rather breaking change.

I had to fix several client websites where we listen to this nonce to apply our own security. And since the key now changed, each and every form on those sites just broke, in the sense that it couldn't be submitted anymore, since our security checks did not pass, of course, since listening to a now inexistent Key.

I would A) Appreciate such things in the changelog, and B), if it was broken before, that is actually a security issue. And thus should have been published IMO, and not just hidden behind a lot of other fixes.

Since things now already broke and I already fixed them, I need to know, if this was even intentional or if you will break it again in the next update.

Please also note that such a change is, indeed, a change. Not a bug fix (even if you fixed a bug with it).
And thus, the version number should be bumped to a 2.7 at least, or even a 3.x because it is in fact a breaking change. That is, if you follow modern versioning of course.
Breaking-change.Non-Breaking-Change.Non-Breaking-Bug-Fix.
That would tell anyone immediately that there will be changes to consider if doing the update.

Cheers.

#2138407

On anther sidenote, since that ticket is closed already:
https://toolset.com/forums/topic/datepicker-not-initialized-after-view-ajax-pagination/
I see now in the CRED Changelog this:
"Fixed the datepicker fields on forms rendered after an AJAX event, like after an AJAX form submission or inside a Views AJAX pagination."

So is that ticket there fixed now? Despite it being so unusual, and that ticket being dismissed, now the very use case is mentioned in a Changelog for a fix thereof? Even if it was dismissed as a "we prefer not to fix this" over a year ago?

#2140073

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+01:00)

Hi Beda

I can confirm the same, that the key in the $_POST object relating to the cred form none changed with the addition of a suffix that matches the count. So if the same form appears twice on the page, the second form submits with a different nonce key than the first.

I'm not sure of the reasoning, I couldn't see a reference to it in the internal tickets for Forms for the 2.6.10 release.

I understand that the change has inconvenienced you and I'm sorry for that, but the contents of the $_POST object are not part of the official Forms API and as such should be used with caution in the understanding that they may change for internal reasons.

Changes affecting the official API would certainly need to appear in the changelog, although changes to the APIs that broke backwards compatibility could expected to be very rare.

#2140105

Hi Nigel
Thanks…
Can you confirm with devs that this will stay as is and isn’t just by error?
I also noticed the nonce is missing completely when a logged out user uses the form…
I didn’t yet have to use logged out forms luckily in these projects but if they’ll ask to add nonce check (which is possible also for logged out users, it’s just slightly different due to how wp generates those nonces)

Any chance you could confirm the change is there to stay?
About logged out form nonce it’s not urgent Or anyhow topic of this ticket, I just noticed it during debugging this issue, never noticed it before. As said, im aware logged out users don’t have an id and thus a nonce is different, but WP actually covers that with a filter I think when generating the nonce.
Could be wrong about this one… would be nice to anticipate in case these projects where safety is written perhaps a tad too heavy come up with logged out submission forms (I don’t think so, but one never knows)

Thanks!

#2140349

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+01:00)

With vacations it will probably be early next week when I have an answer for you, I'll let you know when I've confirmed that.

#2144469

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+01:00)

Juan pointed out that any thing with a key beginning with underscore is private and part of the internal workings of the plugin and is not for public consumption, and that you can edit the form and add your own hidden fields for security etc., but, that being said: no, it is unlikely that the format of key with the nonce will change again for the forseeable future. It was updated to resolve issues with multiple forms on the same page.

I think you should be safe to continue using it with the newer format.

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.