[wp-hackers] JavaScript related functionality failure on some admin pages. 3.5.1

Tue Feb 26 22:55:39 UTC 2013

You are absolutely right Otto.

I tried loading the "load-scripts.php" ( by getting its full 404
URL straight from the Chrome's JavaScript's console with all the
querystring attached to it  ) and pasting it into my browser to see what
would happen...

And I ended up with a

HTTP Error 404.15 - Not Found

which fires when *The request filtering module is configured to deny a
request where the query string is too long. *
*
*
I remember that we had configured the querystring allowed max length on our
IIS server quiet some time ago. So whenever the querystring is too long,
the attacker simply gets a 404.

Your insight was right that it was our server where the solution lied.

However, I'm curious to see if there are ways for WP to find alternative
solutions to keep the QS as short as possible, I know this is quite tricky
but maybe all the wp must have ( required by the core ) scripts may be
dropped from that open list.

In case, you guys are wondering what I'm talking about, here is that QS
that's fed into the load_scripts.php

c=1
&load%5B%5D=admin-bar,hoverIntent,common,thickbox,schedule,wp-ajax-response,autosave,jquery-color,wp-lists,quicktags,jquery-query,admin-comm
&load%5B%5D=ents,suggest,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,postbox,post,underscore,shortcode,backbone,media
&load%5B%5D=-models,wp-plupload,media-views,media-editor,word-count,editor,jquery-ui-resizable,jquery-ui-draggable,jquery-ui-button,jquery-u
&load%5B%5D=i-position,jquery-ui-dialog,wpdialogs,wplink,wpdialogs-popup,wp-fullscreen,media-upload&ver=3.5.1

532 chars.

Do you guys plan to shorten this somehow in the future?

I also notice that there is another area where the querystring goes wild,
and that is when you want to apply a bulk action on comments on the admin
panel by selecting all comments and pressing one of the FILTERS such as
"show all comment type". This action results me a URL with 1388 chars after
the "?" which is another no go for me.

I guess as we rely more and more on the querystring, some people will be
running into issues due to their server configurations.

Maybe the comments URL ( the edit-comments.php file ) can be fixed to work
with a POST method as opposed to the GET method but, the other one, the
load_scripts.php is a more difficult one to deal with.

Thank you all.

