I created a new Ghost installation on Debian 9 and MySQL. After running ghost install, I navigate to my site, attempt to create an account and keep getting
Authorization failed Unable to determine the authenticated user or integration. Check that cookies are being passed through if using session authentication.
What version of Ghost are you using?
CLI: 1.11.0
Ghost: 2.32.0
{
"url": "https://example.com",
"server": {
"port": 2368,
"host": "127.0.0.1"
},
"database": {
"client": "mysql",
"connection": {
"host": "localhost",
"user": "ghost_user",
"password": "pass",
"database": "ghost_db"
}
},
"mail": {
"transport": "Direct"
},
"logging": {
"transports": [
"file",
"stdout"
]
},
"process": "systemd",
"paths": {
"contentPath": "/var/www/example.com/html/content"
},
"bootstrap-socket": {
"port": 8000,
"host": "localhost"
}
}
What errors or information do you see in the console?
When attempting to create an account I see:
Authorization failed Unable to determine the authenticated user or integration. Check that cookies are being passed through if using session authentication.
I’m also having this issue which may or may not be related:
opened 12:57AM - 08 Oct 19 UTC
closed 10:07AM - 08 Oct 19 UTC
### Issue Summary
Upon installing Ghost v2.32.0 with a fresh MySQL installati… on I get
```
✖ Starting Ghost
A GhostError occurred.
Message: Field length of `customer_id` in `members_stripe_customers` is too long!
Help: Read more here: https://github.com/TryGhost/knex-migrator/issues/51
Suggestion: journalctl -u ghost_example-com -n 50
Debug Information:
OS: Debian, v9.11
Node Version: v10.16.3
Ghost-CLI Version: 1.11.0
Environment: production
Command: 'ghost install'
Additional log info available in: /home/admin/.ghost/logs/ghost-cli-debug-2019-10-08T00_54_45_189Z.log
Try running ghost doctor to check your system for known issues.
You can always refer to https://docs.ghost.org/api/ghost-cli/ for troubleshooting
```
### DB Character Set
```
#
# * Character sets
#
# MySQL/MariaDB default is Latin1, but in Debian we rather default to the full
# utf8 4-byte character set. See also client.cnf
#
character-set-server = utf8
collation-server = utf8_general_ci
```
Kevin
October 8, 2019, 8:55am
4
ghost_throw:
[2019-10-07 21:20:13] INFO “POST /ghost/api/canary/admin/authentication/setup/” 201 234ms
Those lines show that the setup and login completed ok on the server-side. Judging from the later error message it sounds like something is stopping the cookie that is set on the successful login request from being saved or included with later requests.
Have you tried using Incognito mode in Chrome or a different browser without any browser extensions? Is there anything else you may have in your setup that would block cookies?
@Kevin I’ve tried different browsers with the same result.
As far as I’m aware, nothing should be blocking cookies. The only thing that I’ve done that might possibly be a problem was uninstall/reinstall Ghost with the CLI commands.
Is there any other logs somewhere that might help point to a solution? Could it be an issue with my Firewall maybe?
Kevin
October 8, 2019, 12:50pm
6
There may be some logs in your browser’s dev tools, you could also inspect the network requests to make sure that the browser is receiving the Set-Cookie header on the POST /ghost/api/canary/admin/session request and double-check that the Cookie header is being sent on the GET /ghost/api/canary/admin/settings/?type=blog%2Ctheme%2Cprivate%2Cmembers request.
Could it be an issue with my Firewall maybe?
Possibly, if the firewall is interfering with request headers then it may cause problems.
I’m just now realizing it might be an issue with my Nginx config
proxy_cache_path /var/run/cache levels=1:2 keys_zone=STATIC:75m inactive=24h max_size=512m;
server {
server_name example.com www.example.com;
add_header X-Cache $upstream_cache_status;
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
location / {
try_files _ @ghost;
}
location /content/images {
alias /var/www/example.com/html/versions/2.31.1/content;
access_log off;
expires max;
try_files $uri @ghost;
}
location /assets {
alias /var/www/example.com/html/versions/2.31.1/content/themes/casper/assets;
access_log off;
expires max;
try_files $uri @ghost;
}
location @ghost {
proxy_cache STATIC;
proxy_cache_valid 200 30m;
proxy_cache_valid 404 1m;
proxy_ignore_headers X-Accel-Expires Expires Cache-Control;
proxy_ignore_headers Set-Cookie;
proxy_hide_header Set-Cookie;
proxy_hide_header X-powered-by;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
expires 10m;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://127.0.0.1:2368;
}
}
server {
if ($host = www.example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 404; # managed by Certbot
}
proxy_ignore_headers Set-Cookie;
proxy_hide_header Set-Cookie;
Gonna try removing them tonight. I got the idea for this config from this post:
gistfile1.md
Full blog post can be found here: http://pnommensen.com/2014/09/07/high-performance-ghost-configuration-with-nginx/
Ghost is an open source platform for blogging founded by John O'Nolan and Hannah Wolfe. It's a node.js application and therefore works great in conjunction with nginx. This guide will will help you create a high performance nginx virtual host configuration for Ghost.
<blockquote class="twitter-tweet" lang="en"><p>"Don't use <a href="https://twitter.com/hashtag/nodejs?src=hash">#nodejs</a> for static content" - <a href="https://twitter.com/trevnorris">@trevnorris</a>. If <a href="https://twitter.com/hashtag/nginx?src=hash">#nginx</a> isn't sitting in front of your node server, you're probably doing it wrong.</p>— Bryan Hughes (@nebrius) <a href="https://twitter.com/nebrius/statuses/505543249969176576">August 30, 2014</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
The node.js application runs on a port on your server. We can configure nginx to proxy to this port and also cache so that we don't need to rely on express, the default node web application framework.
To start we need to tell nginx what port Ghost is running on. Define an upstream in your domains virtual host configuration file. show original
Kevin
October 8, 2019, 7:46pm
8
@ghost_throw that caching setup is quite heavy, you’ll definitely see problems (even after removing the cookie header rules) unless you exclude the /ghost/* paths so that admin API requests are not cached.
@Kevin You’re talking about the location blocks? As far as I can tell, they’re necessary to prevent 404ing for assets and images.
Is there a recommended Nginx config for caching?
Here’s my latest Nginx config. I excluded the Admin panel from being cached:
proxy_cache_path /var/run/cache levels=1:2 keys_zone=STATIC:75m inactive=24h max_size=512m;
server {
server_name example.com www.example.com;
add_header X-Cache $upstream_cache_status;
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
location / {
try_files _ @ghost;
}
location /content/images {
alias /var/www/example.com/html/versions/2.33.0/content/images;
access_log off;
expires max;
try_files $uri @ghost;
}
location /assets {
alias /var/www/example.com/html/versions/2.33.0/content/themes/casper/assets;
access_log off;
expires max;
try_files $uri @ghost;
}
location ~ ^/(?:ghost|signout) {
add_header Cache-Control "no-cache, private, no-store, must-revalidate, max-stale=0, post-check=0, pre-check=0";
proxy_hide_header X-powered-by;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
expires 10m;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://127.0.0.1:2368;
}
location @ghost {
proxy_cache STATIC;
proxy_cache_valid 200 30m;
proxy_cache_valid 404 1m;
proxy_ignore_headers X-Accel-Expires Expires Cache-Control;
proxy_ignore_headers Set-Cookie;
proxy_hide_header Set-Cookie;
proxy_hide_header X-powered-by;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
expires 10m;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://127.0.0.1:2368;
}
}
server {
if ($host = www.example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 404; # managed by Certbot
}
jlmagee
November 29, 2019, 8:05pm
11
I get the below error going to setup with a fresh install. There are no cookies after navigating to /ghost/. There is no interference from proxies or firewalls. nginx is not configured, the firewall is stopped, and I’m on a VPN accessing ghost directly.
GET http://172.23.113.8:2368/ghost/api/v3/admin/users/me/?include=roles 403 (Forbidden)
Thanks for sharing. I don’t know much about this. You may refer any router login guide. It might be helpful to you. Looking for some more responses.
jlmagee
December 1, 2019, 1:19am
13
With no assistance from @westernira who, for some unknown reason, replied with a completely useless post, I’ve determined that this 403 error is not related to the cause of the problem getting into setup. The actual error was a “502 Bad Gateway” transitioning to the /ghost/ path with a POST to obtain the api key.
There are apparently a range of configuration issues that may cause this. In my case, i added disablereuse=On to the ProxyPass directive in the Apache reverse proxy configuration.
Hope this helps someone.
i just had this problem while trying to login /ghost:
Unable to determine the authenticated user or integration. Check that cookies are being passed through if using session authentication.
and I checked in my nginx configuration, and I found the cause:
# Force trailing slashes
if ($request_uri !~ "^/wp-json") {
rewrite ^([^.]*[^/])$ $1/ permanent;
}
I installed ghost in the subdirectory, while my root directory uses wordpress and I set up the forced configuration of the redirect.
after I remove the configuration I can login /ghost again.
