14/02/2006, 09:09
| |||
| |||
| pasar variables entre servidores y/o sesiones multidomino Hola a todos, mi consulta es con que metodo puedo pasar variables desde un servidor a otro. Por ejemplo: si tengo el "servidor 1" en la cual hago unas consultas sql, retornandome ciertos resultados los que guardo en variables, como puedo hacer para que esas variables lleguen al "servidor 2"? -------- otra duda que tengo es que si inicio las variables de session en servidor, estas pueden ser utilizadas por otro servidor?  ojala se entiendan mis dudas gracias de antemano saludos |
|
14/02/2006, 09:22
| |||
| |||
| Cita: En principio se las deberías pasar por el URL (ya sea en un link simple o por sockets) .. Por ejemplo: si tengo el "servidor 1" en la cual hago unas consultas sql, retornandome ciertos resultados los que guardo en variables, como puedo hacer para que esas variables lleguen al "servidor 2"? Por ejemplo: header ("Location: http://www.servidor2.com/nose.php?variable=$variable"); Eso sería una propagación de datos por el URL .. No es para nada seguro .. pero funciona. Por "sockets" podrías probar con cURL (www.php.net/curl) o con algo más básico con fsockopen() e interpretando el protocolo HTTP para la comunicación. Algo más avanzado sería crear "web services" (que se basan en sockets y en datos formateados en XML normalmente). Cita: No, las variables de sesión son própias del servidor que las crea.otra duda que tengo es que si inicio las variables de session en servidor, estas pueden ser utilizadas por otro servidor? Un sistema de sesiones "multidomino" tendría que ser basado en un sistema de almacenamiento centralizado y accesible desde cualquier sitio tipo Base de datos a la cual te puedas conectar desde cualquier servidor (e incluso "lenguaje" de programación .. no sólo PHP). Un saludo, |
|
14/02/2006, 09:41
| |||
| |||
| Cita: He leído hace mucho un post tuyo Cluster que hablaba sobre tener mas control sobre las sesiones (creo que era este el tema del thread) que PHP tenia una función para "reemplazar" las funciones propias sobre el manejo de sesiones, el link es este, ahora como dices tendría que ser un almacenamiento centralizado, sí modificamos las funciones a gusto y la empleamos dentro de un servidor de base de datos "compartido" ¿No cumpliría ese cometido?.
Iniciado por Cluster Un sistema de sesiones "multidomino" tendría que ser basado en un sistema de almacenamiento centralizado y accesible desde cualquier sitio tipo Base de datos a la cual te puedas conectar desde cualquier servidor (e incluso "lenguaje" de programación .. no sólo PHP). Saludos. PD: Me parece que para tu cometido esta opción es un poco "grande", lo digo porque lo veo como si quisieramos cazar pajaritos con una antiaerea de 127 milímetros  . |
|
14/02/2006, 10:26
| |||
| |||
| Si, .. se basa en "reemplazar" las funciones nativas de PHP por las própias. Por supuesto .. los N dominos que tengan que acceder a estas sesiones tendrán que usar el mismo código (classe o lo que usen). Por ejemplo ADOdb .. conocido más bien por ser una capa de abastracción de Base de datos, .. incorpora el manejo de sesiones de este tipo: http://phplens.com/lens/adodb/docs-session.htm (en castellano pero no tan actualizado) http://www.lacorona.com.mx/fortiz/ad...session-es.htm Otro tutorial: http://phplens.com/phpeverywhere/node/view/37 Algunas ventajas principales de estas mejoras al uso de sesiones por defecto de PHP son principalmente la de tener más control sobre la sesión en sí, individualizarla (para ver tiempos de expiración que queda o definirlo .. ) y como añadido y por la filosofía de almacenamiento "centralizado" de los datos .. la posibilidad de acceso desde multiples dominos. Un saludo, Última edición por Cluster; 14/02/2006 a las 10:36 |
|
14/02/2006, 15:01
| |||
| |||
| Ahora, si bien no me interesa aplicar esto de "reemplazar" las funciones nativas para hacer un uso centralizado (si puede ser para tener mas control sobre ellas, como el tiempo de expiración, siempre da problemas) pero me surge una gran duda ¿Como continuamos con la sesion si estamos en distintos dominios? por ejemplo por cookie no creo que se pueda hacer ya que esta guarda el dominio (si estoy equivocado, avisen... nunca me gustaron las cookies), pero si podríamos pasar la sesion por medio de la url, ¿Pero funcionara? Saludos. |
|
14/02/2006, 15:08
| |||
| |||
| El SID se propaga en el URL (en tus links, formularios .. etc). Esto es "peligroso" en condiciones normales .. pero igualmente algunas validaciones se hacen. De hecho propagar el SID en el URL sólo será necesario si necesitas de la funcionalidad de sesiones en "multidomino". Para el uso común en un mismo domino .. se puede propagar por cookies por seguridad. AdoDB parece la más completa e incorpora validaciones al respecto .. Revisa si puedes su documentación .. Un saludo, |
|
14/02/2006, 15:13
| |||
| |||
| Cita: Prometo revisarla cuando tenga un poco de tiempo para leer tranquilo la documentación.
Iniciado por Cluster Revisa si puedes su documentación .. Ahora no entiendo la utilidad de hacer las sesiones "centralizadas" si no las necesitamos usar en multidominio. tiene que haber una razón, pero no la veo  .Saludos. |
|
15/02/2006, 05:08
| |||
| |||
| Cuando usas sesiones "clásicas" de PHP ya estás "centralizando" esos datos sobre un servidor. Ahí por la forma en que se almacenan: (por defecto) en archivos de texto plano sobre la estructura de archivos de ese servidor y como se tratan, el problema principal que tienes es sobre acceso desde otros dominios. Por lo demás .. PHP y el soporte de sesiones que ofrece por defecto no nos ofrece opciones para gestionar el tiempo de vidad de las sesiones en forma individual, ni ver cuanto tiempo le queda para expirar .. entre otras cosas que se hechan en falta. Estos sistemas (como el soporte de sesiones que implementa ADOdb) al gestionar sus datos por funciones própias re-escribiendo las originales de PHP, gracias a que PHP por lo menos dejó la "puerta abierta" para que si el soporte "nativo" de PHP sobre sesiones no te agrada .. por lo menos puedas implementar tu própio sistema, lo único que hacen es aportar esas funcionalidades que hechamos de menos .. y como "añadido" por la filosofía de diseño de estas: almacenamiento de datos "centralizado" sobre una BBDD (accesible desde cualquier sitio simplemente conectandote a ella) .. como "añadido" se observa que puedes usarlo si tuvieses que leer o usar esas sesiones en vários dominios. En resumen .. el hecho no es que estén "centralizadas" .. sino en NO usar el sistema de sesiones por defecto de PHP por qué simplemente no aporta esas funcionalidades extra que más de una vez en cualquier tipo de aplicación se hecha en falta. Ahora .. es cierto que usar como sistema de almacenamiento y gestión de las sesiones una "base de datos" cualquiera se presta a implementaciones de estas funcionalideas (control tiempo expiración principalmente) mucho más rápido y versatil que otro tipo de soluciones (en base a archivos de texto plano ..). Pero, realmente no tiene nada que ver que sean "centralizadas" pues si tu usas tus sesiones en un sólo domino "ya están centralizadas". Un saludo, |
|
01/07/2006, 11:11
| ||||
| ||||
| sintesis: sesiones seria una forma vaga rapida y temporal de bd, si estas en otro server como vas a acceder a esta bd? pues pasale los valores por post y listo; te ahorras de tantas complicaciones de multidominio y todo eso. Luego te creas una sesion en el otro server en que estas con los valores que recibis por post y listo.
__________________ Dios es la unica fuente de todo bien. |
|
06/07/2006, 06:43
| |||
| |||
| Pues precisamente vengo teniendo el mismo problema yo también, necesito hacer login dos dominios a la vez desde una única página de login, colocada en uno de los sitios. Y claro, mantener las sesiones en ambos dominios por si el usuario quiere "saltar" de un lugar a otro. Leyendo vuestros comentarios se me esta ocurriendo una forma rustica que tal vez podría funcionar pero dudo de su seguridad/rapidez. La idea sería...(si de algun modo se puede obtener el nombre que recibe una coockie cuando se crea una sesion), al hacer loguin en el primer sitio y crear las variables de sesion oportunas..., colocar un fichero en el segundo dominio, con el nombre de la coockie (o algun nombre que identifique la sesion del usuario en el primer dominio) y ahora, al acceder al dominio dos, comprobar que los nombrs del fichero creado y la coockie coinciden y si es asi crear las nuevas variable de sesion en el sitio dos. Si cerramos alguno de los dos sitios habrá que borrar dicho fichero. Como veis esto? es viable?? |
|
06/07/2006, 07:20
| |||
| |||
| Cita: A la BBDD accedes por su conexión típíca .. TCP/IP (con tu "domino/IP", usuario y contraseña adecuada). EL "SID" própio que estos sistemas manejan harán la taréa de seguir viendo el mismo grupo de datos de la sesión en curso .. sea desde un dominoX o dominoY ..
Iniciado por ASCENDEDMASTERS sintesis: sesiones seria una forma vaga rapida y temporal de bd, si estas en otro server como vas a acceder a esta bd? pues pasale los valores por post y listo; te ahorras de tantas complicaciones de multidominio y todo eso. Luego te creas una sesion en el otro server en que estas con los valores que recibis por post y listo. No se trata de pasar los valores por "POST" .. Eso no es seguro ni factible cuando estás en una "aplicación" que se compone de muchas páginas/scripts que van interactuando con tus sistemas .. Por ejemplo por ese médio no puedes ir propagando una variable tan delicada como el de un "usuario" autentificado en tus sistemas (por eso existe el concepto de "sesión": te autentificas una vez y mientras estés en esa sesión así permaneces autentificado sin más validaciones contra ese dato en concreto). Un saludo,
__________________ Por motivos personales ya no puedo estar con Uds. Fue grato haber compartido todos estos años. Igualmente los seguiré leyendo. |
|
06/07/2006, 07:26
| |||
| |||
| Cita: Las COOKIES son por domino .. Tendrías el mismo problema. En cuanto a seguridad .. tendrías que implementar algún tipo de autentificación para acceder a tu archivo (sea HTTP simple .. o crear un "web service?" o algo similar .. pero no que quede por ahí en cierto "URL" complicado .. debe ser autentificado).
Iniciado por Gawl_111 Pues precisamente vengo teniendo el mismo problema yo también, necesito hacer login dos dominios a la vez desde una única página de login, colocada en uno de los sitios. Y claro, mantener las sesiones en ambos dominios por si el usuario quiere "saltar" de un lugar a otro. Leyendo vuestros comentarios se me esta ocurriendo una forma rustica que tal vez podría funcionar pero dudo de su seguridad/rapidez. La idea sería...(si de algun modo se puede obtener el nombre que recibe una coockie cuando se crea una sesion), al hacer loguin en el primer sitio y crear las variables de sesion oportunas..., colocar un fichero en el segundo dominio, con el nombre de la coockie (o algun nombre que identifique la sesion del usuario en el primer dominio) y ahora, al acceder al dominio dos, comprobar que los nombrs del fichero creado y la coockie coinciden y si es asi crear las nuevas variable de sesion en el sitio dos. Si cerramos alguno de los dos sitios habrá que borrar dicho fichero. Como veis esto? es viable?? Realmente la "filosofía" de una sesión es clara: "Un grupo de datos asociados bajo un identificador" .. así de simple. Como lo implementes es lo de menos. Lo más "factible" cuando hablamos de saltar entre dominos .. al no poder disponer pór ejemplo de una "cookie" que nos propague ese dato (SID que llama en PHP: Identificador Único de Sesión) .. por qué no tiene validez entre dominos .. lo pasamos por el "URL" (en nuestros links que hacemos para saltar de un dominioX al Y ... o viceversa .. Esto no es seguro por supuesto así simplemente .. pero sistemas como ADOdb (con su implementación de gestión de sesiones) ya validan algunas otras cosas (domino que pide el dato .. etc) para asegurar un poco más el tema. Por otro lado .. a la hora de implementar todo esto .. no sé por qué "asusta" usar BBDD .. pero bueno, el caso es que por seguridad y comodidad de administración ese tipo de tareas es mucho más seguro hacerlo contra una BBDD a la cual puedes autentificarte (con tu usuario/contraseña como corresponda y otro tipo de validaciones referentes al "Host" que lo usa). En resumen .. por mucho que yo "capture" ese SID en el URL no podré aunque use "Adodb" (de código abierto y público) conectarme a la BBDD en la cual almacenamos esos datos .. no tendré esa "contraseña" ni "usuario" .. ni tan siquiera el "host" donde conectarme. Un saludo,
__________________ Por motivos personales ya no puedo estar con Uds. Fue grato haber compartido todos estos años. Igualmente los seguiré leyendo. |
|
06/07/2006, 10:19
| |||
| |||
| La verdad es que el tema de lso web services no lo tengo nada claro y ya he mirado algun tutorial, pero no les capto la "utilidad" o el como me pueden ayudar a resolver mi problema. Igualmente no termino de pillar lo de la base de datos, no es que me asuste guardar algo en la base de datos, si no que no entiendo como hago para que, una vez accedo al segundo dominio.. como obtengo los datos de la "base de datos" que me sirvan para reconocer que el usuario ya estaba logueado en el primer dominio y se mantenga logueado en este segundo, no se si me explico. |
|
06/07/2006, 11:29
| |||
| |||
| Cita: 1) Se supone que tu te autentificas en "domino1" .. contra la BBDD que ese domino gestione y que tenga tus usuarios ..
Iniciado por Gawl_111 La verdad es que el tema de lso web services no lo tengo nada claro y ya he mirado algun tutorial, pero no les capto la "utilidad" o el como me pueden ayudar a resolver mi problema. Igualmente no termino de pillar lo de la base de datos, no es que me asuste guardar algo en la base de datos, si no que no entiendo como hago para que, una vez accedo al segundo dominio.. como obtengo los datos de la "base de datos" que me sirvan para reconocer que el usuario ya estaba logueado en el primer dominio y se mantenga logueado en este segundo, no se si me explico. 2) Creas la sesión sobre la BBDD (como ADOdb u otros sistemas similares gestionan) .. con los datos que consultastes en dominio1 como si lo hicieras con la gestión de sesiones "tradicional" de PHP. 3) Pasas al "domino2" por un link con el SID en el (para hacer referencia a la misma "sesión") propagado. En este caso el código que gestiona la sesión lo tienes instalado en "domino1 y domino2" .. la BBDD a la que se conectan para "centralizar" las varaibles de sesión es UNA sóla y puede estar en "dominioX" o donde quieras .. Por supuesto tiene que tener opción a conectarse en forma remota (no todos los servicios de hosting lo permiten .. sólo aceptan conexiones locales ..). Un saludo,
__________________ Por motivos personales ya no puedo estar con Uds. Fue grato haber compartido todos estos años. Igualmente los seguiré leyendo. |
|
07/07/2006, 02:05
| |||
| |||
| Vale creo que ya voy pillando lo que dices, he estado echando un ojo al manejo de sesiones con adodb que la verdad no sabia que se pudiera hacer. Entonces, para saber ahora que session de las que estan en la base de datos tengo que sacar para "duplicar" la session del sitio 1 en el sitio 2 comentas que tengo que pasarle el SID por un link, esto no me queda muy claro la verdad, como puedo obtener el SID? Es seguro pasar el SID por GET? Muchas gracias. |
|
07/07/2006, 06:18
| |||
| |||
| No, si usas un sistema tipo "Adodb" con su soporte de sesiones donde almacena las sesiones en una BBDD .. no se trata de "duplicar" sesiones ..sino de usar -ese sistema- y sesiones únicas que vas a crear. El "SID" lo gestiona y genera "Adodb" o el sistema que uses (al igual que PHP también lo genera y gestiona cuando usas el sistema clásico de sesiones de PHP). Esos sistemas ya te podrán a tu disposición una variable o método para obtenerlo y así tu podrás componer tus links tipo: <a href="http://www.sitio2.com/nose.php?<? echo $adodb->SID ?>">pasar a sitio 2</a> (El ejemplo del llamado al "SID" es ficticio . .no sé realmente "adodb" que método usa en concreto o variable o constante ...) El SID en general no es seguro pasarlo por el URL (lo que llamas tu "get"), pero estos sistemas como "Adodb" por ejemplo ya gestionan la seguridad por otros médios: comprueban IP's del cliente .. y cosas así .. Un saludo,
__________________ Por motivos personales ya no puedo estar con Uds. Fue grato haber compartido todos estos años. Igualmente los seguiré leyendo. |
Este tema le ha gustado a 1 personas 