On Tue, Feb 26, 2013 at 1:49 PM, Otto <otto at ottodestruct.com> wrote:
>
> The base problem here is that you're getting the 404 error on the
> load-scripts.php URL. Using the options you're describing "fix" the
> problem because you're not using that load-scripts URL anymore.
>
> So the question you need to focus on is why you're getting that 404 in
> the first place. Does the file exist? Do you have some .htaccess rules
> interfering? Anything of that sort. This is a problem that you will
> find the answer to on the webserver, not within WordPress itself.
>
> -Otto
>
>
> On Tue, Feb 26, 2013 at 3:41 PM, Haluk Karamete <halukkaramete at gmail.com>
wrote:
> > Thank you for your reply Aaron. But no, we have not installed that plug
in.
> >
> > As I said in my original post, I went thru the ritual of deactivating
all
> > my plug ins including reverting to the twentyEleven.
> >
> > Here is some more insight about this issue..
> >
> > I do not have to live with the define('SCRIPT_DEBUG', true), I can
> > perfectly comment it out and use this instead;
> >
> > define('CONCATENATE_SCRIPTS', false);
> >
> > That works too. So I will be keeping that on as of now.
> >
> > What I've also observed was this, whenever I use SCRIPT_DEBUG(TRUE) or
> > CONCATENATE_SCRIPTS(FALSE) solutions, the following takes place on the
VIEW
> > SOURCE;
> >
> > With them,  I get this on the source
> >
> > <script type='text/javascript'
> > src='..../wp-includes/js/jquery/jquery.js?ver=1.8.3'></script>
> >
> > Without, I get the following,
> >
> > <script type='text/javascript'
> >
src='....wp-admin/load-scripts.php?c=1&amp;load%5B%5D=jquery,utils,plupload,plupload-html5,plupload-flash,plupload-silverlight,plupload-html4,json2&amp;ver=3.5.1'></script>
> >
> > which is exactly where the 404 was stemming from.
> >
> > I read the codex on the  SCRIPT_DEBUG (
> > http://codex.wordpress.org/Debugging_in_WordPress#SCRIPT_DEBUG )
> > which has the following to say...
> >
> > SCRIPT_DEBUG is a related constant that will force WordPress to use the
> >> "dev" versions of core CSS and Javascript files rather than the
minified
> >> versions that are normally loaded.
> >
> >
> >
> > I rather leave the one-liner *define('CONCATENATE_SCRIPTS', false);* in
the
> > config, than leaving the other one liner which is* the
> > define('SCRIPT_DEBUG', true);*
> > *
> > *
> >
> >
> >
> >
> > On Tue, Feb 26, 2013 at 1:09 PM, Aaron Jorbin <aaron at jorb.in> wrote:
> >
> >> Are you currently, or have you ever used BulletProof Security?
> >>
> >>
> >>
http://wordpress.org/support/topic/troubleshooting-wordpress-35-master-list#post-3547427
> >>
> >> http://aaron.jorb.in
> >> twitter: twitter.com/aaronjorbin
> >>
> >>
> >> On Tue, Feb 26, 2013 at 3:59 PM, Haluk Karamete <
halukkaramete at gmail.com
> >> >wrote:
> >>
> >> > On 3.5.1 installs, ( and I got two of them ), the admin area JS
actions (
> >> > such as the "Screen Options" or the "Help" pull downs and a whole
bunch
> >> of
> >> > more functionality that relies on DHTML effects) all fails.
> >> >
> >> > To troubleshoot the problem, I checked the JavaScript console (
chrome
> >> > developer tools ), and I saw a 404 being reported in there.
> >> >
> >> > GET .../wp-admin/*load-scripts.php*
> >> >
> >> >
> >>
?c=1&load%5B%5D=admin-bar…alog,wpdialogs,wplink,wpdialogs-popup,wp-fullscreen,media-upload&ver=3.5.1
> >> > 404 (Not Found) post.php:41
> >> >
> >> > And this 404 comes up only on some pages at the admin interface.
> >> >
> >> > For example, when adding a new post ( using the
/wp-admin/post-new.php ),
> >> > there is no 404 issue and thus no js issues. Everything works like a
> >> charm.
> >> > But once the post is published and the /wp-admin/post.php responses
> >> back, I
> >> > get that 404 back again and that's when all the js issues are back.
> >> >
> >> > I don't know what's causing this, but the following one-liner in the
> >> >  wp-config.php totally fixes it.
> >> >
> >> > *define('SCRIPT_DEBUG', true);  *
> >> >
> >> > which is not recommended to keep it on a production site.
> >> >
> >> > So I got this dilemma now. What do I do?
> >> >
> >> > To eliminate the problem, I not only switched our current theme to
> >> > the TwentyEleven( to see if theme is the culprit ),  but no, it
wasn't.
> >> > Symptoms were the same with TwentyEleven.
> >> > I also deactivated all the plugins one by one but no luck... this
did not
> >> > help neither.
> >> >
> >> > So to get going, I had to leave the SCRIPT_DEBUG option on...
> >> >
> >> > But, what's your advise for getting rid of this issue without the
> >> > SCRIPT_DEBUG being TRUE?
> >> >
> >> > And out of curiosity, what is it with define('SCRIPT_DEBUG', true);
that
> >> it
> >> > magically fixes the problem?
> >> > _______________________________________________
> >> > wp-hackers mailing list
> >> > wp-hackers at lists.automattic.com
> >> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >> >
> >> _______________________________________________
> >> wp-hackers mailing list
> >> wp-hackers at lists.automattic.com
> >> http://lists.automattic.com/mailman/listinfo/wp-hackers
> >>
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers