Nonce happy?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Nonce happy?

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.

--
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
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Nonce happy?

abdussamad
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


On 08/12/2013 08:01 PM, Thomas Belknap wrote:

> 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.
>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Nonce happy?

Stephen Harris
In reply to this post by Thomas Belknap

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.

> 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.
>

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Nonce happy?

Kenneth Newman
In reply to this post by Thomas Belknap

On Aug 12, 2013, at 11:01 AM, Thomas Belknap <[hidden email]> wrote:

> 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.

>
> 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).

>
> 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.

>
> 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.

>
> --
> 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
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Nonce happy?

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.


On Mon, Aug 12, 2013 at 1:47 PM, Kenneth Newman <[hidden email]>wrote:

>
> On Aug 12, 2013, at 11:01 AM, Thomas Belknap <[hidden email]>
> wrote:
>
> > 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.
>
> >
> > 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).
>
> >
> > 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.
>
> >
> > 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.
>
> >
> > --
> > 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
> > _______________________________________________
> > wp-hackers mailing list
> > [hidden email]
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
>
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> 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
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Nonce happy?

Jaime Martínez
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


On 12 aug. 2013, at 20:50, Thomas Belknap <[hidden email]> wrote:

> 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.
>
>
> On Mon, Aug 12, 2013 at 1:47 PM, Kenneth Newman <[hidden email]>wrote:
>
>>
>> On Aug 12, 2013, at 11:01 AM, Thomas Belknap <[hidden email]>
>> wrote:
>>
>>> 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.
>>
>>>
>>> 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).
>>
>>>
>>> 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.
>>
>>>
>>> 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.
>>
>>>
>>> --
>>> 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
>>> _______________________________________________
>>> wp-hackers mailing list
>>> [hidden email]
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>> _______________________________________________
>> wp-hackers mailing list
>> [hidden email]
>> 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
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers