Discussion:
Nonce happy?
Thomas Belknap
2013-08-12 15:01:41 UTC
Permalink
Reading over a lot of documentation and example code concerning the
addition of custom fields to the Write Post screen, almost every single one
includes the requirement to include a nonce field with your data. An
abundance of caution isn't necessarily a bad thing, but does this not
strike anyone as a little too much caution?

In terms of what WordPress is using nonces for, the only goal is to make
sure the data is coming from the correct origin: your website and your
admin form. Once this task is out of the way, the rest of the POST data
should be trusted. Yet the convention, at least in terms of example code,
seems to be to include a nonce for every single custom field.

If WP is making it's own checks on the "Write Post" screen data, don't the
additional nonces seem superfluous, or am I missing something?

I perfectly understand their value in the context of a custom plugin
configuration page. But when extending the Write Post screen to incorporate
all the additional data a custom post type might require, this additional
nonce data seems like a bit of a headache with very little value.
--
Tom Belknap
Owner/Editor, DragonFlyEye.Net
Join me:

- *Inbox:* http://dragonflyeye.net/subscribe
- *Web*: http://dragonflyeye.net/
- *Facebook*: https://www.facebook.com/DragonFlyEye.Net
- *Twitter*: https://twitter.com/dragonflyeye
- *Google*: https://plus.google.com/u/1/103251482414903117843/posts
Abdussamad Abdurrazzaq
2013-08-12 15:15:06 UTC
Permalink
It is not a problem if you stick all this functionality in a base class
that you then extend for each of your meta options:

base:
http://plugins.svn.wordpress.org/comment-form-message/trunk/includes/abstract.class.abd_meta_option.inc.php

text box:
http://plugins.svn.wordpress.org/comment-form-message/trunk/includes/class.abd_text_meta_option.inc.php
Post by Thomas Belknap
Reading over a lot of documentation and example code concerning the
addition of custom fields to the Write Post screen, almost every single one
includes the requirement to include a nonce field with your data. An
abundance of caution isn't necessarily a bad thing, but does this not
strike anyone as a little too much caution?
In terms of what WordPress is using nonces for, the only goal is to make
sure the data is coming from the correct origin: your website and your
admin form. Once this task is out of the way, the rest of the POST data
should be trusted. Yet the convention, at least in terms of example code,
seems to be to include a nonce for every single custom field.
If WP is making it's own checks on the "Write Post" screen data, don't the
additional nonces seem superfluous, or am I missing something?
I perfectly understand their value in the context of a custom plugin
configuration page. But when extending the Write Post screen to incorporate
all the additional data a custom post type might require, this additional
nonce data seems like a bit of a headache with very little value.
Stephen Harris
2013-08-12 15:24:23 UTC
Permalink
Usually when handling custom metaboxes you can't be sure of $_POST even
when WordPress has checked nonces - since typically the callback is run
on 'save_post' which is a general hook not specific to the user clicking
'publish'. There might not even been any data from your metabox. Since
any plug-in can directly/indirectly trigger 'save_post' with or without
any appropriate nonce checks its best to err on the side.

