Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

serverURL with a base path does not work #24

Closed
joshhills opened this issue Jan 24, 2021 · 8 comments
Closed

serverURL with a base path does not work #24

joshhills opened this issue Jan 24, 2021 · 8 comments

Comments

@joshhills
Copy link

joshhills commented Jan 24, 2021

Bug Report

Setting the server URL to something with a path such as

http://localhost:3000/cms

Does not appear to work, despite printing:

[02:31:35] INFO (payload): Payload Admin URL: http://localhost:3000/cms/admin

Expected Behavior

You should be able to access the admin panel at the URL that is printed

Current Behavior

The route binding does not appear to factor in sub paths

Possible Solution

Use the provided serverURL when configuring express bindings in index.js

Steps to Reproduce

  1. Set the serverURL to http://localhost:3000/foo
  2. Observe that the log prints the admin URL as http://localhost:3000/foo/admin
  3. Observe that opening your browser to that page shows a broken looking "loading" message indefinitely

Detailed Description

I am trying to do this because I have multiple containerized applications running in my environment - e.g.

https://staging.mysite.com
 - port 3000 -> payload
 - port 7017 -> mongodb
 - port 3001 -> my-website-using-payload

Ideally, the front-end site will exist at the / root and the CMS will exist at /cms (akin to Wordpress)

@joshhills joshhills added the bug label Jan 24, 2021
@joshhills
Copy link
Author

Upon further investigation it appears that the issue may lie with the API URL, as the page at e.g. /foo/admin attempts to hit http://localhost:3000/api/users/me as opposed to http://localhost:3000/foo/api/users/me

@jmikrut
Copy link
Member

jmikrut commented Jan 24, 2021

Hey @joshhills!

This is actually not intended functionality, and there may be a way to do exactly what you’re looking to do with current functionality.

Can you try setting your routes.admin to /cms/admin and just leave your serverURL equal to http://localhost:3000?

If this works for your needs, we will make sure to update the docs accordingly!

@joshhills
Copy link
Author

joshhills commented Jan 24, 2021

Thanks for the quick reply! I think the info log message could be considered a bug given it ultimately points to a URL that doesn't work - perhaps an extra line in the docs section for hosting at a sub-path?

I gave that a whirl and it worked. Do you know if there are other paths that need adjusting to ensure that no resources get hosted at the root? I can see options for API etc. in the routes block, but I also see a paths object used as part of the file upload mechanism (?) further down in the configuration? Ideally I need to find a way to scope every Payload resource (CSS/JS, routes...) to foo so that it doesn't fight with the other apps

@jmikrut
Copy link
Member

jmikrut commented Jan 24, 2021

Totally. IMO we really just need to enforce that the serverURL itself does not contain a path - only protocol, domain, port. That would then solve the info log. Well, that and some improved docs of course. Thoughts?

The only routes that get mounted by Payload are the ones that you can customize through the routes config property. Everything that Payload does Express-wise will be scoped accordingly so nothing outside of those routes will compete with your apps whatsoever. Including all statically served CSS, JS, etc. required by the admin panel.

The paths property is actually no longer used and is left over in the config type. We will remove that - good eye!

@joshhills
Copy link
Author

Yes, I think to be pedantic, "URL" can typically contain a path, so either a comment or splitting it into those individual fields (though that might be more boilerplate) should suffice. Support for a basePath to automatically pre-pend the routes fields might be a good feature request if others also run into the same issue? Additionally, showing the default URLs in one place might be useful - I had to skip between docs pages to grab them all - unless I'm missing something.

RE other routes - good to know! From reading the docs on uploads, I gather that I can ensure that media uploads are scoped accordingly by making the staticURL and staticDir also contain /foo in some way. I think it's very elegant that it's suggested that media be its own collection type (though you might want to include that in the npx setup alongside TODOs, I imagine it'll be necessary for most projects?).

I'll try setting them all, creating a collection with file uploads, and close with a final comment when it works?

@jmikrut
Copy link
Member

jmikrut commented Jan 24, 2021

Good point regarding pedantics. We will keep an eye out for further requests and should be able to facilitate basePath support in one way or another if it’s important to the community.

I say we keep this issue open until we can do the following:

  • remove paths from config type
  • update docs to be more explicit about the above
  • enforce that serverURL does not contain a path

We can take a stab at that stuff tomorrow!

@jmikrut
Copy link
Member

jmikrut commented Jan 24, 2021

Closed with #28 .

@jmikrut jmikrut closed this as completed Jan 24, 2021
jacobsfletch added a commit to jacobsfletch/payload that referenced this issue Oct 15, 2023
jacobsfletch added a commit to jacobsfletch/payload that referenced this issue Oct 15, 2023
denolfe pushed a commit that referenced this issue Oct 24, 2023
Copy link

github-actions bot commented Sep 8, 2024

This issue has been automatically locked.
Please open a new issue if this issue persists with any additional detail.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 8, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants