[theme-reviewers] Theme submission fails on WARNING

[Darren Slatten]

@Otto,

WordPress writes data to theme files via the Appearance => Editor admin
panel, without requiring FTP credentials. It only requires that the file
being edited has '666' permissions, which I assume the user has to configure
manually. The Editor panel will prompt a user to enable write permissions,
and in many cases, the user will neglect to reset the file's permissions
after they're done editing it. I'm curious to know how this scenario is
different from the one you've explained. In other words, it seems to me that
themes are being rejected for vulnerabilities that are already present in WP
core. Can you please clarify this and/or explain how these scenarios are
different?

Thanks.
-Darren



On Fri, Jun 24, 2011 at 4:57 PM, Otto <otto at ottodestruct.com> wrote:

> On Fri, Jun 24, 2011 at 4:44 PM, Philip M. Hofer (Frumph)
> <philip at frumph.net> wrote:
> > I got around fopen by using file() instead and imploding it (thanks otto
> and
> > pross for the idea)
>
> That only helps for reading files, not for writing them.
>
> And while I didn't go into it in my WP_Filesystem tutorial, there is a
> slightly alternative way to not have to display that form. It's not
> the safest of things, but it's reasonable if you want to present the
> user with as little difficulties as possible.
>
> http://ottopress.com/2011/tutorial-using-the-wp_filesystem/
>
> If you read the tutorial, you can see where it is doing
> request_filesystem_credentials() call. If you delve into that
> function, you can see that it does its tests and such, but what it's
> really looking for here when it can't do direct calls and is forced to
> fall back to the FTP methods is  $_POST['hostname'],
> $_POST['username'], and $_POST['password'].
>
> So if you don't want your user to see the separate FTP settings screen
> every time, then you can do something like this.
>
> // first, ignore this if we can write files with the "direct" method,
> which needs no credentials
> if ('direct' != get_filesystem_method(array(), false) ) {
>  // display hostname, username, and password inputs on my form..
>  // as long as they use those names and the form is a POST form,
>  // the subsequent call to request_filesystem_credentials will use
>  // them and not display an extra form to the user
> }
>
> That lets you sort of nicely integrate the credentials form into your own
> pages.
>
> If you wanted, you could even ask the user once, then store them in
> the database, and put them back onto the form in hidden inputs. I do
> not recommend this for security reasons, but it would work. The
> problem is that you have to store the credentials, including the
> password, in the database for this approach.
>
> You still have to detect the case when the given credentials are
> wrong, so the $form_fields option should be filled in properly and the
> if ( ! WP_Filesystem($creds) ) check still needs to be made, and the
> error in credentials case handled properly by displaying your form
> again to the user, but this method solves some theme devs objections
> to using the WP_Filesystem.
>
> -Otto
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20110624/a330e3bc/attachment.htm>