Thomas Barregren

Have now tested the new version.

1) Logging is now working. I see messages in the log file.

2) But the Internal Test URL Checker now returns “500 Internal Server Error” instead of “404 Not Found”

PHP issues two warnings and one error message:

PHP Notice:  Undefined index: base-uri in /…/magasinet/wp-content/plugins/wp-content-security-policy/includes/WP_CSP.php on line 254

PHP Notice:  Undefined index: host in /…/magasinet/wp-content/plugins/wp-content-security-policy/includes/WP_CSP.php on line 720

PHP Fatal error:  Uncaught Error: Call to private method WP_CSP::ProcessPolicyViolation() from context 'WP_CSP_Admin' in /…/magasinet/wp-content/plugins/wp-content-security-policy/admin/WP_CSP_Admin.php:877
Stack trace:
#0 /…/magasinet/wp-content/plugins/wp-content-security-policy/admin/WP_CSP_Admin.php(627): WP_CSP_Admin::TestURLChecker()
#1 /…/magasinet/wp-includes/rest-api/class-wp-rest-server.php(936): WP_CSP_Admin::RestAdmin(Object(WP_REST_Request))
#2 /…/magasinet/wp-includes/rest-api/class-wp-rest-server.php(321): WP_REST_Server->dispatch(Object(WP_REST_Request))
#3 /…/magasinet/wp-includes/rest-api.php(266): WP_REST_Server->serve_request('/wpcsp/v1/route...')
#4 /…/magasinet/wp-includes/class-wp-hook.php(286): rest_api_loaded(Object(WP))
#5 /…/magasinet/wp-includes in /…/magasinet/wp-content/plugins/wp-content-security-policy/admin/WP_CSP_Admin.php on line 877

Julio,

Thanks for your comment. I want to remove everything related to comments. To me it looks like SecuPress (which I thinks is the best security plugin) don’t remove everything when I check I do not need comments… in the Anti Spam section. Some examples:

* Settings > Discussions is still in the menu
* The comment feed is still available
* The rel="pingback" is still in the head element

I’m not only trying to avoid spam. I don’t want comments at all. It would be wonderful if SecuPress could accommodate that in the future. But till then, I need Disable Comments (which I think is the best plugin doing just that).

This ticket falls in between a bug report and a feature request. I think it is a design mistake to determine if this plugin should do its job or not based on whether get_disabled_post_types() of this plugin returns an empty array or not.

Sorry, visited https://…/magasinet/wp-json/ and noticed that I must use POST. I therefore did following test:

