Calls to session-status return 403

I’m stumped. New install, v 8.8.1. PHP 8.3 cPanel on a VPS. No visible errors on install.

I’ve changed my session save-path to a local folder in php.ini and have verified that sessions have been created there. /public/legacy/config.php has session_dir set to an empty string. There’s no session_dir setting in config_override.php.

Using the default session ID, but it looks like SuiteCRM is overriding that, no problem.

I Set APP_ENV=qa.

After a cache clear, calls to session-status are returning a 403.
When not logged in the response is

{"active":false,"appStatus":{"installed":true,"locked":true}}

After login I get

{
  "appStatus": {
    "installed": true,
    "locked": true,
    "loginWizardCompleted": true
  },
  "active": true,
  "id": "1",
  "firstName": null,
  "lastName": "Administrator",
  "userName": "[redacted]",
  "redirect": {
    "route": "users\/Wizard",
    "queryParams": null
  }
}

I get the feeling I’ve missed something simple here, but I’m out of ideas.

Nuts. Looks like it’s time to find another solution.

Hello,

could you turn the whole thing around?
First, you’d install Suite on a fresh / vanilla / standard LAMP system without any special settings.
There, it usually runs without any issues.

Afterwards, you’d start changing things on the server setup and see how / what affects the CRM in what way.

The installation sometimes works smoothly but there are some corners in the CRM which don’t. The installation doesn’t test everything that might be utilized later on the day to day work in the CRM.
The installation pre-check is a good first indicator though.

Thanks for your reply, BastianHammer.

Yes, that’s where I’m at. I’ll do a local install, see if that works. If I get the same result (which I think is unlikely) I’ll fire up PHPStorm and debug it. Otherwise I’ll add in some diagnostics and upload that version to the remote system until I can understand where it’s going wrong. Sadly I can’t run xdebug in the remote configuration.

I was just hoping there was a “oh, that’s because of” solution before going into developer mode.

I’d say, plenty of issues here come from “creative” server setups.
I haven’t seen what you’re describing, so unfortunately, I can’t point out sth. specifics.

You’re approach however sounds good with the local / standard system.

As the most popular hosting control panel, cPanel is one place where I’d expect it to “just work.” That said, cPanel has a lot of configuration options, and some hosts manage to do weird things. The pre-install test looks like it catches all of that though.

More than that, I’ve got two decades of experience running a hosting company with cPanel, thus I have a high degree of confidence it’s not a server configuration issue. This in part because I’m getting a “soft” 403 (generated by the application, not Apache). There’s a subtle little quirk somewhere that might be an interaction with the server environment, but I don’t expect it will be a “duh” like directory permissions or ownership. Then again, I’m not excluding anything at this point.

I’ll report back if/when I find the issue.

1 Like