Edit report at https://bugs.php.net/bug.php?id=80291&edit=1
ID: 80291
Comment by: jozyah-etienne at eerees dot com
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: N
Private report: N
New Comment:
> 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
Previous Comments:
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
[2020-10-29 02:50:33] jozyah-etienne at eerees dot com
If nobody here wants to have this very very negligible overhead in his/her websites, that's
fine. But docs should clearly mention this problem and also introduce a solid way to those who care
for their users data and experience and users' trust on site owners and programmers trust on
PHP as a tool.
There are 3 ways to solve the issue:
1. Fix the problem as a bug for all PHP websites out there.
2. Introduce a new function such as session_write_close_atomic() so programmers can decide.
3. Introduce a new boolean config in php.ini such as session.atomic_write so sysadmins can decide.
And please don't say that data is not important, they are, at least to those of us who care.
------------------------------------------------------------------------
[2020-10-29 02:44:43] jozyah-etienne at eerees dot com
> nobody cares about session files, they are in tmpfs here for 20 years
> session data aren't unless you have way bigger problems and then they are not important
Who says so? Are there any conventions out there that programmers agreed on? Are there any
notifications in docs saying so? NO!
> the worst case every few decades is that one needs to login again which is the same for every
> ordinary reboot in that setup
And he/she will lose all his/her session data because some unknown guy on internet said that a very
very negligible overhead worth much more than his/her session data!
I don't know about the default handler handler, but what if he/she can not logout? what if he
needs to clear the cookie from the browser by him/herself? What if there are hundreds of users that
lost their data and they all have problem logging out? How many hours the programmers need to
scratch their head to find the reason?
> it don't happen except for cases where you have *much larger* problems - period
And if a very very negligible overhead is so problematic to you that you want to risk your
users' data and their experience on trust on you, you have *much larger* problems too - period
------------------------------------------------------------------------
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