Attachment upload fails

Hi,
I am hoping that the way to the solution is simple (but I have currently no clue) because the issue is simple: If I want to upload an image (jpg, just 300kB), I get an error (without further details). I tried on different pages. Xwiki version is 13.1.
How can I locate the reason of the issue?

Thanks for your support

without further details

In the attachment upload UI there is indeed not much room for error reporting, but you might find more information in the application server log. See Logging (XWiki.org) if you are not sure where you find the log.

Hi,
in the log I see the following warning:
WARN o.x.c.i.DefaultCSRFToken - CSRFToken: Secret token verification failed, token: "null", stored token: ...
I tried to find some hints in the forum and old tickets but did not find a solution.
I am using xwiki with a proxy. I tried already to access directly but the issue was still there.

You sure this gets logged as a reaction to a failing upload ?

I just tried again. The warning is not there until I try to upload. If I try to upload multiple times it’s there once for each time.

Full warning text is:
tomcat9[795]: 2021-03-15 19:06:02,106 [https-openssl-apr-8443-exec-2 - https://localhost:8443/xwiki/upload/Kanu-Touren/Tourvorschl%C3%A4ge/Jagst/WebHome] WARN o.x.c.i.DefaultCSRFToken - CSRFToken: Secret token verification failed, token: "null", stored token: "..:"

So…yes, I would say I am quite sure.

OK very strange then. When you upload an attachment through the UI a special token is sent along with the attachment content to avoid CSRF attacks (where something would use you to upload stuff without you noticing). In seems in your case the token is not sent or not received but hard to tell why without a way to reproduce.

What you could do is enable your browser dev tool and especially the network tool which show the requests. Then upload an attachment and look at the request which has /xwiki/upload/ in it and check if you find a “form_token” at the end of the request content (should start with the actual attachment content, the a xredirect and then the form_token). This will at least tell use if the issue is with sending the token or receiving it.

Just a quick intermediate reply: Last and this week and the weekend are quite busy. I’ll probably check next weekend.

I tried to find it, but did not succeed yet.
Using Firefox I am in this sheet:
image

That’s what I see when I try to upload:
image

Am I in the right place?
Where do I find the required information?

This weekend would be great to investigate in the issue. Please let me know where to find the needed information to find the cause of the problem (see my post 24-Mar)

The Network tab need to be open when you upload to get the upload related requests.

Before for and after upload approach there are only these two lines difference:
image

Maybe I just a hint which could help to find the cause:
I am accessing wiki via https://mydomain.de/xwiki/view/Admin-Infos/TestSeite
But in the warn message in the log appears https://localhost:8443/xwiki/upload/Admin-Infos/TestSeite

I tried to find already the reason for that but did not succeed.

After a long search I found the reason (but not the final fix yet).
The reason was in my configuration which I tried to adapt according to Short URLs (XWiki.org)

If my web.xml contains the <filter> and <filter-mapping> everything works - except the upload.
If remove that the upload works (but the URLs are not shortened).

Does anybody have an idea how I could further narrow down the reason and finally have short URLs and working upload?

Hi all. Sorry for hijacking this thread but I have the very same problem with our Wiki (Version 13.4 and 13.8 - no issues in a backup of our Wiki v. 12.8!).

When I have the UrlRewriteFilter enabled in web.xml like explained here (Short URLs (XWiki.org)) I cant upload attachments via the attachment tab on the bottom of the wiki page. Also I can’t create pages with importing office files like a Word document. However uploading a file as attachment with the CKEditor works perfectly fine. Deleting attachments also works. No additional issues detected.

To make things clearer let me post some steps I did to narrow down the problem.

Network tool of my browser (Firefox, F12 thing):

Working upload Wiki version 12.8 with UrlRewriteFilter ENABLED:

http://wiki/upload/Spielwiese/Inhaltsverzeichnis%20auf%20der%20rechten%20Seite/WebHome

http://wiki/get/Spielwiese/Inhaltsverzeichnis%20auf%20der%20rechten%20Seite/?xpage=attachmentslist&forceTestRights=1

Working upload Wiki version 13.8 with UrlRewriteFilter DISABLED:

http://wiki/bin/upload/Spielwiese/Inhaltsverzeichnis%20auf%20der%20rechten%20Seite/WebHome

http://wiki/bin/get/Spielwiese/Inhaltsverzeichnis%20auf%20der%20rechten%20Seite/?xpage=attachmentslist&forceTestRights=1

13.8 looks quite similar to 12.8, except for the truncated /bin path.

Deleting the attachment in Wiki version 13.8 with UrlRewriteFilter DISABLED:

http://wiki/bin/delattachment/Spielwiese/Inhaltsverzeichnis%20auf%20der%20rechten%20Seite/WebHome/SOPImportV3.docx?form_token=0vW5AprzpcH5gztU0bjKwQ&xredirect=%2Fbin%2Fview%2FSpielwiese%2FInhaltsverzeichnis%2520auf%2520der%2520rechten%2520Seite%2F%23Attachments

http://wiki/bin/view/Spielwiese/Inhaltsverzeichnis%20auf%20der%20rechten%20Seite/#Attachments

In this case I can see a token being submitted.

Not working upload Wiki version 13.8 with UrlRewriteFilter ENABLED:

import_fehlermeldung

http://wiki/upload/Spielwiese/Inhaltsverzeichnis%20auf%20der%20rechten%20Seite/WebHome

http://wiki/view/Spielwiese/Inhaltsverzeichnis%20auf%20der%20rechten%20Seite/?resubmit=%2Fbin%2Fupload%2FSpielwiese%2FInhaltsverzeichnis%2520auf%2520der%2520rechten%2520Seite%2FWebHome%3Fsrid%3DaAlfLXLN&xback=%2Fview%2FSpielwiese%2FInhaltsverzeichnis%2520auf%2520der%2520rechten%2520Seite%2F&xpage=resubmit

The second URL looks completely different from what I see when the UrlRewriteFilter is disabled.

In my logfiles I can read:

Oct 7 09:49:58 wiki tomcat9[1593]: 2021-10-07 09:49:58,913 [http-nio-80-exec-6 - http://wiki/upload/Spielwiese/Inhaltsverzeichnis%20auf%20der%20rechten%20Seite/WebHome] WARN o.x.c.i.DefaultCSRFToken - CSRFToken: Secret token verification failed, token: "null", stored token: "OSzeGOh4ZCS7oqO8Z8dcTA"

and

[07/Oct/2021:10:09:56 +0000] "GET /view/Spielwiese/Inhaltsverzeichnis%20auf%20der%20rechten%20Seite/?resubmit=%2Fbin%2Fupload%2FSpielwiese%2FInhaltsverzeichnis%2520auf%2520der%2520rechten%2520Seite%2FWebHome%3Fsrid%3DLKYTgX64&xback=%2Fview%2FSpielwiese%2FInhaltsverzeichnis%2520auf%2520der%2520rechten%2520Seite%2F&xpage=resubmit HTTP/1.1" 401 6468

So it seems there is something wrong with the CSRFToken.

When I upload and delete an attachment via CKEditor and with UrlRewriteFilter ENABLED:

import_editor_2
import_editor_3

http://wiki/get/Spielwiese/Inhaltsverzeichnis%20auf%20der%20rechten%20Seite/?sheet=CKEditor.FileUploader&outputSyntax=plain&syntax=xwiki%2F2.1&language=de&form_token=OSzeGOh4ZCS7oqO8Z8dcTA&initiator=filebrowser

http://wiki/delattachment/Spielwiese/Inhaltsverzeichnis%20auf%20der%20rechten%20Seite/WebHome/SOP_Import_V3.docx?form_token=OSzeGOh4ZCS7oqO8Z8dcTA&xredirect=%2Fview%2FSpielwiese%2FInhaltsverzeichnis%2520auf%2520der%2520rechten%2520Seite%2F%23Attachments 
http://wiki/view/Spielwiese/Inhaltsverzeichnis%20auf%20der%20rechten%20Seite/#Attachments

So I understand that even with UrlRewriteFilter ENABLED the CSRFToken thing CAN work (but only with the CKEditor, not with the upload button on the attachment tab).

Oh, and when I try to create a page with importing an office file I get an error message like this after hitting submit:

office_fehlermeldung

This does not occur when the UrlRewriteFilter is disabled.

Pls help :slight_smile:

Thanks!

Heino

Hi,
Same problem here.

CSRFToken: Secret token verification failed, token: "null"

while UrlRewriteFilter is enabled.

The upload was working with v12.9.
It stopped after upgrading to v13.7 and i could only upload through the CKEditor.
I’ve just tested v13.9 and the problem still exists.

Has anyone found a fix?

Hi,
I did not find a solution for the problem I had a while ago (see older messaages in this threat). Finally I removed the UrlRewrite.

Hello all,
I faced the same problem after upgrading from xwiki 11 to 13.10. And I also run short-URLs and would prefer not to abandon them.

Based on the detailed attempts of @heinoh I observed the network tab of the inspector for the wysiwyg editor: The xredirect and form_token parameters are passed at the URL. This, probably, allows an upload form recipient to check the validity of the the CSRF token before starting to swallow the attachment which is, otherwise, as part of the big stream of attachments.

So I tried to correct upload.min.js to do the same.
I simply replaced upload.min.js by upload.js (to make it readable) then changed the line 237 from request.open('POST', this.formData.action); to request.open('POST', this.formData.action + "?form_token="+this.formData.additionalFields["form_token"] + "&xredirect=" + escape(this.formData.additionalFields["xredirect"]));.

This made my uploads work. ShortURLs remain active :-).

I am not sure if or how I should file a fix within a jira issue.
paul

3 Likes

This looks like a regression and a Jira issues was raised on [XWIKI-19444] Uploading an attachment fails when using short URLs - XWiki.org JIRA.
WDYT @tmortagne?

I had the same problem with uploading while using Short URLs. @polx’s post resolved it.

Hi,
I have the same issue. @polx 's workaround fixed it mostly. I still have the same issue when trying to upload user avatars.

Warning

This request contains an invalid authentication information.

This might happen in the following situations:

  • You left the editor open in another window/tab and logged off and on again
  • Your authentication token expired after a long period of inactivity
  • Somebody tried to perform a CSRF attack

If you are sure that none of these situations apply in your case, you might have found a bug. We are sorry about that, please report it on XWiki JIRA

Do you want to resend the request? If unsure, say No.

and I get following warning in debugger

CSRFToken: Secret token verification failed, token: “null”, stored token: “<removed>”

Would anyone have a fix or a pointer as to what file would have to be edited?