Attachments forbidden 403 in wiki pages
With no rhyme or reason, attaching a file to a wiki page may fail with 'Forbidden 403 try again or another file'.
A successful upload looks like this in the log:
Started POST "/api/v4/projects/10693/wikis/attachments" for 128.141.79.105 at 2019-03-05 15:27:23 +0100
Processing by Gitlab::RequestForgeryProtection::Controller#index as JSON
Parameters: {"file"=>#<ActionDispatch::Http::UploadedFile:0x00007f3875da0bd8 @tempfile=#<Tempfile:/tmp/RackMultipart20190305-29991-k6xe3i.zip>, @original_filename="sympa.zip", @content_typ
e="application/zip", @headers="Content-Disposition: form-data; name=\"file\"; filename=\"sympa.zip\"\r\nContent-Type: application/zip\r\n">}
Completed 200 OK in 1ms (ActiveRecord: 0.0ms)
On the other hand, this is the fingerprint of a failed upload:
Started POST "/api/v4/projects/10693/wikis/attachments" for 128.141.79.105 at 2019-03-05 15:19:39 +0100
Processing by Gitlab::RequestForgeryProtection::Controller#index as JSON
Parameters: {"file"=>#<ActionDispatch::Http::UploadedFile:0x00007f3873ec3030 @tempfile=#<Tempfile:/tmp/RackMultipart20190305-29997-13gek7s.zip>, @original_filename="sympa.zip", @content_ty
pe="application/zip", @headers="Content-Disposition: form-data; name=\"file\"; filename=\"sympa.zip\"\r\nContent-Type: application/zip\r\n">}
Can't verify CSRF token authenticity
This CSRF token verification failure is handled internally by `GitLab::RequestForgeryProtection`
Unlike the logs may suggest, this does not result in an actual 422 response to the user
For API requests, the only effect is that `current_user` will be `nil` for the duration of the request
Completed 422 Unprocessable Entity in 2ms (ActiveRecord: 0.0ms)