[wp-trac] [WordPress Trac] #10551: wp_die() triggers block when using ModSecurity Core Rules
WordPress Trac
noreply at wordpress.org
Tue Oct 7 22:50:05 UTC 2014
#10551: wp_die() triggers block when using ModSecurity Core Rules
-------------------------------------------------+-------------------------
Reporter: cstrosser | Owner: westi
Type: defect (bug) | Status: accepted
Priority: low | Milestone: Future
Component: Security | Release
Severity: normal | Version: 2.8.3
Keywords: needs-patch dev-feedback westi- | Resolution:
likes | Focuses:
-------------------------------------------------+-------------------------
Comment (by nacin):
This function already has a ton of "magic", I'll give you that. Example:
for `wp_die( $wp_error_object )`, that `WP_Error` object could also have a
title in its error data, and it'd magically work.
But we're already giving this function a new prototype. Existing:
{{{
wp_die( string|WP_Error $message = '', $title = '', array $args = array()
)
}}}
New:
{{{
wp_die( string|WP_Error $message = '', $title = '', int $response_code =
500 )
}}}
I've been convinced to be conservative on method overloading because it
really damages IDE usage (example: `add_query_arg()`) but as long as
"standard" arguments are listed (in `add_query_arg()`'s case, they are
not, and `func_get_arg()` is used), then I'm more for it. Why not an
additional prototype of:
{{{
wp_die( string|WP_Error $message = '', int $response_code = 500 )
}}}
If we had a default message (which we don't), I'd even be OK with even
allowing this, too:
{{{
wp_die( int $response_code = 500 )
}}}
I dunno. I can be convinced either way. Check out [attachment:10551.diff]
as a sample.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/10551#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list