Variable de asp php

[Tato]

Alguien me podría decir como leer una $HTTP_SESSION_VARS["X"] recibida desde un php con un ASP. Gracias.

[u_goldman]

Bueno, pero como se la vas a pasar al ASP?

[Tato]

esa es mi duda.

[Neuron_376]

Si estas usando el IIS que soporta ambos tipos de lenguajes, prueba usar solamente esto.

En PHP $_SESSION[$Var]

En ASP Session("Var")

Y nos dices que pasa.

Es bueno saber esto...

[Tato]

no funciona

[Neuron_376]

Como inicializaste la session, con ASP o con PHP, si la iniciaste solo en PHP, lo que deberias hacer entonces es crear en ASP las variables que necesitas, es decir algo como:


iniciarSession.php

session_start();
$_SESSION["User"] = "x";

redireccionar_hacia("iniciarSession.asp");

iniciarSession.asp

Session("User") = "x"

Entonces en las paginas donde uses ASP deberas podras usar esas variables, no se si en un solo script puedas tener ambos codigos, algo como:

iniciarSession.asp

<?
CODIGO PHP
?>

<%
CODIGO ASP
%>

Lo cual seria muy facil manejar variables de session asi.

Pruebalo

[u_goldman]

Y por qué no se la pasas al ASP mediante un querystring y listo? no se la sintaxis en php, pero es lo que me suena más lógico, y en ASP la recibes con

variable = request.querystring("variable")

Salu2,

[javopereira]

Solo una acotación:
si hay cosas en asp y php me "huele" que quizas esten sn sitios diferentes.
Si fuera asi, aviso que las variables de sesion de "un" sitio no se ven en "otro".

Quizas sea muy obvio, pero aviso x las dudas......

[Neuron_376]

Escrito por u_goldman

Y por qué no se la pasas al ASP mediante un querystring y listo? no se la sintaxis en php, pero es lo que me suena más lógico, y en ASP la recibes con

variable = request.querystring("variable")

La respuesta es SEGURIDAD, no puedes meter cosas de Session en ese tipo de variables, no si deseas funciones de atutentificacion, imagina.

redirect hacia--> ( "privado.asp?" . $_SESSION["user"])

y en

privado.asp

if request.querystring("user") > "" then
//tienes acceso
else
//no tienes acceso

Eso seria muy peligroso e incorrecto, la otra claro, todo tiene solucion, en esta pagina de ASP se busca al usuario en la base de datos y ya se decide el acceso, etc, pero pues no va.

[javopereira]

meterlos en campos hidden y pasarlos x form?
¿no te sirve?

[Neuron_376]

Escrito por javopereira

meterlos en campos hidden y pasarlos x form?
¿no te sirve?

Es lo mismo que decia u_goldman, y es la misma respuesta.

[u_goldman]

Es verdad eso de la seguridad, pero habría que ver que dato realmente está almacenando en sesión...la otra es utilizar una tabla temporal como puente entre estas dos tecnologías, bah, que se sho!

Salu2,

[Neuron_376]

Lo de la tabla es buena idea, pero tendriamos una tabla que es consultada en cada pagina por cada usurio, pero bueno, para logs, banners, etc, tambien pasa lo mismo, hummm, lo malo es que seria mas complicado decidir como consultar...

Como encontrarias el ID que corresponde al usuario, tal vez una cookie en el cliente con un codigo ????

Suena muy complicado...

Mejor que Tato haga pruebas con conbinar codigo en el mismo archivo y que nos diga que paso.

[u_goldman]

No, no es tan complicado, es como está funcionando por ejemplo .NET, que puedes tener tus sesiones en SQL, precisamente para evitar las deficiencias que tiene ASP 3.0 en ese tema.

Y si, la idea sería generar un ID y guardarlo junto con el valor de la sesión, la idea es generar un par valor, después dentro de los 2 ambientes puedes jugar con esto incluso para no tener que consultar cada vez. Y es mucho menos volátil que estar manejando todo en memoria principal.

Mis $0.02

Salú!

[Myakire]

Me imagino que javopereira al mencionar lo de los campos hidden se refería a algo como:

