Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • G gitlabhq1
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 21
    • Issues 21
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 12
    • Merge requests 12
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • gpt
  • large_projects
  • gitlabhq1
  • Issues
  • #9302

Closed
Open
Created May 16, 2015 by Administrator@rootOwner

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

  1. Setup a gitlab instance using relative url support, resulting in gitlab being available at https://sub.domain.com/gitlab
  2. Setup another service on the same subdomain but with a different root, for example Gitlab-CI: https://sub.domain.com/ci
  3. 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)
  4. 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

Normal directory listing 2

Directory listing with gitlab-stylesheet 1

Normal Gitlab-CI repository overview 4

Gitlab-CI with Gitlab stylesheet 3

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 6

Gitlab respository with Gitlab-CI stylesheet 5

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.

Assignee
Assign to
Time tracking