Running atlantis on non-root URLs leads to broken images & stylesheets

[jml]

I'm running Atlantis v0.4.4 on a non-root URL (e.g. https://example.com/admin/atlantis). It works fine (thanks!) but the web page has default browser stylings and broken images.

Looking at the rendered HTML, it's because it refers to /static/images/atlantis-icon.png, when it should be https://example.com/admin/atlantis/static/images/atlantis-icon.png.

I found this surprising, since this is what I guessed to be the purpose of the --atlantis-url flag.

Looking at the code, the absolute /static/... path is hard-coded in the templates.

Would a PR to fix this be welcome?

[lkysow]

Hi Jonathan, sorry about that, I hadn't thought of using the --atlantis-url flag to also specify a base path.

I'm curious what your use-case is? Why do you need to host it at a non-root URL?

I'm wary of supporting a different base path simply because it adds complexity. I know it doesn't seem like much but I want to keep Atlantis as simple as possible so I can make changes quickly.

Either way, currently Atlantis should error out if a path is used in --atlantis-url. I've created #214 to track that.

[jml]

No worries. I’m still super pleased that I didn’t have to write Atlantis myself. I’m running it inside a Kubernetes cluster which has an authenticating proxy in front of it, and routes to services based on url path. We aren’t going to register a new subdomain and introduce a new way of routing for our Atlantis deployment. I totally get where you’re coming from about being ruthless with new complexity. However, may I suggest that prepending the base URL reduces complexity? Currently, Atlantis has two ways of generating URLs: one is to hardcode paths in the template, the other is to prepend the configured base url. Similarly, supporting all URLs could be seen as fundamentally simpler than supporting only some URLs—fewer `if` statements at the least, which means fewer tests required and less to think about when changing. I would note that if Atlantis *did* error out if the base URL had a path, then I wouldn’t have been able to get my Atlantis deployment set up today. It probably would have added another week or two of calendar time to work around the issue. Possibly more (I’m a manager and don’t get a heap of contiguous hours).

…

On Tue, 7 Aug 2018 at 20:36, Luke Kysow ***@***.***> wrote: Hi Jonathan, sorry about that, I hadn't thought of using the --atlantis-url flag to also specify a base path. I'm curious what your use-case is? Why do you need to host it at a non-root URL? I'm wary of supporting a different base path simply because it adds complexity. I know it doesn't seem like much but I want to keep Atlantis as simple as possible so I can make changes quickly. Either way, currently Atlantis should error out if a path is used in --atlantis-url. I've created #214 <#214> to track that. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#213 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHq6uVYxt9ymTysjXWC5rRWB0hkpC_sks5uOewggaJpZM4VygLN> .

[jml]

A potential future use case for us: We’re currently running Atlantis on a repo that does corporate IAM—managing GitHub and GSuite teams, more or less. If this works out, we probably also want to use Atlantis for managing our AWS infrastructure. Current plan is to run a separate Atlantis for that, as it will need more AWS privileges and fewer GitHub privileges. Keeping them separate makes things a bit clearer and gives me a warm fuzzy security feeling.

…

On Tue, 7 Aug 2018 at 21:20, Jonathan Lange ***@***.***> wrote: No worries. I’m still super pleased that I didn’t have to write Atlantis myself. I’m running it inside a Kubernetes cluster which has an authenticating proxy in front of it, and routes to services based on url path. We aren’t going to register a new subdomain and introduce a new way of routing for our Atlantis deployment. I totally get where you’re coming from about being ruthless with new complexity. However, may I suggest that prepending the base URL reduces complexity? Currently, Atlantis has two ways of generating URLs: one is to hardcode paths in the template, the other is to prepend the configured base url. Similarly, supporting all URLs could be seen as fundamentally simpler than supporting only some URLs—fewer `if` statements at the least, which means fewer tests required and less to think about when changing. I would note that if Atlantis *did* error out if the base URL had a path, then I wouldn’t have been able to get my Atlantis deployment set up today. It probably would have added another week or two of calendar time to work around the issue. Possibly more (I’m a manager and don’t get a heap of contiguous hours). On Tue, 7 Aug 2018 at 20:36, Luke Kysow ***@***.***> wrote: > Hi Jonathan, sorry about that, I hadn't thought of using the > --atlantis-url flag to also specify a base path. > > I'm curious what your use-case is? Why do you need to host it at a > non-root URL? > > I'm wary of supporting a different base path simply because it adds > complexity. I know it doesn't seem like much but I want to keep Atlantis as > simple as possible so I can make changes quickly. > > Either way, currently Atlantis should error out if a path is used in > --atlantis-url. I've created #214 > <#214> to track that. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#213 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAHq6uVYxt9ymTysjXWC5rRWB0hkpC_sks5uOewggaJpZM4VygLN> > . >

[lkysow]

Okay so after thinking about this further, I'm happy to take a PR that will change the assets to use the base url's path because I know how setting up subdomains + ssl can be difficult.

I don't think in the long-term that this will be a supported feature however. If I look at a lot of hosted applications out there like consul, gitlab, circleci, they don't support a prefix base path. I'm guessing mostly for complexity issues and documentation issues.