Bug #71088 [Opn->Fbk]: Session gets corrupted using custom session handler, unicode chars + 2 pg_conn

Edit report at https://bugs.php.net/bug.php?id=71088&edit=1 ID: 71088 Updated by: yohgaki@php.net Reported by: cdutary at grupocti dot com Summary: Session gets corrupted using custom session handler, unicode chars + 2 pg_conn -Status: Open +Status: Feedback Type: Bug Package: Session related Operating System: Windows 2008 PHP Version: 7.0.0 -Assigned To: +Assigned To: yohgaki Block user comment: N Private report: N New Comment: Your session save handler implementation has some problems. In order to lock and keep data consistency, PostgreSQL (and other database systems) should do followings in save handler. 1. It must use SERIALIZABLE transaction isolation level. Otherwise, you may end up with inconsistent session data. (PostgreSQL should not cause broken data without serializable transaction, though. It just may end up with inconsistent data like $_SESSION['access_counter']++, etc.) i.e. Start serializable transaction on read() and commit at write(). Use SELECT FOR UPDATE on read() to lock the accessing row also. 2. It must create new session data record (i.e. INSERT) in session read(), not in write(). Write() must UPDATE session data always. 3. It must return TRUE for successful operations always except read() which returns session data for success and gc() which returns number of deleted records. i.e. It should not return FALSE like public function open($savePath, $sessionName) { return (isset($this->nombre_de_sesion) && strlen($this->nombre_de_sesion) > 2) ? true : false; public function destroy($session_id) { return pg_affected_rows(pg_query($this->db, 'DELETE FROM "sesiones_soporte" WHERE session_id = ' . pg_escape_literal($session_id) . '')) ? true : false; Returning FALSE means "operation, that will never fail under normal circumstance, failed". For newly created session data, read() must return empty string. i.e. return ""; Without serializable transaction and lock, destroy()'s pg_affected_rows() may result in 0. This is not an error without serializable transaction and lock. destroy() must return TRUE in this case. 4. (Optional) It's better to use persistent connection for better performance and you don't have to close database connections. Note: Programmers must manage number of database connections anyway. Otherwise, apps may end up with random session open() (i.e. pg_connect()) error because PostgreSQL server rejects connection that exceeds max connections defined in postgresql.conf unlike Apache httpd. 5. (Optional, but strongly recommended) It should detect pg_query() errors directly. i.e. Do not use pg_query() result like if (pg_affected_rows(pg_query($this->db, 'UPDATE "sesiones_soporte" SET .... otherwise, you cannot tell what's wrong. e.g. Access to records that has been deleted by gc() already. This shouldn't happen with serializable transaction isolation level, though. Instead, process _all_ pg_query() errors directly and properly. Make sure return FALSE only when the database operation is failed. 6. (Irrelevant, but should be fixed) gc() takes "maximum of session life time in seconds". Calling gc() like $this->gc(time()) will do nothing. i.e. Remove $this->gc(time()) in open(). Session module calls gc() whenever it is needed. That said, it's strange that you seems to get corrupted database record. Could you fix save handler issues. If you still have this issue with proper save handler, please report contents of broken data. (I guess you don't have the record) It seems save handler and transaction isolation level problems are causing this to me. Previous Comments: ------------------------------------------------------------------------ [2015-12-11 13:13:21] mattw at epiphanycardio dot com We have experienced a very similar issue using php 5.6.x It appeared with 5.6.12, 5.6.11 was fine. We use mysql for the custom handler. I inserted debugging into the session handler and discovered an extra session_destroy is called implicitly by the session handler. I have turned off all explicit session_destroy() php function calls, yet a session_destroy is still being called. ------------------------------------------------------------------------ [2015-12-11 05:53:12] cdutary at grupocti dot com Description: ------------ PHP: VC14 x64 Thread Safe (2015-Dec-03 20:07:26) To reproduce this problem we need 3 elements: - A custom session handler using postgres - Unicode characters inside our session variable. - A seccond postgres connection made when the session has ben started. So what happends is: The session gets corrupt at the end of the script when these 3 elements are present, throwing: "PHP Warning: session_start(): Failed to decode session object. Session has been destroyed in some location at some line" when you reload the page. Reloading the page once more will give you: PHP Warning: pg_fetch_result(): Unable to jump to row 0 on PostgreSQL result index something in some path: If we take the seccond postgres connection OUT of the equation then session data will remain untouched. So just comment that line and watch the page reload and reload over time. Uncomment the seccond connection and it will crash. Test script: --------------- This code is about 50 lines and you shall download it from: https://grupocti.com/sesiones.txt Just fill in 2 diffrent pg_conn. A StackOverflow question is also open and contains all the details: http://stackoverflow.com/questions/34185536/php7-is-breaking-my-sessions-when-custom-session-handler-is-used-and-a-seccond-p ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=71088&edit=1