“HTTP Error” when uploading files / Attachment Upload not working

Hi @scipper15 – Sorry to hear you’re having problems. A few questions:

– Are you able to upload files normally through the Dashboard? Eg, Dashboard > Media > Add New
– Is the problem limited to certain user types? Does a site administrator also have the problem?
– Is your site’s Dashboard available at the same domain as the front end? In other words, is the AJAX request going to https://c-vbci-kvi.allprojects.co/wp-admin/async-upload.php?
– Does other BP/Docs AJAX in the front end work properly? For example, when creating a new Doc, when you choose a different Associated Group from the dropdown, do the privacy options automatically update to reflect the changes? Do you see any other AJAX-related 403s in the browser console?
– Is HTTPS set up for any part of your site? You mention that this is a dev site – is there also a production site at this time? Are you having the same problem there?

Hello Boone,

thanks for your reply!

– exactly that’s the problem: It’s working without problems in the WordPress media library.
– as far as I noticed I can’t upload any file independently of size and file type. Till now I did all those trys as Super Admin.
– Yes, ajax request goes to https://c-vbci-kvi.allprojects.co/wp-admin/async-upload.php
– Changing the associated group for example seems to work (opens 4 AJAX Requests, all result in 200/OK). There are no other 403s in the console.
– HTTPS is not enabled still. We still don’t have a production site.

Directories are writable btw. and have the correct owner (www-data, user of the webserver) is set. In /wp-content/uploads/bp-attachments there is a subdirectory called “0” (“zero”) and in there there are two files with following name and content:
test.html: “This is a test of the Protected Attachment feature of BuddyPress Docs. Please do not remove.”
.htaccess:
“# BEGIN BuddyPress Docs
RewriteEngine On
RewriteBase /
RewriteRule (.+) ?bp-attachment=$1 [R=302,NC]
# END BuddyPress Docs”

But I don’t think that’s relevant in this context. There are no other files beneath /wp-content/uploads/bp-attachments btw.

Best regards
Reinhard Eichhorn

Thanks for the additional details.

From what you’ve described, it doesn’t sound like file permissions are part of the cause.

Another question for you: When you view the async-upload.php request in the browser console, is there any content in the Response? Does it say, for instance, ‘Sorry, you are not allowed to upload files’? Or perhaps -1? This will help narrow down the source.

Another possibility is that there’s a nonce mismatch; WP will throw a 403 in this case, when the request takes place over AJAX. If this is the case, it might be that the attachments modal is picking the wrong nonce to send to the server (maybe because there’s a duplicate ‘#wpnonce’ element in the DOM?). If you’re able, you might trace to check_ajax_referer() to see if this may be the problem.

Hallo again, and thanks for the fast reply!

The response of the ajax-reuqest is “-1” as you supposed.

To your second point “check_ajax_referer()”: I could, but actually don’t know where to do it. Can you give a brief explanation where to put this code snippet? Is anywhere in the functions enough? Which arguments do I use?

<?php check_ajax_referer( $action, $query_arg, $die ) ?>

Thanks again, hope this helps.

Beste regards
Reinhard Eichhorn

Hi Reinhard-

As Boone has suggested, getting a -1 back is a good indication that the nonce is broken. When attempting to upload a file, look at the parameters passed as part of the request (I use the “Network” tool in Firefox dev tools for this). There will be one called _wpnonce. Note the nonce sent, like 3ae36f62c2.

In the source code of your doc edit screen, do a search for “nonce” and see if there are conflicting values. If there are, it’s likely that another plugin is inserting nonces for its own purposes, but it’s breaking this upload functionality.

Hello David,

thanks for your reply.

The ajax-request uses for example 212b462ef4 as the nonce.

But I found that in this try nonce was there 2 times (in source code of Website, examined with developer tools):
Once here:

<div id="doc-submit-options">
  <input type="hidden" id="_wpnonce" name="_wpnonce" value="<strong>0b7327d018</strong>">
  <input type="hidden" name="_wp_http_referer" value="/docs/create/">
  <input type="hidden" id="doc_id" name="doc_id" value="31506">
  <input type="submit" name="doc-edit-submit" id="doc-edit-submit" value="Save">
  <a href="" class="action safe">Cancel</a>
</div>

and once in the JavaScript part (“var _wpPluploadsettings = […]”. But the nonce in the JavaScript is different, it’s 212b462ef4. But both times it’s a nonce from BuddyPress Docs, right?

What can I do further for testing / debugging?

Thanks for your help.

Beste regards
Reinhard Eichhorn

Hello,

I have to come back to this thread: The problem miraculously disappeared a while ago but recently came back. Problem is that I even disabeled all Plugins (except BuddyPress and BuddyPress DOCS) and changed theme to Twentynineteen for testing just in case there was some plugin or theme interferrence: but it is not, the problem persists in this minimal configuration.

I updated to WordPress 5.1 meanwhile (problem was there before this update) and to BuddyPress 4.2.0 (from 4.1.0) and BuddyPress DOCS is up to date too (2.1.2).

Console says “POST https://mitgliederbereich.chemie-kvi-bayern.de/wp-admin/async-upload.php 403 (Forbidden)”

Can you help me here please or at least tell me where to look at to debug further. There are no log entries in PHP-error log concerning this error.

Best regards
Reinhard

That’s so strange, it’s working again. Had to delete cache / open inkognito-tab.

Other than that I did the following:
Added the following in .htaccess file at the WordPress root folder:
# Exclude the file upload and WP CRON scripts from authentication
<FilesMatch “(async-upload\.php|wp-cron\.php|xmlrpc\.php)$”>
Satisfy Any
Order allow,deny
Allow from all
Deny from none
</FilesMatch>

AND
Your server may have mod_security, and it might be causing problems:
Disable it to see if that is the problem.
To do this, make an .htaccess file in your wp-admin directory.
Add the following code to it:
<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>

FROM: https://docs.presscustomizr.com/article/229-fixing-errors-when-uploading-images-in-wordpress

Regards
Reinhard

Hm. It sounds like you’re having two different problems:
? 403 forbidden error (server level security)
? AJAX response of -1 (WordPress, software level security–usually mismatched nonces)

Your most recent post deals with some server level security issues. Are those resolved?

When you use an incognito/uncached browser, do you find that uploads are successful? (No more -1 responses?)

It was strange, problem disappeared after using an inkognito-tab. The only two things which I did meanwhile were the ones mentioned in my last post. Uploads are successfull again. I don’t exactly know why.

• This reply was modified 5 years, 9 months ago by scipper15.

Another source of caching problems is aggressive “expires” headers rules in htaccess files, like:

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresDefault "access plus 1 month"
</IfModule>

Which could cause your browser to use an old version of /docs/create/ rather than the current document. Basically, it’s important that the create and edit pages not be cached, whether by plugin like WP Super Cache or by browser via expires headers. (And when you use the incognito window, your browser will not use browser caching, as I understand it, so that could be part of your issue.)

• This reply was modified 5 years, 9 months ago by David Cavins.
• This reply was modified 5 years, 9 months ago by David Cavins.

Hello,

thanks for coming back on this. I suppose browser caching / server configuration issues, too, as it is so unpredictable when those problems occure (sometimes they do and “suddenly” they disappear). Website is behind a Nginx proxy, mabey there is some agressive header configuration too. As soon as I have nailed the reasons behind this behaviour I’ll give you an update on this. Mabey then (when cleared) it might be a good idea to have this kind of issue added to a FAQ section of the addon, if there is one, as the problem is definitely not plugin or theme originated.

Best regards
Reinhard