With regards to adding a nonce for each field - that is overkill, but
you should add a nonce for each metabox. Because metaboxes can be
removed, you cannot assume that any particular metabox will be present
with which to check its nonce.
Post by Thomas Belknap
Reading over a lot of documentation and example code concerning the
addition of custom fields to the Write Post screen, almost every single one
includes the requirement to include a nonce field with your data. An
abundance of caution isn't necessarily a bad thing, but does this not
strike anyone as a little too much caution?
In terms of what WordPress is using nonces for, the only goal is to make
sure the data is coming from the correct origin: your website and your
admin form. Once this task is out of the way, the rest of the POST data
should be trusted. Yet the convention, at least in terms of example code,
seems to be to include a nonce for every single custom field.
If WP is making it's own checks on the "Write Post" screen data, don't the
additional nonces seem superfluous, or am I missing something?
I perfectly understand their value in the context of a custom plugin
configuration page. But when extending the Write Post screen to incorporate
all the additional data a custom post type might require, this additional
nonce data seems like a bit of a headache with very little value.
Kenneth Newman
2013-08-12 17:47:54 UTC
Permalink
Post by Thomas Belknap
Reading over a lot of documentation and example code concerning the
addition of custom fields to the Write Post screen, almost every single one
includes the requirement to include a nonce field with your data. An
abundance of caution isn't necessarily a bad thing, but does this not
strike anyone as a little too much caution?
Nah, it turns out that using a wpnonce to identify your fields is easier then the alternatives, so for me, it's less about caution and more about pragmatism.
Post by Thomas Belknap
In terms of what WordPress is using nonces for, the only goal is to make
sure the data is coming from the correct origin: your website and your
admin form. Once this task is out of the way, the rest of the POST data
should be trusted. Yet the convention, at least in terms of example code,
seems to be to include a nonce for every single custom field.
wpnonces are (supposed) to be tied to a unique action string-key. Every action deserves it's own wpnonce.
If a user uses the bulk edit feature on the post list screen, then for each post edited, the wpnonce for bulkedit will pass, and yet your fields aren't present and your handle shouldn't run.
Further, there's no guarantee that 'save_posts' (which is where your action is hooked) was even triggered by an edit form submission (upgrades and unistalls update posts sometimes) and there's no guarantee that a related nonce check was performed at all (unless you do it yourself).
Post by Thomas Belknap
If WP is making it's own checks on the "Write Post" screen data, don't the
additional nonces seem superfluous, or am I missing something?
This wpnonce is tied to an action that does not necessarily cover your fields' purpose.
Your nonce is supposed to indicate an action such as 'user_wants_to_update_my_metafields_for_book_cpts' (overlong because it's contrived).
It's a way of assuring you are only taking action when the user intends for that action to occur.
Post by Thomas Belknap
I perfectly understand their value in the context of a custom plugin
configuration page. But when extending the Write Post screen to incorporate
all the additional data a custom post type might require, this additional
nonce data seems like a bit of a headache with very little value.
I find that using a unique nonce actually has quite a bit of utility, and it's only two lines of code: a line printing the nonce with your fields, and a line checking it's value.

The most evident utility is that if my unique nonce is valid, my fields should at least be present. User actions involving the posting form on the dashboard, the bulk edit form, pressthis, among others, won't contain my fields, since I add them via metabox calls typically. Checking the nonce saves me the hassle of detecting the screen type and inspecting the $_POST object and detecting my fields.

You should always use a unique string that describes the custom action you are handling, and specify a unique field name for the nonce (otherwise someone's _wpnonce is going to get trampled).

I think of this system as effectively having multiple forms that are transmitted via the same html form. If I use my own unique nonces, I don't have to worry about what any other actions are doing.
Post by Thomas Belknap
--
Tom Belknap
Owner/Editor, DragonFlyEye.Net
- *Inbox:* http://dragonflyeye.net/subscribe
- *Web*: http://dragonflyeye.net/
- *Facebook*: https://www.facebook.com/DragonFlyEye.Net
- *Twitter*: https://twitter.com/dragonflyeye
- *Google*: https://plus.google.com/u/1/103251482414903117843/posts
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Thomas Belknap
2013-08-12 18:50:28 UTC
Permalink
Thank you all for your helpful and thoughtful responses. Kenneth, what you
say makes a lot of sense. I'm trying to create a more or less generic form
field generator for use across other plugins that I use all the time, just
because I'm so spoiled on the way CakePHP creates forms, and the nonce
thing was an open question.

You've all given me a lot to think about. Thank you.
Post by Kenneth Newman
Post by Thomas Belknap
Reading over a lot of documentation and example code concerning the
addition of custom fields to the Write Post screen, almost every single
one
Post by Thomas Belknap
includes the requirement to include a nonce field with your data. An
abundance of caution isn't necessarily a bad thing, but does this not
strike anyone as a little too much caution?
Nah, it turns out that using a wpnonce to identify your fields is easier
then the alternatives, so for me, it's less about caution and more about
pragmatism.
Post by Thomas Belknap
In terms of what WordPress is using nonces for, the only goal is to make
sure the data is coming from the correct origin: your website and your
admin form. Once this task is out of the way, the rest of the POST data
should be trusted. Yet the convention, at least in terms of example code,
seems to be to include a nonce for every single custom field.
wpnonces are (supposed) to be tied to a unique action string-key. Every
action deserves it's own wpnonce.
If a user uses the bulk edit feature on the post list screen, then for
each post edited, the wpnonce for bulkedit will pass, and yet your fields
aren't present and your handle shouldn't run.
Further, there's no guarantee that 'save_posts' (which is where your
action is hooked) was even triggered by an edit form submission (upgrades
and unistalls update posts sometimes) and there's no guarantee that a
related nonce check was performed at all (unless you do it yourself).
Post by Thomas Belknap
If WP is making it's own checks on the "Write Post" screen data, don't
the
Post by Thomas Belknap
additional nonces seem superfluous, or am I missing something?
This wpnonce is tied to an action that does not necessarily cover your fields' purpose.
Your nonce is supposed to indicate an action such as
'user_wants_to_update_my_metafields_for_book_cpts' (overlong because it's
contrived).
It's a way of assuring you are only taking action when the user intends
for that action to occur.
Post by Thomas Belknap
I perfectly understand their value in the context of a custom plugin
configuration page. But when extending the Write Post screen to
incorporate
Post by Thomas Belknap
all the additional data a custom post type might require, this additional
nonce data seems like a bit of a headache with very little value.
I find that using a unique nonce actually has quite a bit of utility, and
it's only two lines of code: a line printing the nonce with your fields,
and a line checking it's value.
The most evident utility is that if my unique nonce is valid, my fields
should at least be present. User actions involving the posting form on the
dashboard, the bulk edit form, pressthis, among others, won't contain my
fields, since I add them via metabox calls typically. Checking the nonce
saves me the hassle of detecting the screen type and inspecting the $_POST
object and detecting my fields.
You should always use a unique string that describes the custom action you
are handling, and specify a unique field name for the nonce (otherwise
someone's _wpnonce is going to get trampled).
I think of this system as effectively having multiple forms that are
transmitted via the same html form. If I use my own unique nonces, I don't
have to worry about what any other actions are doing.
Post by Thomas Belknap
--
Tom Belknap
Owner/Editor, DragonFlyEye.Net
- *Inbox:* http://dragonflyeye.net/subscribe
- *Web*: http://dragonflyeye.net/
- *Facebook*: https://www.facebook.com/DragonFlyEye.Net
- *Twitter*: https://twitter.com/dragonflyeye
- *Google*: https://plus.google.com/u/1/103251482414903117843/posts
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
--
Tom Belknap
Owner/Editor, DragonFlyEye.Net
Join me:

- *Inbox:* http://dragonflyeye.net/subscribe
- *Web*: http://dragonflyeye.net/
- *Facebook*: https://www.facebook.com/DragonFlyEye.Net
- *Twitter*: https://twitter.com/dragonflyeye
- *Google*: https://plus.google.com/u/1/103251482414903117843/posts
Jaime Martínez
2013-08-12 21:23:41 UTC
Permalink
I know writing it youself is fun, still If you are looking for a generic way of creating back-end forms, maybe you could check scb-framework and the scbForm part.
https://github.com/scribu/wp-scb-framework
http://scribu.net/wordpress/scb-framework/

Good luck and have fun

Jaime
Post by Thomas Belknap
Thank you all for your helpful and thoughtful responses. Kenneth, what you
say makes a lot of sense. I'm trying to create a more or less generic form
field generator for use across other plugins that I use all the time, just
because I'm so spoiled on the way CakePHP creates forms, and the nonce
thing was an open question.
You've all given me a lot to think about. Thank you.
Post by Kenneth Newman
Post by Thomas Belknap
Reading over a lot of documentation and example code concerning the
addition of custom fields to the Write Post screen, almost every single
one
Post by Thomas Belknap
includes the requirement to include a nonce field with your data. An
abundance of caution isn't necessarily a bad thing, but does this not
strike anyone as a little too much caution?
Nah, it turns out that using a wpnonce to identify your fields is easier
then the alternatives, so for me, it's less about caution and more about
pragmatism.
Post by Thomas Belknap
In terms of what WordPress is using nonces for, the only goal is to make
sure the data is coming from the correct origin: your website and your
admin form. Once this task is out of the way, the rest of the POST data
should be trusted. Yet the convention, at least in terms of example code,
seems to be to include a nonce for every single custom field.
wpnonces are (supposed) to be tied to a unique action string-key. Every
action deserves it's own wpnonce.
If a user uses the bulk edit feature on the post list screen, then for
each post edited, the wpnonce for bulkedit will pass, and yet your fields
aren't present and your handle shouldn't run.
Further, there's no guarantee that 'save_posts' (which is where your
action is hooked) was even triggered by an edit form submission (upgrades
and unistalls update posts sometimes) and there's no guarantee that a
related nonce check was performed at all (unless you do it yourself).
Post by Thomas Belknap
If WP is making it's own checks on the "Write Post" screen data, don't
the
Post by Thomas Belknap
additional nonces seem superfluous, or am I missing something?
This wpnonce is tied to an action that does not necessarily cover your fields' purpose.
Your nonce is supposed to indicate an action such as
'user_wants_to_update_my_metafields_for_book_cpts' (overlong because it's
contrived).
It's a way of assuring you are only taking action when the user intends
for that action to occur.
Post by Thomas Belknap
I perfectly understand their value in the context of a custom plugin
configuration page. But when extending the Write Post screen to
incorporate
Post by Thomas Belknap
all the additional data a custom post type might require, this additional
nonce data seems like a bit of a headache with very little value.
I find that using a unique nonce actually has quite a bit of utility, and
it's only two lines of code: a line printing the nonce with your fields,
and a line checking it's value.
The most evident utility is that if my unique nonce is valid, my fields
should at least be present. User actions involving the posting form on the
dashboard, the bulk edit form, pressthis, among others, won't contain my
fields, since I add them via metabox calls typically. Checking the nonce
saves me the hassle of detecting the screen type and inspecting the $_POST
object and detecting my fields.
You should always use a unique string that describes the custom action you
are handling, and specify a unique field name for the nonce (otherwise
someone's _wpnonce is going to get trampled).
I think of this system as effectively having multiple forms that are
transmitted via the same html form. If I use my own unique nonces, I don't
have to worry about what any other actions are doing.
Post by Thomas Belknap
--
Tom Belknap
Owner/Editor, DragonFlyEye.Net
- *Inbox:* http://dragonflyeye.net/subscribe
- *Web*: http://dragonflyeye.net/
- *Facebook*: https://www.facebook.com/DragonFlyEye.Net
- *Twitter*: https://twitter.com/dragonflyeye
- *Google*: https://plus.google.com/u/1/103251482414903117843/posts
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
--
Tom Belknap
Owner/Editor, DragonFlyEye.Net
- *Inbox:* http://dragonflyeye.net/subscribe
- *Web*: http://dragonflyeye.net/
- *Facebook*: https://www.facebook.com/DragonFlyEye.Net
- *Twitter*: https://twitter.com/dragonflyeye
- *Google*: https://plus.google.com/u/1/103251482414903117843/posts
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Loading...