Bug #80291 [Com]: Data corruption and data loss in default session handler (All PHP versions)

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: > 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). Previous Comments: ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ [2020-10-28 20:46:30] rtrtrtrtrt at dfdfdfdf dot dfd > It took less than 1 second to rename a file for 100,000 times in 1 second i spit out 20000-50000 dynamic pages nobody cares about session files, they are in tmpfs here for 20 years the worst case every few decades is that one needs to login again which is the same for every ordinary reboot in that setup > I'm saying, most programmers are using standard session > handler and they are not aware that data loss and data > corruption can happen it don't happen except for cases where you have *much larger* problems - period > It's all about how important your data is session data aren't unless you have way bigger problems and then they are not important ------------------------------------------------------------------------ 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