...
?>
<form name=frmOculto method="POST">
<input type="hidden" name="ID" value="$_SESSION["user"]">
</form>
<script>document.frmOculto.submit()</script>
<?

Lo cual no suena tan descabellado, ya que al momento de necesitar la redirección en PHP es lógico que es un momento en que el cliente no pide datos, solo recibiría el formulario del servidor y lo procesaria inmediatamente, el usuario no sa dería cuenta de ello ni podría ver el código.

[Neuron_376]

Myakire
Me imagino que javopereira al mencionar lo de los campos hidden se refería a algo como:

...
?>
<form name=frmOculto method="POST">
<input type="hidden" name="ID" value="$_SESSION["user"]">
</form>
<script>document.frmOculto.submit()</script>
<?

Lo cual no suena tan descabellado, ya que al momento de necesitar la redirección en PHP es lógico que es un momento en que el cliente no pide datos, solo recibiría el formulario del servidor y lo procesaria inmediatamente, el usuario no sa dería cuenta de ello ni podría ver el código.

Es el mismo problema con eso, que con lo que comento u_goldman, y javopereira, y es la misma respuesta, no puedes tratar las variables de session de esa forma.

Por lo tanto lo mas seguro y sencillo seria la parte de inicializar las variables de session para ambos lenguajes, aunque esto te da el doble de consumo de memoria por usuario, pero pues vas a declarar en session solamente las variables que necesites para cada lenguaje segun tu programa lo requiera, y bueno, yo sigo esperando que Tato pruebe tener codigo PHP y ASP en un solo SRIPT para ver que pasa, sino la otra es la redireccion, ahi si, con parametros en el URL o con FORM (recomendado), entonces la segunda pagina lee esos datos y realiza el proceso de buscar en la base de datos, autentificar al usuario, etc, y poner las variables de session adecuadas para el segundo lenguaje, lo cual es muy diferente a que una pagina privada acepte variables de session por URL o por FORM, lo cual es un hoyo de seguridad.

Jejeje, y si es una idea MUY DESCABELLADA

[Myakire]

Pues yo sigo sin entender tu punto de vista Neoron_376. ¿por qué dices que no se puede tratar a las variables de sesión de esa forma?, tu argumento algunos post arriba fue unicamente la palabra seguridad........¿cuál es el problema?, no sería lógico que un archivo .asp o .php pueda contener e interpretar dos lenguajes de servidor diferentes. Y empezando por ahí, entonces lo único que te queda es redireccionarlo (por que es menos costoso que utilizar una tabla, un archivo tal vez) y de hacerlo por URL o por POST, esto último como lo comentó javopereira es lo más lógico.

[Neuron_376]

Ok, antes ya puse toda la explicacion acerca de seguridad, y el hueco que provoca interpretar variables de session como parametros de URL o post, es exactamente lo mismo el problema, yo recomende abajo directamente el redireccionamiento para INICIALIZAR variables de session en ambos lenguajes, porque tambien pienso que no es posible tener dos lenguajes en el mismo script, pero bueno, es posible que si se de el caso, no lo se, recuerda que lo que esta entre <% %> es interpretado por el ASP, y el resto por el HTML, entonces ahi son dos interpretes en el mismo codigo, es posible, no lo se si exista, que tambien se pueda mezclar <? ?> que seria php.

Pero bueno, mira este caso que puse abajo

pagina1.php ---> POR POST para el parametro de user hacia privado

y en

privado.asp

if request.form("user") > "" then
//tienes acceso
else
//no tienes acceso

Esto que te provoca ??? facil, cualquier persona puede hacer una pagina local con un form asi:

<form actio="http://www.TU_SERVIDOR.com/privado.asp" method="post">
//Campo de user
</form>

Eso, que provoca, que sin autentificacion alguna cualquier persona tenga acceso a la pagina, y sucede lo mismo con URL etc.

Eso es seguridad, en session existen datos personales y datos privados para el funcionamiento de la pagina personalizada a tu cliente, entonces ninguna pagina puede decir cosas como:

"Si recibo esta variables (que deberia estar en session) por la URL entonces todo es correcto" --> Esa idea esta mal

No puedes tratar esas varibles como si fueran de session por parametros, es una falla.

