Menú dinámico con JavaScript y PHP

[lucasarts_18]

Empezado por dec

Hola,

Bueno. Pues las cosas cambian, pero, permíteme insistir en lo dicho de escapar cadenas (de entrada en la base de datos y de salida para imprimir), puesto que, como ves, usas el valor de la variable de la sesión dentro de la consulta SQL sin escaparlo antes: y eso puede traer problemas de seguridad... alguien podría "inyectar" SQL ahí.

Totalmente de acuerdo.

Empezado por dec

Pero, dejando este tema aparte y volviendo al asunto primero de este hilo... pues... ¿qué hay exactamente en la variable de la sesión? Yo probaría a dejar el "session_start()", pero, a poner un valor fijo en la variable de marras. No creo que "session_start()" de problemas (vamos, no veo porqué), pero, el valor... quién sabe qué valor es...

Es un simple valor del idPerfil, en mi caso tengo dos perfiles en la base de datos, 1 y 2. Puse el valor en "bruto" Y deje el session_start en el mismo lugar y sigue dando el problema.

Empezado por dec

Por otro lado, no has comentado al respecto, pero, ¿se supone que "juegas" con los mismos datos? En donde funciona y en donde no, me refiero, porque el problema podría estar en los datos... unos son problemáticos y los otros no.

Sos los mismos datos, en realidad en la misma base de datos, porque hice un restore de la misma base de datos que está en la otra máquina.Tienen los mismos registros.

Empezado por dec

Así que, resumiendo, vería qué contiene la variable de sesión.
Vamos... digo yo.

La variable de sessión trae un 1 o un 2.

Seún la web de php dice esto.

[quote=sitiophp]

Nota: Si está usando sesiones basadas en las cookies, debe llamar a session_start() antes de que haya ninguna salida al navegador.

[/sitiophp]

Y ahora que recuerdo existe una directiva en php.ini que en estos momentos no recuerdo su nombre que permite sacar salidas al navegador antes de enviar un session_start().

no sé, no sé, yo apuesto a lo que dice la web de php y que el session_start debe ir antes que haya una salida al navegador, ya que la variable que trae la variable de session siempre es 1 o 2, y los registros de la base de datos son los mismos.

Gracias por todo....

Espero tu comentario.

Nos vemos.

[dec]

Hola,

Bueno, es que de hecho, ahora que lo mencionas, efectivamente, no se puede (?) iniciar una sesión de usuario si ya se enviaron algunas cabeceras HTTP... y cuando enviamos contenido ya hemos hecho eso. Pues oye, por ahí pueden ir los tiros, sí. Diste en el clavo.

Ahora faltaría saber cómo es que un lugar funciona y en otro no, pero, yo creo que el asunto apunta a lo que dices: puede que cierta configuración de PHP (tal vez incluso de Apache) haga que el que no se pueda enviar nada antes de iniciar sesión no sea tan así...

De todas formas, es extraño. Porque, si me dijeras, bueno, es que no puedes enviar contenido antes de iniciar sesión, y, si lo haces, los resultados son inesperados... pues vale. Pero, si me dices que la variable de sesión que utilizas trae el valor "correcto" en todo caso... pues chico, no sabe uno qué pensar.

En todo caso, efectivamente, no cuesta nada poner ese "session_start()" antes de enviar salida alguna, de modo que comprobemos si así funciona... en ambos sitios.

PD. No había visto el mensaje:

Empezado por Lúcas

Asunto arreglado el session_start debe estar antes de una salida al navegador, lo puse al comienzo y asunto arreglado, ahora mi pregunta es ¿por qué diablos funciona en la otra máquina.?

Y ahí está la madre del cordero, pero, como he dicho, creo que apuntas bien... debe ser "algo" en la configuración de PHP... o Apache... pero, en todo caso, teniendo cuidado de no enviar nada antes de iniciar la sesión, y funcionando así en todos lados... oyes, a lo mejor tampoco hay que dar más de sí el tema, que bastante te ha comido el coco. Aunque, por otro lado, estas cosas gusta saber porqué pasan... No sé... no sé...

[lucasarts_18]

Hola Dec,

Encontre en la otra máquina porque sí funcionaba el asunto, efectivamente era una directiva del php.ini (no tengo tan mala memoria decía un sabio, jeje )
y la directiva que permite modificar ese comportamiento en php es la siguiente.

output_buffering = On

Así estaba en la máquina que siempre había funcionado

output_buffering = Off

Así estaba en la máquina que no funcionaba.

Pero vemos que dice esta directiva en el propio comentario del php.ini

; Output buffering allows you to send header lines (including cookies) even
; after you send body content, at the price of slowing PHP's output layer a
; bit.  You can enable output buffering during runtime by calling the output
; buffering functions.  You can also enable output buffering for all files by
; setting this directive to On.  If you wish to limit the size of the buffer
; to a certain size - you can use a maximum number of bytes instead of 'On', as
; a value for this directive (e.g., output_buffering=4096).

Ahí está la respuesta a este quebradero de coco. jeje.

Hasta Luego .-

[dec]

Hola,

Pues a mí no me queda tan claro... o sea, que sí, que uno puede usar esa directiva en caso de tener la necesidad (podrá darse el caso, digo yo) de enviar cabeceras HTTP incluso luego de haber enviado cierto contenido, pero, ¿y qué más?

Porque no veo que diga (pero mi inglés es muy malo) algo así como "y si usted no usa esta directiva y envía contenido y después trata de enviar cabeceras HTTP, entonces los resultados de su script serán pueden ser impredecibles"... ¿O qué?

Pero, no te quiero comer el coco Lúcas... me alegro de que dieras con la tecla, incluso si a mí no me queda claro por qué ocurría el error... qué era lo que lo provocaba, al cabo. ¿O es que me estoy perdiendo algo? Mira que no me extrañaría.

[lucasarts_18]

Dec, yo lo veo así, en la máquina que tiene activado esta directiva permite enviar contenido antes de hacer uso de funciones como session_start, de ahí que el menú siempre funcionaba, hay que mirar que el código del menú al comienzo el solo javascript, por lo tanto se enviaba este código antes del session_start y funcionaba de maravilla porque estaba activada esta directiva en el php.ini.

En la otra máquina pues no estaba activada esa directiva por lo tanto fallaba, de ahí que cambiara el session_start al comienzo del script y funcionó.

y sí efectivamente esa directiva al tenerla activada permite enviar salidas al navegar antes que el envío de cabeceras HTTP.

Hasta Luego .-

[dec]

Hola,

¿Quieres decir que de ahí que JavaScript no encontrara la variable "TREE_NODES", porque esta, en realidad, no era enviada? Ajá... pues entonces, claro, ahí puede estar la madre del cordero, como suele decirse.