Relative url triggers rails-turbolink on links to external websites
Created by: flaiker
Summary
With relative-url-support enabled and other services being on the same subdomain (fileserver, gitlab-ci, ...) hyperlinks in markdown-files to these services are not marked with the data-no-turbolink="data-no-turbolink"
-attribute which results in the linked page loading without its own js/css but with the one of the gitlab instance.
Steps to reproduce
- Setup a gitlab instance using relative url support, resulting in gitlab being available at
https://sub.domain.com/gitlab
- Setup another service on the same subdomain but with a different root, for example Gitlab-CI:
https://sub.domain.com/ci
- Create a repository with a markdown file (like README.md) and insert a hyperlink like:
[See on CI](https://sub.domain.com/ci/projects/1?ref=master)
- Click on the link
Expected behavior
The link should be opened in the browser like any other link to an external website.
Observed behavior
Instead the link is opened using the rails-turbolink-feature, which results in css missing / being wrong.
Relevant logs and/or screenshots
Directory listing with gitlab-stylesheet
Normal Gitlab-CI repository overview
Gitlab-CI with Gitlab stylesheet
You can solve this by pressing F5, although then you have the same problem going back from Gitlab-CI to Gitlab, as you can see here:
Normal Gitlab repository overview
Gitlab respository with Gitlab-CI stylesheet
Also interesting to note as in my example I took the gitlab-ci badge which is already linked in the repository overview automatically, however that one works as it has the additional html-attribute. Here are the two badge links:
Created by Gitlab on connecting a repo with gitlab-ci:
<a data-no-turbolink="data-no-turbolink" href="https://sub.domain.com/ci/projects/1?ref=master"><img alt="build status" src="https://sub.domain.com/ci/projects/1/status.png?ref=master"></a>
Created with markdown:
<a href="https://sub.domain.com/ci/projects/1?ref=master"><img src="https://sub.domain.com/ci/projects/1/status.png?ref=master" alt="build status"></a>
Output of checks
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true
Checking Environment ...
Git configured for git user? ... yes
Checking Environment ... Finished
Checking GitLab Shell ...
GitLab Shell version >= 2.6.3 ? ... OK (2.6.3)
Repo base directory exists? ... yes
Repo base directory is a symlink? ... no
Repo base owned by git:git? ... yes
Repo base access is drwxrws---? ... yes
Satellites access is drwxr-x---? ... yes
hooks directories in repos are links: ...
6/2 ... ok
7/3 ... ok
8/4 ... ok
8/5 ... ok
8/6 ... ok
8/7 ... ok
8/8 ... ok
8/9 ... ok
8/10 ... ok
8/11 ... ok
8/12 ... ok
8/13 ... ok
8/14 ... ok
8/15 ... ok
8/16 ... ok
8/17 ... ok
8/18 ... ok
8/19 ... ok
8/20 ... ok
8/21 ... ok
8/22 ... ok
8/23 ... ok
8/24 ... ok
8/25 ... ok
8/26 ... ok
8/27 ... ok
8/28 ... ok
8/29 ... ok
8/30 ... ok
2/31 ... ok
2/32 ... ok
2/33 ... ok
2/34 ... ok
2/35 ... ok
2/36 ... ok
Running /home/git/gitlab-shell/bin/check
Check GitLab API access: OK
Check directories and files:
/home/git/repositories/: OK
/home/git/.ssh/authorized_keys: OK
Test redis-cli executable: redis-cli 2.8.4
Send ping to redis server: PONG
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Sidekiq ...
Running? ... yes
Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking LDAP ...
LDAP is disabled in config/gitlab.yml
Checking LDAP ... Finished
Checking GitLab ...
Database config exists? ... yes
Database is SQLite ... no
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Init script exists? ... yes
Init script up-to-date? ... yes
projects have namespace: ...
6/2 ... yes
7/3 ... yes
8/4 ... yes
8/5 ... yes
8/6 ... yes
8/7 ... yes
8/8 ... yes
8/9 ... yes
8/10 ... yes
8/11 ... yes
8/12 ... yes
8/13 ... yes
8/14 ... yes
8/15 ... yes
8/16 ... yes
8/17 ... yes
8/18 ... yes
8/19 ... yes
8/20 ... yes
8/21 ... yes
8/22 ... yes
8/23 ... yes
8/24 ... yes
8/25 ... yes
8/26 ... yes
8/27 ... yes
8/28 ... yes
8/29 ... yes
8/30 ... yes
2/31 ... yes
2/32 ... yes
2/33 ... yes
2/34 ... yes
2/35 ... yes
2/36 ... yes
Projects have satellites? ...
6/2 ... yes
7/3 ... yes
8/4 ... yes
8/5 ... yes
8/6 ... yes
8/7 ... yes
8/8 ... yes
8/9 ... yes
8/10 ... yes
8/11 ... yes
8/12 ... yes
8/13 ... yes
8/14 ... yes
8/15 ... yes
8/16 ... yes
8/17 ... yes
8/18 ... yes
8/19 ... yes
8/20 ... yes
8/21 ... yes
8/22 ... yes
8/23 ... yes
8/24 ... yes
8/25 ... yes
8/26 ... yes
8/27 ... yes
8/28 ... yes
8/29 ... yes
8/30 ... yes
2/31 ... yes
2/32 ... yes
2/33 ... yes
2/34 ... yes
2/35 ... yes
2/36 ... yes
Redis version >= 2.0.0? ... yes
Ruby version >= 2.0.0 ? ... yes (2.1.6)
Your git bin path is "/usr/bin/git"
Git version >= 1.7.10 ? ... yes (2.4.0)
Active users: 4
Checking GitLab ... Finished
Gitlab Version GitLab 7.11.0.rc2 a7a5de7f GitLab Shell 2.6.3 GitLab API v3 Ruby 2.1.6p336 Rails 4.1.9
sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production
System information
System: Ubuntu 14.04
Current User: git
Using RVM: no
Ruby Version: 2.1.6p336
Gem Version: 2.2.3
Bundler Version:1.9.4
Rake Version: 10.4.2
Sidekiq Version:3.3.0
GitLab information
Version: 7.11.0.rc2
Revision: a7a5de7
Directory: /home/git/gitlab
DB Adapter: postgresql
URL: https://***.com/git
HTTP Clone URL: https://***.com/git/some-project.git
SSH Clone URL: git@***.com:some-project.git
Using LDAP: no
Using Omniauth: yes
Omniauth Providers: github
GitLab Shell
Version: 2.6.3
Repositories: /home/git/repositories/
Hooks: /home/git/gitlab-shell/hooks/
Git: /usr/bin/git
Possible fixes
Since other links to external websites work normally there must be some code checking for wether a link is internal or external which needs to also take the relative url root into consideration. Alternatively you could disable the turbolink feature for all "user-generated" links, so wikis, repository files etc. (that would be more of a dirty hotfix...). For now I replaced my links with links to the http-version of the website so that the turbolink-trigger doesn't fire but I still get to the url (because I have setup an auto redirect to https) which obviously is not the ideal solution. Or maybe there is something in nginx's configuration I can change?
I know using the relative url support is not recommended, though I would appreciate it if this could be fixed as without the relative url I would need to buy multiple ssl-certs for all the subdomains of the different services which is an expense factor.