Hello, I published a system developed in cake 4.4. When running the application on the server, I am having the following error message:
Cake\Http\Session::_overwrite(): Argument #1 ($old) must be of type array, null given, called in /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Http/Session.php on line 508
Has anyone had this problem, or can guide me on what I should do, or what it could be?
Iād look in the second entry in the sidebar which mentions APP/Controller/CartController.php:42
My guess is that this line is trying to $this->getRequest()->getSession()->write($var) where $var is null.
Actually no, it seems that your $_SESSION is not initialised.
Looking at Cakephp4 debug before write session - #9 by gludie try setting these Cookie Settings in your config/app_local.php
'Session' => [
'defaults' => 'php',
'ini' => [
'session.cookie_secure' => false
]
],
The strange thing is that in my LocalHost (Mamp) it is working perfectly. But when publishing on the production server (HostGator) it does not recognize the session in the application.
Another case, when logging in, returns this message. I donāt know if they both have the same relationship.
Unsuccessfully 
Follows the same problem
Is this the only error you are getting or are there other notices or warnings above that big debug_kit HTML output as well?
I mean something like:
These have to be fixed, otherwise the sessions logic wonāt work.
The main culprit in my case is the first Notice which I manually added to my AppController.php line 47
At first, the only one Iām having. Iāll forward the error.log of the application:
2023-03-08 09:32:49 warning: DebugKit is disabling itself as your host `www.mariosalviato.com.br` is not in the known safe list of top-level-domains (localhost, invalid, test, example, local). If you would like to force DebugKit on use the `DebugKit.forceEnable` Configure option.
2023-03-08 09:32:49 error: [TypeError] Cake\Http\Session::_overwrite(): Argument #1 ($old) must be of type array, null given, called in /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Http/Session.php on line 508 in /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Http/Session.php on line 555
Stack Trace:
- /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Http/Session.php:508
- /home1/marios35/public_html/novo/src/Controller/CartController.php:42
- /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Controller/Controller.php:229
- [internal]:??
- /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Controller/ControllerFactory.php:87
- /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Http/BaseApplication.php:318
- /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Http/Runner.php:86
- /home1/marios35/public_html/novo/vendor/cakephp/authentication/src/Middleware/AuthenticationMiddleware.php:124
- /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Http/Runner.php:82
- /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Http/Middleware/CsrfProtectionMiddleware.php:164
- /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Http/Runner.php:82
- /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Http/Middleware/BodyParserMiddleware.php:157
- /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Http/Runner.php:82
- /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Routing/Middleware/RoutingMiddleware.php:186
- /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Http/Runner.php:82
- /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Routing/Middleware/AssetMiddleware.php:68
- /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Http/Runner.php:82
- /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Error/Middleware/ErrorHandlerMiddleware.php:131
- /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Http/Runner.php:82
- /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Http/Runner.php:67
- /home1/marios35/public_html/novo/vendor/cakephp/cakephp/src/Http/Server.php:90
- /home1/marios35/public_html/novo/webroot/index.php:40
Request URL: /cart
Well yes, thats the problem.
If you want DebugKit to work in your www.mariosalviato.com.br then you must add
'DebugKit' => [
'safeTld' => ['br']
],
to your config/app_local.php
If you donāt want DebugKit on your Live website (which I would recommend) then disable debug mode on your live page.
I disabled debug mode and the warning no longer appears. But the error persistsā¦
This jĆ” estĆ” is a mystery 
. I contacted the Host support, but according to them the server settings are correct. I tested with PHP 8.1 and 8.2 but both have the same case.
Iām messing with Session.php, it really canāt start the session
The CSRF Token Problem can be fixed via adding the CSRF Token to your AJAX request.
In jQuery this looks like
$.ajax({
type: 'get',
dataType: 'json',
url: fetchUrl,
headers: {
'X-CSRF-Token': $('[name="_csrfToken"]').val(),
},
success(response, textStatus) {
// on success
},
error(jqXHR, textStatus, errorThrown) {
console.log(jqXHR);
console.log(errorThrown);
},
});
The function is stopping here. If I create $_SESSION = [ ] Outside the if (line) 334, the error stops but when creating a new session item (adding product to cart, gives error of āMissing or incorrect CSRF cookie type.ā)
Strange localhost this works and on the server it doesnāt
Any other suggestions of what it could be?
If that is the line where it bails out, then your application generates output before the session is being started.
If there are no additional errors/warnings (do not disable debugging), and it works on your local server, then either the files are not identical, or your local server has output buffering enabled (or a larger output buffer), so that it hides the problem.
Use headers_sent() to figure where the output is being generated if itās not obvious to you:
headers_sent($file, $line);
debug(compact('file', 'line'));
That was it!!! Indeed, on localhost output_buffering was active and on production it was not.
Disabling on localhost, the same problem happened.
Solution: I enabled it in production and my problem stopped happening and the system worked perfectly!!
Thank you so much guys!! Itās been more than a week breaking my head with this.
@ndm @KevinPfeifer 
Well, your problem is still there, itās just being hidden until possibly more of the same problem piles up and exceeds the buffer before headers are being sent.
Using output buffering to āsolveā this, isnāt advised, even if the PHP docs say that using output buffering to echo data before sending headers is a thing, IMHO you should always prefer figuring out where the early output is happening, and fix that instead if possible!