Igual el título de esta entrada no es el más adecuado, pero, es el que se me ha ocurrido. Ya veremos. Lo que quiero plantear es lo importante de utilizar ciertas constantes "bandera" para impedir el proceso por separado de determinados "scripts", bien porque este no tenga sentido alguno, en principio, bien por evitar posibles problemas de seguridad, y también para evitar los reportes de errores de PHP, que no siempre pueden estar configurados en un determinado servidor tal y como quisiéramos.
Seguramente no descubriré nada nuevo a nadie. Imagina que un determinado "script" de PHP es el encargado a su vez de requerir otros "scripts" necesarios. Es una de las características que hacen poderoso a PHP a la hora de "modularizar" ciertas páginas web, la posibilidad de utilizar archivos a modo de "plantilla", por ejemplo, es muy común contar con "scripts" tales como "index.php", "header.php" y "footer.php". A "header.php" y a "footer.php" no tiene sentido "llamarles" por separado, puesto que será "index.php" quien los requiera.
Ahora bien, ¿qué ocurre si se llama a "footer.php" por separado? Alguien con mejores o peores intenciones puede tratar de hacerlo, ¿y entonces qué ocurre? Pueden ocurrir varias cosas, evidentemente, depende de qué sea lo que haga exactamente el "footer.php", pero, en todo caso lo que tenemos que mirar es que es un "script" que no debe ser procesado por separado, que no tiene sentido, así que tenemos que evitarlo, y esto es muy sencillo de llevar a cabo utilizando alguna constante que nos sirva de "bandera".
Así, en "index.php" podemos definir cierta constante:
define('APP_INDEX_OK', true); require('header.php'); // Código del script require('footer.php');
Y, tanto en "header.php" como en "footer.php" averiguar si nuestra constante está definida, para, si no lo está, no continuar adelante:
Terminar o no la ejecución del "script" es ya algo más o menos opcional, quiere decirse, si se trata de algo más o menos sencillo, podríamos redirigir a quien fuera que pidiera los "scripts" "header.php" o "footer.php", de este modo:
Pero, en todo caso, evitamos el proceso de dichos "scripts" de forma separada. Ya dije arriba que lo hacemos por varios motivos. No tiene sentido que esos "scripts" se procesen por solitario, pero, es que, de permitirlo, podemos encontrarnos con consecuencias inesperadas. Por ejemplo, es probable que "footer.php" utilice ciertos recursos, ciertas variables, que dependen de que la aplicación se iniciara por el punto de entrada predeterminado: "index.php".
En este caso, el servidor podría arrojar una serie de errores PHP, que, como sabes, conviene ocultar en todo caso, puesto que proporcionan información que puede ser utilizada por según qué personas para fines nada sanos, por decirlo así. Comprobando que nuestra constante está definidida, y no permitiendo la ejecución de este tipo de "scripts", nos quitamos del medio posibles problemas desagradables. Estarás de acuerdo conmigo.
Es cierto que quizá no es nada nuevo -y menos si se destripa cualquier prefabricado-, pero no es menos cierto que viene bien porque siempre hay alguien despistadillo por ahí.
En mi caso he llegado hasta aquí buscando algo relacionado aunque no es exactamente esto lo que buscaba. Llegué desde google en relación a la búsqueda sobre la variable del servidor HTTP_X_REQUESTED_WITH... que imagino será de Apache 2.x y que nos da el valor del objeto XHR.
El motivo de mi búsqueda es exactamente el problema del que tratas pero llevado, como no, a AJAX y el establecimiento de banderas en scripts que serán llamados fuera, digamos, del sistema, para poder evitar llamadas directas.
Y lo mismo te preguntas: ¿Y a mí que me cuentas? xDD, sólo es porque está muy relacionado y, en mi opinión, es el siguiente paso natural al problema que comentas aquí, ya que hoy en día las peticiones cada vez son más las asíncronas y se nos complica la cosa.
Igualmente... me llama la atención que no aparezca el término HTTP_X_REQUESTED_WITH y aún así google me haya traído aquí ^^!.
Un saludo, me gusta el estilo minimalista de tu blog ;)
Hola Covi, gracias por tu comentario. Efectivamente, creo que el motivo de que llegases hasta aquí, o de que Google te trajese hasta esta bitácora, está en esta entrada: Conocer el tipo de petición HTTP, que trata de la constante de que hablas, precisamente.
Respecto de dicha constante, no estoy seguro de que la proporcione sólo Apache 2.x, sino que más bien parece que son las herramientas utilizadas para realizar este tipo de peticiones HTTP las que tienen que "informar" de ello, por una especie de consenso, mediante el uso de la cabecera HTTP correspondiente: es esa cabecera la que nos ofrece la constante, por lo tanto, creo, independientemente de si usamos Apache 2.x.
De todas maneras no creas que lo tengo muy claro. Esta entrada ha podido quedar muy simplona, pero, en fin, supongo que son de esas cosas que hay que tener en cuenta a la hora de llevar a cabo algún proyecto con PHP. Es bien saber que un determinado "script" no debe funcionar por separado, y que podemos tratar de evitarlo en todo caso. ;)
Ole!, muchas gracias, eso es precisamente lo que buscaba. No la he leído entera pero va a ayudar mucho, no sabía que esa cabecera indicara precisamente eso..., es que X_REQUESTED_WIDTH??? ggg xD , yastamos con el tema del guirlandés.
Es cierto, fue una tontería ^^ , que no tiene porqué ver con Apache pero creo que lo que es seguro, y aunque XHR sea más viejo que el sol en realidad, es que esa cabecera, o no era nada conocida o lo mismo forma parte de una nueva versión de HTTP... ¿no crees?.
Me ha sorprendido sobremanera que ningún IDE para php la liste en variables globales de servidor, así que buscaré más sobre el tema, aunque ya veo que comentas que no se suele usar, lo mismo por lo que digo de vieja ha perdido importancia.
--- En cualquier caso creo que para mí va a ser interesante en relación a eso mismo: establecer banderas en peticiones HTTPRequest. Aunque pensándolo bien, es igualmente suplantable, lo que había pensado era usarla al generar una clave única con un conjunto de variables de servidor y tiempo.
Bueno, muchas gracias por responder tan pronto ;) ...y bueno, ya que estamos, sería de agradecer que compartieras tu conocimiento en este sentido, me estoy partiendo los cuernos googleando y leyendo soluciones de seguridad para peticiones ajax legítimas. No acierto a escoger o elegir una técnica :( El principal problema que veo es que cualquier flag basado en tiempo no sirve ya que mientras el script de respuesta genera un tiempo nuevo, el script que hace la petición, al ser estático, no :S
En fin, un saludo.
Lo cierto es que el asunto puede complicarse, en un momento dado. Como tú dices, cualquiera podría falsear la cabecera HTTP de que hablamos, así que muy fiable, en según que casos, no sería. Y es que me parece que depende de cómo y de qué manera el sistema acepta y utiliza peticiones HTTP en segundo plano, vía "AJAX".
En el caso de mi proyecto Gesbit, por ejemplo, en el panel de administración, pueden llevarse a cabo algunas tareas de esta forma. ¿Y cómo impido que esos "scripts" se ejecuten de forma separada? Mediante el uso de alguna constante "bandera". ¿Pero esta forma no es también hasta cierto punto "falseable"? Me temo que sí. ¿Y entonces? Daría lo mismo.
Para que los "scripts" que Gesbit usa en el panel de administración vía "AJAX" puedan ejecutarse, es preciso que un usuario esté autenticado en la aplicación. Si no es así... ya puedes incluir el "script", saltarte las banderas o lo que sea: el "script" no se ejecutará si se comprueba que quien realiza la petición HTTP no es un usuario registrado y autenticado en la aplicación.
Y dirás, hombre, pero, eso sólo valdría en el caso de que la aplicación contara con un registro de usuarios, y la posibilidad de saber si uno está autenticado, además de que algunos "scripts" podrían ser más bien "públicos" y así cualquiera, en principio, debería poder ejecutarlos. Y aquí es cuando te digo que no se me ocurre nada en concreto, y que me parece que dependerá de la aplicación en cuestión.
Sólo se me ocurre algo, pero, no me parece que sea algo que no se te hubiera ocurrido a ti ya: se trata de usar variables "de sesión". Hasta donde yo llego, nadie desde fuera puede establecer variables de este tipo, de la misma forma que podría definir una determinada constante. Un determinado "script" podría comprobar la existencia de cierta variable de sesión, con cierto valor, y, no ejecutarse si esta no existe o no contiene un valor como el que se espera.
Una cosa sí creo que debe quedar medio clara para todos: las constantes "bandera" están muy bien, pero, sea como sea, no podemos utilizar algo así para procesos "críticos", por decirlo de alguna manera. Las constantes "bandera" pueden servirnos normalmente en buena parte de los casos, pero, más allá de eso la aplicación debería llevar a cabo otras comprobaciones si fuera necesario. En el caso de Gesbit, como digo, por ejemplo, si no estás autenticado en la aplicación, ninguno de los "scripts" del panel de administración ("los de AJAX" también) debe procesarse. Y así lo procuro...
Pero no sé si te habré dado alguna idea o qué. Lo que sí puedo hacer es invitarte a los foros del ClubDelphi, en los que participo desde hace algunos años: porque si bien yo puedo tratar de echar una mano, lo cierto es que en el ClubDelphi no sólo yo podría tratar de hacerlo, sino que hay otras personas que también podrían aportar soluciones, como así hacen, como podrás comprobar tú mismo. ¿Eh? ¿Qué te parece? ;-)