Aplicalo con una pagina tuya por ejemplo, simplemente los sistemas de banners que se basan en el pais, estado y ciudad del usuario actual, que pasa si en lugar de Session utilizas valores de url, cualquier persona puede ver todos tus banners de cualquier pais, etc.

[AlZuwaga]

Esto que te provoca ??? facil, cualquier persona puede hacer una pagina local con un form asi:

<form actio="http://www.TU_SERVIDOR.com/privado.asp" method="post">
//Campo de user
</form>

Ok, pero eso es controlable (no sé si 100%).
Puedo preguntar primero si HTTP_REFERER (tanto en ASP como en PHP) es nulo. Si lo es, lo mando al demonio. Si no es nulo, pregunto su valor. Si el valor del referer no es exactamente el esperado (http://www.MI_SERVIDOR.com/pagina_que_llama_a_privado.asp), también lo mando a la merda.

y... no le veo más problemas de seguridad, aunque podrían existir y escapan a mi conocimiento.

[Neuron_376]

En un sitio normal pequeño, desde cuantos puntos puedes llegar a una pagina privada, tanto desde secciones de visitantes como secciones de miemobros? Muchisimos puntos diferentes.

Ademas de Refered tiende a fallar y esta comprobado en este mismo foro, tema que ya se toco antes, tango en PHP como ASP esa variable tiende a fallar.

Otra cosa, si quieres implementar algo asi, tendrias que definir:

1. todos los puntos por donde puedes llegar
2. cada pagina deberia estar preparada para realizar la comprobacion en la base de datos referente a los datos que esta leyendo.
3. El ejemplo del sistema de banners ???, como lo solucionarias con este algoritmo, como decir, muestra los banners segun el usuario activo cuando le estas pasando por el URL o POST al AdServer valores, como se arregla ese caso??? Para mi no hay forma de prevenir 100% ese error, y asi como esta el AdServer existen otros caso.

Ultimos puntos:

4, Session es session y Parametros son Parametros.
5. Para que crear y poner en cada pagina codigo tan complicado para CUBRIR UN PROBLEMA DE SEGURIDAD, cuando en primer lugar, este problema de seguridad te lo puedes ahorrar, es decir, si lo haces correctamente este problema no existe, y segundo, el codigo (PARCHE) para cubrirlo tambien te lo puedes ahorrar.

Esa es mi opinion

[Myakire]

Pues yo insisto ...

Ahora voy de salida y no puedo colocar un post extenso explicando mis puntos de vista a conciencia, pero no creo que debas de basar las sesiones como único medio o por lo menos como lo más seguro para manejar autentificación.
Para empezar, ni siquiera tenemos control en la existencia de seciones dado a que están supeditadas a la aceptación de cookies por parte del cliente. Por lo que se refiere a los envios de POST, pues primero deberían averigûar el nombre del parámetro que se envía (que si se puede) y luego pasarse la validación del HTTP_REFERER trabajado por medio de una página de redireccionamientos (para que el dominio de dicha variable sea menor). En ASP.NET se maneja la ausencia de cookies en el cliente por medio de valores por POST y si uno desea aumentar la seguridad, pues de le agregan encabezados SOAP. Pero eso ya es complicarse aún mas el asunto. Ya en estos limites del stress se puede implementar un certificado de seguridad y se evita el problema del parámetro POST. pero bueno, ya lo dejaremos para el Martes ( el Lunes 25 es el mero día de la feria de San Marcos en Aguascalientes -¿dónde andas U_G, te pierdes de la cantina más grande de México? )

Saludos y nos vemos el Martes

[u_goldman]

-¿dónde andas U_G, te pierdes de la cantina más grande de México?

Que envidia master!! pásatela bien, hace dos años estuve en "chorros tibios", gran lugar!!! y la feria es inmejorable!

[Neuron_376]

Estoy de acuerdo contigo Myakire, pero creo que caes en lo mismo que puse en el punto 5, ... para que crear codigo tan complicado para tapar algo de seguridad, si te puedes evitar el problema de tener ese error de seguridad.

Es como crear el oyo, y luego querer taparlo..

Pero bueno, respeto todos los puntos de vista, y cada quien hace las cosas como mejor le funcionan.

Suerte!!