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

Setup with reverse proxy leads to some static GET to localhost:[port] instead of the root domain #286

Closed
thepra opened this issue Mar 21, 2020 · 3 comments

Comments

@thepra
Copy link

thepra commented Mar 21, 2020

Describe the bug

As in the title, after setting up the writefreely server from the guide I found that out of the gate some resource were still pointing to localhost as if they were hard setup, like:
image

Bug number 2 is that error appearing in the h.js which you should look up(from Firefox latest release).

Steps to reproduce (if necessary)

Steps to reproduce the behavior:

  1. Setup writefreely with reverse proxy
  2. Open the website
  3. Look at the console for errors

Expected behavior

What should've happened?
Right out of the box have pointing to static resources done right. And JS without error.

Application configuration

  • Single mode or Multi-user mode? Multi-user
  • Database? sqlite
  • Open registration? no
  • Federation enabled? yes

Version or last commit: 0.11.2

@thepra
Copy link
Author

thepra commented Mar 21, 2020

One solution could be that at the writefreely --config step there is also an option that asks if the writefreely server is going to be behind a reverse proxy, and if so, switch from pointers from localhost:[port] to blog.example.com

@thebaer
Copy link
Member

thebaer commented Mar 21, 2020

Thanks for bringing this up, @thepra. What is your host config value? If it's set to localhost and you intend this to be accessed outside the local machine, you'll want to instead set it to the public-facing URL (see config docs for more info). Based on your screenshots, it should probably be https://blog.[redacted-domain]

@thebaer
Copy link
Member

thebaer commented Mar 24, 2020

Closing for now. Please let us know if this turns out to be something other than a misconfiguration.

@thebaer thebaer closed this as completed Mar 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

2 participants