I have tried it with Joplin Server 1.75 and the beta 2.05 but i get the same result
when i attempt to login i get
no matter what i try its the same result
I am using a postgres db
Any help would be appreciated
I have tried it with Joplin Server 1.75 and the beta 2.05 but i get the same result
when i attempt to login i get
no matter what i try its the same result
I am using a postgres db
Any help would be appreciated
All tests were fresh installs, no residual data.
Using docker
Got the same error on Server 2.0.5 when the server listened behind a reverse proxy, but the domain the server was listening on was not the domain specified in the Docker's env vars.
Maybe check you have all those set correctly.
I have been using the Joplin server docker image behind an nginx reverse proxy. The last version I got to work was, 2.0.1 beta (using the SQLite db). I also had to use florider's version as the official one always started with data already in the admin account and an additional "user1" account. Even after a complete new, clean ubuntu / docker install!!
I then moved onto the later 2.x series using the same .env file and I always got "Invalid origin" regardless of the version. This suggests that the proxy and the Joplin server are not on speaking terms. If I reverted to the 2.0.1 version of the server it worked again. I am not a fan of the Docker concept and so it is currently a bit of a dark art to me and is likely to remain so. I didn't have the knowledge to troubleshoot the issue so I gave up.
Not exactly helpful but just to let you know that you are not the only one who has come across this... assuming it's the same problem
Yes sorry this is not currently documented, but you need to make sure that your reverse proxy passes the origin properly to the Docker image.
I think it means having this on the Nginx config:
proxy_set_header host $host;
And this on Apache:
ProxyPreserveHost on
Yep, that's it for nginx.
In case it helps anyone, this works for me:
server {
server_name joplin.example.lol;
location / {
proxy_pass http://127.0.0.1:31337;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Host $host;
client_max_body_size 400M;
}
}
I'm not saying all of those are needed, mind: I just set them by default to avoid trouble.
edit: you may need to add Listen directive for ports. I just let certbot deal with it (and redirect to https.)
Thanks for sharing your config, the "client_max_body_size" property is important too. I guess once the server gets more stable we can put a sample Nginx and Apache config in the doc.
That we definitely should. It's always a hassle to figure out/troubleshoot when projects don't do that.
(Server now working )
In case anyone is interested this is an nginx "sites-available" reverse-proxy file that uses self-signed certs, diverts port 80 to 443, adds a bit of hardening and also logging. It does work with 2.0.6-beta.
{
listen 80;
server_name joplin.example.lol;
return 301 https://joplin.example.lol$request_uri;
}
server {
listen 443 ssl http2;
server_name joplin.example.lol;
proxy_read_timeout 720s;
proxy_connect_timeout 720s;
proxy_send_timeout 720s;
client_max_body_size 50m;
# Proxy headers
proxy_set_header X-Forwarded-Host $host;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
# SSL parameters
ssl_certificate /path/to/certs/joplin.example.lol-cert.pem;
ssl_certificate_key /path/to/certs/joplin.example.lol-key.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA HIGH !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";
# log files
access_log /var/log/nginx/joplin.example.lol.access.log;
error_log /var/log/nginx/joplin.example.lol.error.log;
# Handle / requests and redirect to a specific port on localhost
location / {
proxy_redirect off;
proxy_pass http://127.0.0.1:22300;
}
}
Replace joplin.example.lol
with your domain and /path/to/certs/example.lol-cert.pem
and /path/to/certs/example.lol-key.pem
with the real thing.
Then, with the real thing, sudo ln -s /etc/nginx/sites-available/joplin.example.lol.conf /etc/nginx/sites-enabled/joplin.example.lol.conf
I got to this by butchering other examples, I am not an nginx expert.
I'm kind of screwed, I'm using IIS 8 Url Rewrite
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<httpRuntime requestPathInvalidCharacters="" />
<pages validateRequest="false" />
</system.web>
<system.webServer>
<rewrite>
<rules>
<rule name="ReverseProxyInboundRule1" stopProcessing="true">
<match url="(.*)" />
<action type="Rewrite" url="http://10.2.0.140:22300/{R:1}" />
<serverVariables>
<set name="HTTP_X_ORIGINAL_ACCEPT_ENCODING" value="HTTP_ACCEPT_ENCODING" />
</serverVariables>
</rule>
</rules>
<outboundRules>
<rule name="fix" preCondition="NeedsRestoringAcceptEncoding">
<match serverVariable="HTTP_ACCEPT_ENCODING" pattern="^(.*)" />
<action type="Rewrite" value="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" />
</rule>
<preConditions>
<preCondition name="NeedsRestoringAcceptEncoding">
<add input="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" pattern=".+" />
</preCondition>
</preConditions>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>
I'm getting the same result
I have the variable APP_BASE_URL set to the url of the reverse proxy
I found a solution for us forced IIS users, you need to turn preserve host header on (Its off by default)
C:\Windows\system32\inetsrv\appcmd.exe set config -section:system.webServer/proxy -preserveHostHeader:true /commit:apphost
In a future version I'll probably remove this Origin check as it's only useful when there are different domains for main website, API, and user content. But when self-hosting you don't really need this.
I would really appreciate that - I currently have two setups (with and without proxy, which I use for note re-sync when necessary) and currently it means I have to stop the server and reconfigure APP_BASE_URL variable. Or make it an optional check that could be disabled.
I would also highly appreciate removing the origin check or to add the possibility of a whitelist.
In my case the nginx proxy is served/configured by Opnsense which is unfortunatly not able to add the host header (at least not without doing some additional manual config operations).
So currently I have to stick to 2.0.1-beta version
Hello all - I’m trying to migrate to the newest joplin server. I’m an embedded developer, so I suck at web stuff. What I’ve tried thus far:
I’ve stood up a new digital ocean ubuntu 20.04 instance, installed nginx, and setup a reverse proxy (successfully, I believe). I then attempted to perform the fix suggested by @laurent, but I am still getting the “Invalid origin” error. Below are my configuration files:
joplin-server .env file
# Example of local config, for development:
#
JOPLIN_BASE_URL=http://localhost:22300
JOPLIN_PORT=22300
# Example of config for production:
#
# JOPLIN_BASE_URL=https://example.com/joplin
# JOPLIN_PORT=22300
nginx reverse proxy config file:
cat /etc/nginx/sites-available/reverse-proxy.conf
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://localhost:22300;
proxy_set_header Host $host;
}
}
Don’t trash my configuration too hard I’m learning web stuff
Hello again everybody - I managed to get everything working, based on this guide in another thread. I also found that the latest desktop version of 2.1.7 only plays nice with the latest beta of joplin server (2.1.6-beta) according to this post. You can change which version of joplin server docker pulls down by changing the "latest" tag in the docker-compose.yml file to "2.1.6-beta". Current versions of apps/server playing happy together below:
Joplin Server: 2.1.6-beta
Android: 2.1.3
Windows Desktop: 2.1.7
iOS (ipad OS on iPad Pro 2020): 12.0.2
Ubuntu 2020.04: 2.1.7
Thanks all, and let me know if I can help.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.