Selfhosted

60320 readers

497 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:

Detailed Rules Post

Be civil.
No spam.
Posts are to be related to self-hosting.
Don't duplicate the full text of your blog or readme if you're providing a link.
Submission headline should match the article title.
No trolling.
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details.

Resources:

selfh.st Newsletter and index of selfhosted software and apps
awesome-selfhosted software
awesome-sysadmin resources
Self-Hosted Podcast from Jupiter Broadcasting

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

Questions? DM the mods!

founded 3 years ago

MODERATORS

curbstickle@anarchist.nexus

curbstickle_lw@lemmy.world

Help fixing invalid origin with memos (self.selfhosted)

submitted 1 year ago* (last edited 1 year ago) by Thoven to c/selfhosted@lemmy.world

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

[–] catloaf@lemm.ee 0 points 1 year 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.

[–] silenium_dev@feddit.org 1 points 1 year ago* (last edited 1 year 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.

[–] catloaf@lemm.ee 2 points 1 year ago

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

[–] Thoven 0 points 1 year 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.