Bug #71088 [Asn]: 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: Assigned Type: Bug Package: Session related Operating System: Windows 2008 PHP Version: 7.0.0 Assigned To: yohgaki Block user comment: N Private report: N New Comment: @cdutary I briefly checked PostgreSQL 8.4 and 9.x libpq code. PostgreSQL 8.4's PQunescapeBytea() does not have support new escape method, but it seems 9.x code has older escape support. I'm not sure why you get errors. Since I'm a pgsql module maintainer, I may investigate what's wrong. Please open new pgsql module bug report, if you think your problem is some kind of bug. I'll close this bug. Previous Comments: ------------------------------------------------------------------------ [2015-12-14 22:56:39] cdutary at grupocti dot com Well, the seccond connection is made to a older version of postgres, session management is made on the same version (9.4.4) both client and server so I guess this is the one that should matter. My guess is that PHP, in order to be compatible with the seccond conection is using old "techniques" against the new server as well. I was expecting for php to handle both connections separately but I guess that is just not possible. FIRST SERVER (session storage): PostgreSQL 9.4.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11), 64-bit SECCOND SERVER: PostgreSQL 8.4.20 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11), 64-bit CLIENT(php): PostgreSQL(libpq) Version 9.4.4 ------------------------------------------------------------------------ [2015-12-14 22:08:20] yohgaki@php.net I don't get suspicious error. --- modified test codes ---- ob_start(); session_start(); isset($_SESSION['aaa']) ? : 'Setting value' . $_SESSION['aaa'] = 'áéíóú'; //added unicode chars to our session data. $_SESSION['cnt']++; var_dump($_SESSION); $pg_conn = pg_connect("host=localhost port=5432 dbname=yohgaki user=yohgaki"); ------------------------------ 1st access ------------------------------ Notice: Undefined index: cnt in /home/yohgaki/workspace/ext/git/oss/php.net/php-src/t3.php on line 156 array(2) { ["aaa"]=> string(10) "áéíóú" ["cnt"]=> int(1) } ------------------------------- 2nd access ------------------------------- array(2) { ["aaa"]=> string(10) "áéíóú" ["cnt"]=> int(2) } ------------------------------- It seems you are having problem with BYTEA escaping. What is your PostgreSQL version, both client library(libpq) and server? Does client library (libpq) and server version match? Check phpinfo() output for client library version. Do "SELECT version()" for server version. BYTEA escaping has been changed for better performance. It seems your environment has version mismatch problem. If client library and server version matches, it should work. ------------------------------------------------------------------------ [2015-12-14 18:41:12] cdutary at grupocti dot com I took your code and added the last 2 ingredients to make PHP fail and it did: ob_start(); session_start(); echo isset($_SESSION['aaa']) ? : 'Setting value' . $_SESSION['aaa'] = 'áéíóú'; //added unicode chars to our session data. var_dump($_SESSION['cnt'] ++); $pg_conn = pg_connect("host=´host2 port=5432 dbname=database2 user=user2 password=pass2"); //added a seccond pg_conn which somehow makes session unreadable The output is: PHP Warning: session_start(): Failed to decode session object. Session has been destroyed in sesions.php on line 179 PHP Notice: Undefined index: cnt in sesions.php on line 183 For now the workaround I found is to wrap up the session info in base64() before saving it into php_session and unwrap it at read. This works with both session save handlers, your's and mine. The original problem still remains and I can't find a reason for it yet. ------------------------------------------------------------------------ [2015-12-14 10:48:53] yohgaki@php.net I just wrote an example save handler for PostgreSQL. https://gist.github.com/yohgaki/a7b130bc93b2f9467ccc Try this one and see if you have problems. ------------------------------------------------------------------------ [2015-12-14 09:29:03] yohgaki@php.net 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. ------------------------------------------------------------------------ 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=71088 -- Edit this bug report at https://bugs.php.net/bug.php?id=71088&edit=1