sourcegraph / sourcegraph-public-snapshot

Code AI platform with Code Search & Cody
https://sourcegraph.com
Other
10.1k stars 1.28k forks source link

Support externalURL at a non-root path #103

Open dadlerj opened 6 years ago

dadlerj commented 6 years ago

Describe the feature request.

A customer requested support for externalURL config values (https://about.sourcegraph.com/docs/config/site) that include subdirectories.

Is your feature request related to a problem? Please describe.

As the customer described it:

I want sourcegraph to respond to http://127.0.0.1:7080/sourcegraph/ with the configuration set to

"externalURL": "http://127.0.0.1:7080/sourcegraph/",

but sourcegraph already responds to http://127.0.0.1:7080 and ignores my subdirectory

Describe alternatives you've considered.

n/a

Additional context

More context from the user:

Yeah it's pretty common for self hosted services.

Maybe as a future feature? Rewriting with reverse proxies is a pretty fragile method after all.

Source graph is a really good code search and it's a tad disappointing this wasn't considered.

Requested by:

beyang commented 6 years ago

Another user has requested this here: https://stackoverflow.com/questions/51223293/nginx-reverse-proxy-subdirectory-rewrites-for-sourcegraph

alexandnpu commented 5 years ago

is there any progress for this issue? I desperately need this feature.

beyang commented 5 years ago

@alexandnpu thanks for the feedback. This is not yet supported. However, we've moved external URL configuration to nginx, which brings us fairly close: https://github.com/sourcegraph/sourcegraph/blob/master/doc/admin/nginx.md. The final step would be to ensure that all frontend AJAX requests and URLs use relative paths, rather than absolute paths (as absolute paths would conflict with the subpath setup).

At the moment, we're backlogged with other priorities, so I can't offer a concrete timeline beyond saying this is on our radar and we will revisit this every month when we do prioritization. We prioritize features based on customer needs and our product roadmap. We also accept open-source PRs if you'd be open to submitting one!

alexandnpu commented 5 years ago

@beyang , thanks for you feedback and sorry for my late reply.

IMHO, I think subdirectories supporting IS the top priority. If users cannot setup sourcegraph, they cannot use it, not to speak of using your advanced features.

sqs commented 5 years ago

@alexandnpu Can you help me understand the need for a subdirectory? What prevents you from running Sourcegraph on its own hostname?

alexandnpu commented 5 years ago

In my company, it is not very convenient to apply a new domain name, so every team has only one internal domain name, like below:

  1. team1.example.com
  2. team2.example.com

if we have to setup our own web tools, the only way we have to do is to use subdirectories under our team domain name. For example, I successfully setup grafana in team1.example.com/grafana with the following simple nginx setup (where I run grafana within docker):

location /grafana/ {
        proxy_pass http://grafana_servers/;
    }

I did some investigation with sourcegraph why it doesnot work with subdirectory in nginx. it turns out to be like what @beyang said above, the frontend ignores the path i setup, the frontend uses only the domain name, not including the subdirectory.

sqs commented 5 years ago

@alexandnpu Got it, thank you. That is helpful to understand. There are other issues we'd need to investigate before making this change, such as cookie hosts and CORS policies, and future product plans around using subdomains (such as myorg.gitlab.io or myorg.github.io for GitLab/GitHub Pages-like features). We generally prioritize customer requests, so if you are at a current customer or plan to be, let me know. Otherwise, we accept PRs and we'll keep this issue updated. Thanks!

netmonk commented 2 years ago

Well it seems this didn't evolve since 2021. Im trying to figure out how to configure sourcegraph to be reachable from https://www.externalurl.foobar/sourcegraph.

This kind of feature is very basic and almost found in most of web application. Also, in the documentation, this limitation must be written and clear. So that peoples like me dont try to install it at my clients request and facing a major issue due to my clients environment constraints.