curl -v -d "key1=val1" https://www.wtcmalmo.se/magasinet/wp-json/wpcsp/v1/route/LogPolicyViolation?_wpnonce=fd15dc52d7
*   Trying 139.162.161.177...
* Connected to www.wtcmalmo.se (139.162.161.177) port 443 (#0)
* found 149 certificates in /etc/ssl/certs/ca-certificates.crt
* found 604 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* 	 server certificate verification OK
* 	 server certificate status verification SKIPPED
* 	 common name: www.wtcmalmo.se (matched)
* 	 server certificate expiration date OK
* 	 server certificate activation date OK
* 	 certificate public key: RSA
* 	 certificate version: #3
* 	 subject: CN=www.wtcmalmo.se
* 	 start date: Mon, 25 Dec 2017 15:27:14 GMT
* 	 expire date: Sun, 25 Mar 2018 15:27:14 GMT
* 	 issuer: C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
* 	 compression: NULL
* ALPN, server accepted to use http/1.1
> POST /magasinet/wp-json/wpcsp/v1/route/LogPolicyViolation?_wpnonce=fd15dc52d7 HTTP/1.1
> Host: www.wtcmalmo.se
> User-Agent: curl/7.47.0
> Accept: */*
> Content-Length: 9
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 9 out of 9 bytes
< HTTP/1.1 200 OK
< Server: nginx/1.10.3 (Ubuntu)
< Date: Mon, 08 Jan 2018 20:41:24 GMT
< Content-Type: application/json; charset=UTF-8
< Content-Length: 4
< Connection: keep-alive
< X-Robots-Tag: noindex
< Link: <https://www.wtcmalmo.se/magasinet/wp-json/>; rel="https://api.w.org/"
< X-Content-Type-Options: nosniff
< Access-Control-Expose-Headers: X-WP-Total, X-WP-TotalPages
< Access-Control-Allow-Headers: Authorization, Content-Type
< X-WP-Nonce: fd15dc52d7
< Allow: POST
< Cache-Control: max-age=0
< Expires: Mon, 08 Jan 2018 20:41:24 GMT
< Vary: Accept-Encoding
< 
* Connection #0 to host www.wtcmalmo.se left intact

Nothing shows up in the log.

I did following simple test: Visit a page, copy the report-uri (including the nonce) and paste it the addressbar of the browser. I don’t know what response to expect, but this is what I got:

code	"rest_no_route"
message	"No route was found matching the URL and request method"
data	
status	404

Thanks for taking time with this issue.

The CSP header does have a wpnonce query string parameter. (I didn’t include it in my last comment.)

I?don’t seen any errors in the error log.

But there are some warnings in the web browser console. One saying that child-src is deprecated. The other reads: loading pref showConsoleLogs before prefs were initialised, you will not get the correct result content-script.bundle.js:333:7

Thanks for your kind help.

You should now get a proper response from https://…/magasinet/wp-json. It turned out that I had to visit the permalink settings page (so WordPress flushed its rewrite rules after I had enabled the REST API).

But the Internal Test URL Checker still returns 404, because it uses the wrong URL: https://…/wp-json/wpcsp/v1/route/RestAdmin instead of https://…/magasinet/wp-json/wpcsp/v1/route/RestAdmin. The same is true for the Clear Log File button.

Finally, I still don’t see anything in the log when I introduce a violation of the CSP, although report-uri in the CSP header looks right: https://…/magasinet/wp-json/wpcsp/v1/route/RestAdmin.

Thanks for quick reply.

Yes, I had the REST API turned off (I’m embarrassed). It’s now fixed, and following can be found in the HTML: <link rel='https://api.w.org/' href='https://…/magasinet/wp-json/' />.

The report URI in the header seems right (https://…/magasinet/wp-json/wpcsp/v1/route/LogPolicyViolation), but the Internal Test URL Checker still returns 404.

More important, I don’t see anything in the log. I guess I should got plenty of log entries while I tested out the policy now in effect. I have enabled logging of all violations.

Many thanks for your effort.

I have neither of the two alternatives. ??

This is the output of grep -lR WP_POST_REVISIONS *when run in root:

wp-content/plugins/wp-cms-post-control/wp-cms-post-control.php
wp-includes/default-constants.php
wp-includes/revision.php

The constant is defiend on line 324 in wp-includes/default-constants.php

SOLUTION:

WordPress don’t store a video clip’s path in its metadata (it is still available as the attachment’s guid). That explains the bug.

Since ILAB Media Tools only supports images, as far as I understand, it should really not process non-images (videos, pdfs, whatever). So the best solution (in my opinion) is to not to import non-images in the first place.

I therefore modified importMedia() in classes/tools/s3/ilab-media-s3-tool.php so it looks as follows:

public function importMedia() {

    $query = new WP_Query(array(
      'post_type'      => 'attachment',
      'post_status'    => 'inherit',
      'post_mime_type' =>'image',
      'fields'         => 'ids',
      'nopaging'       => true,
    ));

    if ($query->post_count > 0) {
        update_option('ilab_s3_import_status', true);
        update_option('ilab_s3_import_total_count', $query->post_count);
        update_option('ilab_s3_import_current', 1);

        $process = new ILABS3ImportProcess();

        for($i = 0; $i < $query->post_count; ++$i) {
            $process->push_to_queue(['index' => $i, 'post' => $query->posts[$i]]);
        }

        $process->save();
        $process->dispatch();
    } else {
        update_option('ilab_s3_import_status', false);
    }

    header('Content-type: application/json');
    echo '{"status":"running"}';
    die;
}

Following is a patch-file:

--- classes/tools/s3/ilab-media-s3-tool.php	2016-08-24 10:44:24.010656014 +0200
+++ classes/tools/s3/ilab-media-s3-tool.php	2016-08-24 10:44:03.554613353 +0200
@@ -482,21 +482,23 @@

     public function importMedia() {

-        $attachments = get_posts([
-                                     'post_type'=> 'attachment',
-                                     'posts_per_page' => -1
-                                 ]);
+        $query = new WP_Query(array(
+          'post_type'      => 'attachment',
+          'post_status'    => 'inherit',
+          'post_mime_type' =>'image',
+          'fields'         => 'ids',
+          'nopaging'       => true,
+        ));

-
-        if (count($attachments)>0) {
+        if ($query->post_count > 0) {
             update_option('ilab_s3_import_status', true);
-            update_option('ilab_s3_import_total_count', count($attachments));
+            update_option('ilab_s3_import_total_count', $query->post_count);
             update_option('ilab_s3_import_current', 1);

             $process = new ILABS3ImportProcess();
-
-            for($i = 0; $i<count($attachments); $i++) {
-                $process->push_to_queue(['index' => $i, 'post' => $attachments[$i]->ID]);
+
+            for($i = 0; $i < $query->post_count; ++$i) {
+                $process->push_to_queue(['index' => $i, 'post' => $query->posts[$i]]);
             }

             $process->save();

This is the content of $data in the failing lines:

Array
(
    [bitrate] => 12813162
    [filesize] => 35972999
    [mime_type] => video/quicktime
    [length] => 22
    [length_formatted] => 0:22
    [width] => 1920
    [height] => 1080
    [fileformat] => mp4
    [dataformat] => quicktime
)

Scott,

You have a great plugin that really has its place.

However, the code severely needs an overhaul. There are countless static call of non-static functions, which results in white screen of death on sites running PHP in strict mode.

Looking forward to an update at your earliest possible convenience. Meanwhile, I?need to disable it. ??