this post was submitted on 29 Mar 2025
14 points (93.8% liked)

Selfhosted

45658 readers
303 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
14
Help fixing invalid origin with memos (lemdro.id)
submitted 1 week ago* (last edited 1 week ago) by [email protected] to c/[email protected]
7 comments fedilink hide all child comments
 

Running joplin and memos in docker, routed through nginx. Since I don't own a domain I'm just using my public ip with ports and port forwarding. Joplin was throwing the same invalid origin error, but worked after I set APP_BASE_URL: http://<IP>:<port>. I tried setting SITE_URL=http://<IP>:<port2> under environment, which I've read is supposed to fix this exact problem. Same error. The error displays the correct address including port number, so I know that's being passed correctly. I've tried several different variations of the Host, Origin, and Referer header without success. Just for fun I tried directly exposing <port2> on the memos instance and it opened right up in the browser.

PS: Yes, I know I should be using https. I'm lazy. Setting up a cert is on the old todo list.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 0 points 1 week ago (2 children)

Stop exposing services like these to the Internet. If you need remote access, use a VPN.

You don't need to own a domain either. Use a free dynamic DNS provider.

And if you don't need remote access, don't bother with that at all. Just run a local DNS server with records for these services with anything under the .internal TLD. Or even just IP address.

HTTPS can come later. It's really not important for traffic that's not sensitive, like no passwords or whatever.

[–] [email protected] 0 points 1 week ago

Definitely need remote access, and tunneling in every time I want to sync my notes app is way too much work. I've containerized these services as a security layer and you need user creds to access anything without an exploit. I'm comfortable with that level of risk.

Dynamic DNS is a very cool thing I didn't know exists. I'll definitely look into it further! But for the time being I still need a fix for my problem.

[–] [email protected] 0 points 1 week ago* (last edited 1 week ago) (1 children)

There's no reason not to expose those services to the Internet, they have authentication, and noone can access them without logging in first. There are actually reasons for exposing them, you can share a memo or a file to other people. You should enable HTTPS though to prevent passwords being transferred in clear text.

[–] [email protected] 2 points 1 week ago

You assume there is no vulnerability in the web server itself, or a vulnerability that allows bypassing authentication.