Edit report at https://bugs.php.net/bug.php?id=80291&edit=1
ID: 80291
Updated by: requinix@php.net
Reported by: jozyah-etienne at eerees dot com
Summary: Data corruption and data loss in default session
handler (All PHP versions)
Status: Open
Type: Bug
Package: Session related
PHP Version: Next Major Version
-Block user comment: No
+Block user comment: Yes
Private report: N
New Comment:
This is a completely reasonable request.
Previous Comments:
------------------------------------------------------------------------
[2020-10-30 04:11:28] rtrtrtrtrt at dfdfdfdf dot dfd
> Who knows how many times people lost their session because of this bug?
get some relieable hardware and until then you have bigger problems!
how did the wordl survive writeback-storage until you came?
------------------------------------------------------------------------
[2020-10-30 01:06:44] jozyah-etienne at eerees dot com
> You can create a custom session save handler for such purposes.
Also custom session handlers doesn't work with some PHP features and makes more problems -
I'm looking at you, session.upload_progress.enabled INI option :D
------------------------------------------------------------------------
[2020-10-30 00:57:09] jozyah-etienne at eerees dot com
> Why? Is there a standard somewhere?
When the docs advertise session write operation without any warning that data may gets lost, it
means that it is reliable, while it's clearly not. I don't know about any standard out
there.
> Not worrying about user data and not worrying about an issue that might never happen is
> different. And the issue we are talking about is a user having to re-connect. (if your code is
> correctly designed, it's the only thing that should happen).
I tried to manipulate session files and it seems that PHP silently clears $_SESSION data in case of
data corruption. That's a relief because user session automatically restarts and the user just
logouts and there will be no issues in re-login at all.
But some data is gets lost without any sysadmin/programmer gets noticed about because PHP
doesn't trigger any errors at all. Maybe that's why nobody is worried about this issue yet
and this issue seems so unrealistic to happen. Who knows how many times people lost their session
because of this bug? Who spends time to report a unwanted logout to website owners? (And believe me,
I had a lot of unwanted logouts in different sites in the past and nobody including I myself and
site owners knows how many of those was because of this bug. I never reported those issues and just
signed in again. Maybe that situation happened to you too?)
> You can create a custom session save handler for such purposes.
We do that for years, but it needs a lot of knowledge to write a good session handler to save data
in files. We currently are using DBMS for convenience, but It takes a lot of time to connect and
read and save transactions compared to PHP's original files handler. (I've explained our
situation in the Stack Overflow page that is linked in the original post above). Anyway, I believe
the only issue with modern default session handler is atomic writes and not notifying in case of
data corruption. So why not just fix it and put the problem on programmers shoulder? And how many of
us knows enough to write a perfect session handler (Years ago I spent one whole week to write our
own session handler and I mess a lot at that time while developing it, and at the end we decided to
use DBMS with transactions. It is a tricky topic and people will make more problems with rolling out
their own session handler, I believe).
> This is not a bug, and should not be an option.
But to some people like us who worry about our data and our users' experience, it clearly is.
Specially that PHP silently ignores data corrupted session files and doesn't log it at all, so
nobody knows how often this issue had happened in the past.
> However I agree that the docs could use a small paragraph about the session_writes not being
> atomic and thus data should not be saved only in session (but again, that should already be the case
> even without worrying about session writes atomicity).
I believe if this issue isn't going to get fixed for good, not only docs should mention it, but
also at least a NOTICE level error must be triggered so people can get notified about it when it
happens. Also a reliable way to avoid such conditions should be introduced for those who care, like
what I suggested in my last comment (I personally prefer session.atomic_writes with PHP_INI_ALL mode
because not only both sysadmin and programmers can change it, but also works when
session_write_close_atomic() is not called and so PHP automatically tries to save the session at the
end of execution).
------------------------------------------------------------------------
[2020-10-29 18:38:41] xx_pulse_xx at idkwhatiamdoing dot com
> Session's write operation should be atomic.
Why? Is there a standard somewhere?
Sessions are designed to store data related to the current session, the issues you raise in this bug
reports and the comment tend to show unreliable patterns in your code.
Not worrying about user data and not worrying about an issue that might never happen is different.
And the issue we are talking about is a user having to re-connect. (if your code is correctly
designed, it's the only thing that should happen).
This is not a bug, and should not be an option. You can create a custom session save handler for
such purposes. However I agree that the docs could use a small paragraph about the session_writes
not being atomic and thus data should not be saved only in session (but again, that should already
be the case even without worrying about session writes atomicity).
------------------------------------------------------------------------
[2020-10-29 09:33:05] rtrtrtrtrt at dfdfdfdf dot dfd
> And if a very very negligible overhead is so problematic
> to you that you want to risk your users' data
yes because "in case of failure (power outage, disk failure, crash, connection loss to a
networked storage" don't happen in the real world
* each server has two power supplies
* each power supply is on a different UPS
* disk failures don't matter on redundant arrays
* my servers don't crash
* my storags don't lose connections - redundancy is the keyword
again: your issue don't exist in ten real world and you should fix the root cause
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=80291
--
Edit this bug report at https://bugs.php.net/bug.php?id=80291&edit=1