403 error uploading PDF files to main document

I am using Tainacan in Wordpress 6.4.2. I am logged in with the Administrator role. I have verified with the User Role Editor plugin that this role has all capabilities enabled. When I try to attach a PDF file to a collection record, I get error 403 Forbidden (nginx). The message appears in the main document field. This seems to happen only with PDF files. It does not happen with graphic or text files (including docx files). Your help would be greatly appreciated.

Hi @argeifontesfunes,

Is your item private in this situation? If yes, there might be missing some redirect configuration in your nginx settings. In apache servers, this tend to be something that we could adjust in the .httaccess file. I’m not very familiar with nginx, but we’ll discuss here and see if we can find the related instructions.

Dear Mateus: The item is “published”. There is no problem with uploading PDFs to the attachments section. When I upload a PDF to main document section, I get the problem. The file gets uploaded to media library and to the attachments section, but it shows the 403 error.

Thank you for your help.

Best regards,

                    Pedro

Dear Mateus:

I apologize for insisting on this issue. I have no technical knowledge, but I think the problem has to do with the pdf-viewer. It is possible that this is the reason why the problem only appears with PDF files. The page of a published item has an area where the processing wheel appears (see photo). Is this a particular problem with sites running on nginx? Again, thank you for your help.

Best regards,

                    Pedro

The PDF viewer will display an iframe that opens in the folder where the PDF file is uploaded. I suspect of nginx redirection configuration because the URL that renders inside the iframe could be showing that error. Could you please provide us a public item page so we can inspect the inner HTML and see the network requests?

Thank you Mateus. As I mentioned elsewhere, I have corrected ImageMagick configuration to allow read and write of PDF.

This is a published item:

Published item

Could you do a dummy test, where you upload a PDF file that does not contains “.” or “_” in its name?

Unfortunately, if that doesn’t solve it is hard for us to identify the cause of the problema because this is very server-related.

Considering that you don’t have much knowledge of the technical details, what you have to do is ask to whomever is offering support to your server to check why this page:
https://funesfrpre.uniandes.edu.co/wp-content/plugins/tainacan/views/libs/pdf-viewer/pdfjs-dist/web/viewer.html?file=https://funesfrpre.uniandes.edu.co/wp-content/uploads/tainacan-items/29989/32489/bg-import-19.log_.pdf

Is returning an 403 error, even though this one:

Does not returns an error. The first page contains the PDF viewer library, which is a JavaScript that loads the file on the second link.

It could be a variety of settings, but one thing that we’ve seen now and then are CORS settings in the server that were blocking this kind of request.

Hopefully with this details they can give you a direction.

Thank you, Mateus for the time spent on this issue. I will get help from the server side and get back to you.

Best regards,

                    Pedro

Dear Mateus:

We have found a solution to the problem. It might be of interest to other people working under Nginx. Nginx blocks by default access to js files in the wp-content directory with this rule in the /etc/nginx/nginxconfig.io/wordpress.conf file:

WordPress: deny wp-content, wp-includes php files

location ~* ^/(?:wp-content|wp-includes)/.*.php$ {
deny all;
}

We have added the following rule to the beginning of that file:

Permitir acceso a viewer.html en Tainacan plugin

location = /wp-content/plugins/tainacan/views/libs/pdf-viewer/pdfjs-dist/web/viewer.html {
allow all;
}

Now, things are working as expected. Again, thank you for the time devoted to this issue.

Best regards,

                    Pedro
2 curtidas

I should say that it was our IT department who had added the rule blocking js scripts inside the wp-content directory as a safety measure.

Best regards,

                    Pedro

Este tĂłpico foi fechado automaticamente 5 dias depois da Ăşltima resposta. Novas respostas nĂŁo sĂŁo mais permitidas.