SuiteCRM-Core
SuiteCRM-Core copied to clipboard
/api/graphql 403 forbidden, SuiteCRM 8.3.1 and 8.4.0 (installed in subfolder /suitecrm)
Issue
Fresh install of SuiteCRM 8.3.1 and/or SuiteCRM 8.4.0 gives "403 forbidden" on a /api/graphql (POST) request.
I've used the cli console to install.
Expected Behavior
I expected the application to actually work :wink:
Actual Behavior
"403 forbidden" on a /api/graphql (POST) request.
Looking at the request headers in the browser console, I can see a X-XSRF-TOKEN
header and cookie being passed.
Context
I'm trying to run SuiteCRM 8.3.1 and/or SuiteCRM 8.4.0 from http://127.0.0.1/suitecrm
I think this is reasonably high priority. I've seen quite a few community posts on this and/or something very similar.
Your Environment
- SuiteCRM Version used: 8.3.1 and 8.4.0
- SuiteCRM is installed on http://127.0.0.1/suitecrm on my local machine
- I get the same behavior regardless of browser
- I've re-created the database on each attempt
- Apache, MariaDB, PHP 7.4 FPM (I have also tried using PHP 8.1 FPM)
- Ubuntu 22.04.LTS
Apache configuration block
<VirtualHost 127.0.0.1:80>
ServerName localhost
ServerAdmin webmaster@localhost
DocumentRoot /var/www/empty
LogLevel debug
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Alias /suitecrm /var/www/suitecrm/public
<Directory /var/www/suitecrm/public>
AllowOverride all
Order allow,deny
Allow from all
Require all granted
DirectoryIndex index.php index.html index.htm
<FilesMatch \.php$>
SetHandler proxy:fcgi://127.0.0.1:8001
</FilesMatch>
</Directory>
RemoveHandler .php
RemoveHandler .php5
</VirtualHost>
The RewriteBase
directive in /var/www/suitecrm/public/legacy/.htaccess
is /suitecrm/legacy/
(created by the installer). I have tried altering this to everything I can think of, but nothing I try seems to help.
I have also set it up as suitecrm.local
(with an entry in my hosts file to 127.0.0.2
) to see if it would work if I removed the subfolder component of my installation, but it fails with the exact same error. The installer has then create the .htaccess
file in the legacy folder with /legacy/
as the RewriteBase
.
Here's something of interest, I think.
I always configure all PHP pools with a different session.name
setting. It seems like SuiteCRM's code assumes it's PHPSESSID
in various places. If I change my session.name
setting back to the default session.name = PHPSESSID
, then things start working a lot better :thinking:
We experienced something similar when upgrading Suitecrm from 8.2.4 to 8.4 and php version 7.4 to 8.2.
When trying to display the opportunities list, the graphql would complain about CSRF token, but we could see it was set and working on other list views.
After further investigation we found an error message in our apache log, complaining about memory issues. The php.ini had a limit at 128mb. When raising the limit, the issue was resolved.
Hope it helps!
Found this issue with a 8.4 fresh install, and also before when upgrading from a 7.4 to a 8.4.
Maybe the problem is in my Apache setup but it seems that the CSRF token is submitted from the browser in a cookie, but not in a request header as expected by SuiteCRM.
So, I have configured Apache to copy the token from the cookie in the header.
SetEnvIf Cookie "(^|;\ *)XSRF-TOKEN=([^;\ ]+)" MyCookieValue=$2
RequestHeader set X-XSRF-TOKEN "%{MyCookieValue}e"
` And this workaround worked for me.
@carlitros900 where excactly did you place these commands?
@TwizzX17 I've increased to 256 as well - but without any improvement.
@joho1968 I'm using the standard session config, but still the same problem.
Any other ideas on what to do here?
I don't really know what got it working, but 8.4.0 is working here now with PHP 8.1.23 on Ubuntu 22.04.LTS.
I have my DocumentRoot set to /var/www/suitecrm/public_html/public
, i.e. the public
folder of SuiteCRM.
The .htaccess
file in the legacy
subfolder has this: RewriteBase /legacy/
@joho1968 Yes, same setup here - .htaccess is standard then. Still, if I open URL/api/graphql I get the 403.
Any other ideas what you've changed from the standard? Did you add any redirect rules? How do you work with the API? Just open it in the browser or do you use PHP / Python or anything? Do you first have to authenticate to retrieve the token? Where is this endpoint and what are the parameters to authenticate? (Sorry for all the questions - this is just frustratring without documentation from SalesAgility)
I don't think I've changed anything else. Maybe with the exception of PHP's session handling. I saw that a lot of session files were created, so I installed Redis and configured PHP-FPM like so:
[suitecrm.conf]
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp
clear_env = yes
php_admin_value[session.save_handler] = redis
php_admin_value[session.save_path] = "tcp://127.0.0.1:6379"
php_admin_value[sys_temp_dir_string] = "/tmp"
[php.ini]
redis.session.locking_enabled=1
redis.session.lock_retries=-1
redis.session.lock_wait_time=10000
[Apache suitecrm.conf]
<IfModule setenvif_module>
SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
</IfModule>
I'm not using the API. SuiteCRM ran into the issue itself while calling the API. So no external code was part of my problem, only SuiteCRM's internal code.
@Chris8080 Is in the virtual host in the apache configuración. Also ha e found the non standard session name issue
The internal SuiteCRM code works fine for me. Settings are all more or less standard as well (including PHP sessions). LAMP stack, fresh VPS, nothing special so far. My problem is just the GraphQL API.