Skip to content

parse-server ignoring my public_html folder for static files, serves files shipped with parse-server #7204

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

Closed
mman opened this issue Feb 17, 2021 · 5 comments
Labels
state:wont-fix Won’t be fixed with a clearly stated reason type:bug Impaired feature or lacking behavior that is likely assumed

Comments

@mman
Copy link
Contributor

mman commented Feb 17, 2021

New Issue Checklist

Issue Description

I am trying to serve static files via top level public_html folder included along with my parse server, but my files are ignored.

Looking at the

const public_html = path.resolve(__dirname, '../../public_html');
and
router.use('/apps', express.static(public_html));
where the public_html static route is defined, the static files from public_html dir should be available under http://server:1337/parse/apps/ URL.

Debugging this actually revealed that

const public_html = path.resolve(__dirname, '../../public_html');
actually expands the public_html directory path to node_modules/parse-server/public_html and therefore serves the files shipped with the current version of the parse-server, not my files shipped along.

The same problem applies with the views directory.

Suggested Fix

Path to public_html and views should either be configurable the same way path the cloud code is using the cloud option here:

cloud: ?string;
or it should first try to lookup dir shipped alongside parse-server and only then fallback to node_modules/parse-server/public_html

Looks like some work has already progressed along these lines to deprecate the use of public_html and views in favor of the new PagesRouter so feel free to close this as will not fix. Filing for future developers that may be hit.

Environment

Server

  • Parse Server version: 4.5.0
@mtrezza
Copy link
Member

mtrezza commented Feb 17, 2021

Thanks for reporting.

This is expected - although not optimal - behavior when running Parse Server as a module. Feel free to provide a PR to fix this, ideally via a path parameter in the Parse Server options.

Alternatively feel free to enable the PagesRouter that allows you to specify the path and other options. The router is still experimental and is not officially released for use in production critical environments. I will say though that it has been tested extensively and is currently being used in production environments, just so you get a better sense of its maturity.

@mtrezza mtrezza added type:bug Impaired feature or lacking behavior that is likely assumed S3 labels Feb 17, 2021
@mtrezza
Copy link
Member

mtrezza commented Feb 17, 2021

I have classified this as bug with severity S3:

  • Workaround: Use PagesRouter or fork Parse Server and override path to public directory in PublicAPIRouter.js.
  • Fix: Introduce Parse Server option to manually set the path for the public directory.

@mman
Copy link
Contributor Author

mman commented Feb 17, 2021

Thank @mtrezza for classifying this. I will very probably go with the PagesRouter but wanted to have this documented.

@mtrezza
Copy link
Member

mtrezza commented Feb 17, 2021

Sure, please provide any feedback including possible optimizations for the PagesRouter.

The PagesRouter is currently in the docs under "Localization", that being its major feature, but it has other, localization-unrelated improvements as you can find in the related PR.

@mtrezza mtrezza added the state:wont-fix Won’t be fixed with a clearly stated reason label Mar 11, 2021
@mtrezza
Copy link
Member

mtrezza commented Mar 11, 2021

I am closing this as won't fix as the PagesRouter already provides a fix for this, albeit still in experimental status. Feel free to comment if you have any questions and we can re-open.

@mtrezza mtrezza closed this as completed Mar 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
state:wont-fix Won’t be fixed with a clearly stated reason type:bug Impaired feature or lacking behavior that is likely assumed
Projects
None yet
Development

No branches or pull requests

2 participants