BlobFileDropzone url not updated when navigating in Gitlab-FOSS
Summary
When creating a project in the FOSS version and start to navigate using the repository browser, we encountered issues when uploading files using the BlobFileDropzone (upload modal). The files are being uploaded to last location where a real reload happened and not the current location the user navigated to.
Steps to reproduce
Only occurs in FOSS version. Gitlab.com actually refreshes the page when navigating
- Create a project
- Create a number of subfolders
- Use the repository browser to open a folder (it just needs to be different)
- Upload a file (using the dropdown menu)
Example Project
Tested with version 12.9 and 12.10
What is the current bug behavior?
The file is not being placed in the correct location.
What is the expected correct behavior?
The file should be placed in the correct location.
Relevant logs and/or screenshots
There are several indicators, that the url is wrong, I'm just pasting the POST request in nginx done by the uploader:
***.***.***.*** - - [23/Apr/2020:10:59:31 +0200] "POST /ansible/start/-/create/master HTTP/1.1" 200 76 "https://gitlab.tba-hosting.de/ansible/start/-/tree/master/roles%2Fapache%2Ftemplates" "
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0"
There is also an encoding issue, but we verified that this is not the issue. You see that the user has the referer from a subfolder (roles/apache/templates
) but the POST request goes to /create/master
.
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
System information System: Debian 10 Current User: git Using RVM: no Ruby Version: 2.6.5p114 Gem Version: 2.7.10 Bundler Version:1.17.3 Rake Version: 12.3.3 Redis Version: 5.0.7 Git Version: 2.24.1 Sidekiq Version:5.2.7 Go Version: unknown GitLab information Version: 12.9.1 Revision: 63745c932cc Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 11.7 URL: https://gitlab.tba-hosting.de HTTP Clone URL: https://gitlab.tba-hosting.de/some-group/some-project.git SSH Clone URL: ssh://git@gitlab.tba-hosting.de:47478/some-group/some-project.git Using LDAP: yes Using Omniauth: yes Omniauth Providers: GitLab Shell Version: 12.0.0 Repository storage paths: - default: /var/opt/gitlab/git-data/repositories - medien: /opt/data/git-data/repositories GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Git: /opt/gitlab/embedded/bin/git
Results of GitLab application Check
Expand for output related to the GitLab application check
Checking GitLab subtasks ...Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 12.0.0 ? ... OK (12.0.0) Running /opt/gitlab/embedded/service/gitlab-shell/bin/check Internal API available: OK Redis available via internal API: OK gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Gitaly ...
Gitaly: ... default ... OK medien ... OK
Checking Gitaly ... Finished
Checking Sidekiq ...
Sidekiq: ... Running? ... yes Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking Incoming Email ...
Incoming Email: ... Reply by email is disabled in config/gitlab.yml
Checking Incoming Email ... Finished
Checking LDAP ...
LDAP: ... Server: ldapmain not verifying SSL hostname of LDAPS server 'REDACTED' LDAP authentication... Success LDAP users with access to your GitLab server (only showing the first 100 results) User output sanitized. Found 100 users of 100 limit.
Checking LDAP ... Finished
Checking GitLab App ...
Git configured correctly? ... yes Database config exists? ... yes All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date? ... yes Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory exists? ... yes Uploads directory has correct permissions? ... yes Uploads directory tmp has correct permissions? ... yes Init script exists? ... skipped (omnibus-gitlab has no init script) Init script up-to-date? ... skipped (omnibus-gitlab has no init script) Projects have namespace: ... 1/1 ... yes 6/2 ... yes 13/3 ... yes 13/4 ... yes 13/6 ... yes 13/7 ... yes 6/8 ... yes 14/9 ... yes 14/11 ... yes 14/12 ... yes 13/13 ... yes 13/14 ... yes 14/15 ... yes 14/16 ... yes 14/17 ... yes 13/18 ... yes 14/19 ... yes 13/20 ... yes 16/21 ... yes 16/22 ... yes 23/23 ... yes 24/24 ... yes 16/25 ... yes 16/27 ... yes 14/28 ... yes 14/29 ... yes 52/35 ... yes 50/37 ... yes 52/38 ... yes 60/39 ... yes 64/40 ... yes 64/42 ... yes 64/43 ... yes 64/44 ... yes 60/47 ... yes 52/48 ... yes 64/49 ... yes 14/50 ... yes 45/51 ... yes 71/52 ... yes 59/53 ... yes 87/54 ... yes 87/55 ... yes 6/56 ... yes 59/57 ... yes 6/58 ... yes 14/60 ... yes 14/61 ... yes 14/64 ... yes 107/65 ... yes 6/66 ... yes 107/67 ... yes 56/68 ... yes 59/70 ... yes 97/72 ... yes 107/75 ... yes 107/76 ... yes 117/77 ... yes 117/78 ... yes 115/80 ... yes 118/81 ... yes 119/82 ... yes 116/86 ... yes 6/87 ... yes 52/88 ... yes 49/89 ... yes 52/90 ... yes 43/91 ... yes 43/92 ... yes 43/93 ... yes 52/96 ... yes 59/97 ... yes 127/98 ... yes 127/99 ... yes 128/100 ... yes 130/101 ... yes 43/102 ... yes 131/103 ... yes 128/105 ... yes 135/108 ... yes 120/109 ... yes 120/113 ... yes 43/114 ... yes 131/115 ... yes 107/116 ... yes 43/118 ... yes 128/119 ... yes 128/120 ... yes 128/121 ... yes 20/122 ... yes 131/125 ... yes 138/127 ... yes 128/128 ... yes 128/129 ... yes 128/130 ... yes 22/131 ... yes 131/132 ... yes 20/133 ... yes 43/134 ... yes 20/135 ... yes 128/136 ... yes 107/138 ... yes 131/139 ... yes 119/140 ... yes 119/141 ... yes 107/142 ... yes 5/143 ... yes 16/144 ... yes 111/145 ... yes 120/146 ... yes 50/147 ... yes 52/148 ... yes 120/149 ... yes 61/151 ... yes 131/152 ... yes 131/153 ... yes 148/154 ... yes 131/155 ... yes 151/156 ... yes 153/157 ... yes 59/158 ... yes 128/159 ... yes 175/161 ... yes 16/162 ... yes 176/163 ... yes 131/164 ... yes 131/165 ... yes 131/166 ... yes 131/167 ... yes 177/168 ... yes 177/169 ... yes 107/170 ... yes 179/171 ... yes 18/172 ... yes 93/173 ... yes 20/175 ... yes 148/176 ... yes 148/177 ... yes 148/178 ... yes 148/179 ... yes 148/180 ... yes 148/181 ... yes 148/182 ... yes 148/183 ... yes 148/184 ... yes 148/185 ... yes 182/186 ... yes 177/188 ... yes 148/189 ... yes 20/190 ... yes 183/191 ... yes 43/192 ... yes 128/193 ... yes 148/194 ... yes 148/195 ... yes 16/196 ... yes 52/197 ... yes 4/198 ... yes Redis version >= 2.8.0? ... yes Ruby version >= 2.5.3 ? ... yes (2.6.5) Git version >= 2.22.0 ? ... yes (2.24.1) Git user has default SSH configuration? ... yes Active users: ... 130 Is authorized keys file accessible? ... yes
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished
Possible fixes
I traced it down, and found that in https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/blob/blob_file_dropzone.js#L29 the initialization occurs, which uses form.attr("action")
to extract the location where the upload should happen.
I made a small workaround and placed before line https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/blob/blob_file_dropzone.js#L96 the following code:
dropzone[0].dropzone.options.url = form.attr("action");
This solved this issue, as the action-url is kept up 2 date and is then in sync when the upload is being done.