roundcube: "Session no valida. No se guardaron datos" - Imposible iniciar sesion a traves de HTTP despues de iniciar sesion a traves de HTTPS - Venezolana GNU/linux

roundcube: "Session no valida. No se guardaron datos" - Imposible iniciar sesion a traves de HTTP despues de iniciar sesion a traves de HTTPS

 

Desde que salio roundcube 1.0.X, se cambió la api y ahora es tan difícil ignorar que la gente normal la use ... quiero decir, una gente normal solo quiere navegar y luego, en las migraciones, genera este error:

Aqui te damos la solucion al problema, sigue leyendo:

Esto se informó en roundcube en el número de issue https://github.com/roundcube/roundcubemail/issues/7691, por supuesto, como siempre, el hipócrita  @alecpl solo se limita a decir "funciona para mí". 

El comportamiento de trabajo es incorrecto: cada sesión debe ser por sí misma ... ¡independiente de la bandera de seguridad! 

Esto significa que la sesión abierta https debe ser primero cerrada, por lo que no se puede permitir el sofing o hijacking si el usuario están en el camino del https, pero si está debajo de http después de cerrarla ... no debe ser, pues iba por https, mi parche resuelve el problema y legaliza cada sesión en su propia via de http o https. Permitira una migración fluida y limpia para su gente, debajo del parche la explicación:

diff --git a/program/lib/Roundcube/rcube.php b/program/lib/Roundcube/rcube.php
--- a/program/lib/Roundcube/rcube.php
+++ b/program/lib/Roundcube/rcube.php
@@ -442,7 +442,7 @@ class rcube
         $sess_domain = $this->config->get('session_domain');
         $sess_path   = $this->config->get('session_path');
         $lifetime    = $this->config->get('session_lifetime', 0) * 60;
-        $is_secure   = $this->config->get('use_https') || rcube_utils::https_check();
+        $is_secure   = $this->config->get('use_https');
         // set session domain
         if ($sess_domain) {
@@ -459,7 +459,9 @@ class rcube
         // set session cookie lifetime so it never expires (#5961)
         ini_set('session.cookie_lifetime', 0);
-        ini_set('session.cookie_secure', $is_secure);
+        if ( rcube_utils::https_check() ) {
+            ini_set('session.cookie_secure', $is_secure); // coment here for all unsecure if do not want https check
+        }
         ini_set('session.name', $sess_name ?: 'roundcube_sessid');
         ini_set('session.use_cookies', 1);
         ini_set('session.use_only_cookies', 1);

La primer comit que usó la cookie segura fue d5fca0c que verifica si están bajo el modo https, y si están bajo ... luego establece una cookie segura ... ¡ el problema está establecido para el resto del cliente remoto! después de la refactorización de la api roundcube en 1.0.X, este commit no se puede revertir, por lo que la nueva forma es verificar si está en https y usa https siempre ... (significa ... si y el usuario regresa de https a http por supuesto podría ser un ataque de suplantación)

Sin embargo, contrario a lo que dice @alecpl , técnicamente este código es incorrecto, ya que siempre siempre asume que pasa por https, eso no es cierto, PERO al contrario, por razones de seguridad el código original de roundcube está "bien", ya que un usuario se supone que dejar de ir por https seria un ataque de phishing, por eso este issue está cerrado y no se proporciono soporte.

Mi parche arriba solo legaliza y respeta la forma en la que navegas por el renderizado ... si estás bajo http para que la cookie no se aplique como debe ser , pero si estás bajo https, debes cerrar esta sesión correctamente para volver a usarla sobre http .. fácil. como debe ser.

No hay comentarios.:

Publicar un comentario

DESTACADOS:

El E3 está muerto: ¿qué tamaño tenía? leyenda para jugadores

E3 (abreviatura de Electronic Entertainment Expo) fue una feria/evento comercial anual para/de la industria de los videojuegos y/o jugadores...