FAQ
Me gustaria , si alguien tiene un rato , que me explicaran como se puede
mantener una coherencia en la seguridad de las paginas. Todo lo que pretendo
hacer es :

- Autentificacion de usuarios.
- Imposibilitar que los usuarios se bajen los archivos fuente (.php) , es
decir , ocultarlos.
- Imposibilidad de acceder directamente a una página sin haber realizado
una autentificación del usuario.
- Y si fuese posible ,que los usuarios no pudieran ver el contenido html de
las páginas devueltas por el servidor.

Si alguien tiene un rato y quiere puede enviarme un correo a la direccion
practicas1@vallduixo.infoville.net y quedaremos en un canal irc, o si
alguien tiene la solucion y puede enviarla a la lista le ruego lo haga.

Gracias .

Search Discussions

  • Devta Singh at Jan 25, 2001 at 11:18 am
    Bueno tus deseos son comunes a algunas necesidades de un sitio con
    información confidencial, pero eso de llegar a que no vean el html es
    excesivo y que no es posible evitarlo.

    En cuanto a que no vean el código fuente, si el PHP y el Apache están bien
    instalados no pueden verlo. Pero hay una forma de asegurarte y es poner todo
    el código en includes a los que llamas y que están fuera de la ruta del web.

    Por otra parte si quieres que solo accedan usuarios autentificados, pon un
    include que llame a tu función de autentificación favorita y usa también
    base de datos para registrar los accesos, así evitarás que algun
    malintencionado manipule una cookie y pueda entrar.

    La regla debería ser: Si no tiene cookie, le pides nombre y clave y si
    acierta, se la pones. Si la tiene, compruebas su validez contrastando con la
    base de datos, finalmente si todo está ok sigues con la págia y si hay
    errores le mandas al formulario de autentificación. (o le haces un
    header("location= http://www.... ") o un exit;)

    Y santas pascuas, y si quieres que no vean nada del HTML, generas la página,
    la vuelcas a un fichero gráfico y se lo mandas, pero tu cliente tiene que
    tener un ancho de banda razonable para ver esas lindas páginas de 2M en
    formato gráfico.

    ------------------------------------------------------
    Devta Singh
    Webmaster ZDNet España
    devta@zdnet-es.com
    ------------------------------------------------------
    ----- Original Message -----
    From: "Jose Luis de Vega Andres" <practicas1@vallduixo.infoville.net>
    To: "Lista de PHP (E-mail)" <lista@phpes.com>
    Sent: Thursday, January 25, 2001 9:02 AM
    Subject: [PHP-ES] Mantenimiento de la seguridad

    Me gustaria , si alguien tiene un rato , que me explicaran como se puede
    mantener una coherencia en la seguridad de las paginas. Todo lo que pretendo
    hacer es :

    - Autentificacion de usuarios.
    - Imposibilitar que los usuarios se bajen los archivos fuente (.php) , es
    decir , ocultarlos.
    - Imposibilidad de acceder directamente a una página sin haber realizado
    una autentificación del usuario.
    - Y si fuese posible ,que los usuarios no pudieran ver el contenido html de
    las páginas devueltas por el servidor.

    Si alguien tiene un rato y quiere puede enviarme un correo a la direccion
    practicas1@vallduixo.infoville.net y quedaremos en un canal irc, o si
    alguien tiene la solucion y puede enviarla a la lista le ruego lo haga.

    Gracias .


    ---------------------------------------------------------------------
    Archivo On-line: http://www.phpes.com/
    Manual PHP en español: http://www.php.net/manual/es/
    Para dar de baja la suscripción, mande un mensaje a:
    lista-unsubscribe@phpes.com
  • Tomas V.V.Cox at Jan 27, 2001 at 10:17 pm

    Devta Singh wrote:


    Por otra parte si quieres que solo accedan usuarios autentificados, pon un
    include que llame a tu función de autentificación favorita y usa también
    base de datos para registrar los accesos, así evitarás que algun
    malintencionado manipule una cookie y pueda entrar.

    La regla debería ser: Si no tiene cookie, le pides nombre y clave y si
    acierta, se la pones. Si la tiene, compruebas su validez contrastando con la
    base de datos, finalmente si todo está ok sigues con la págia y si hay
    errores le mandas al formulario de autentificación. (o le haces un
    header("location= http://www.... ") o un exit;)
    Este metodo me parece un poco ineficiente, ya que para cada pagina que
    visita el cliente se tiene que llamar a la base de datos. Un metodo
    mucho mas sencillo e igualmente seguro viene usando variables de
    session. Por ejemplo:

    login.php
    <?php
    if (se ha validado en la BD){
    session_start();
    session_register("login");
    }
    ?>

    secure.php
    <?php
    session_start();
    if (!session_is_registered("login"))
    die ("Debe validarse");
    ?>

    En tus paginas, al principio del todo (incluso antes que cualquier
    codigo HTML):

    <?php
    include ("secure.php");
    ?>

    Saludos,

    Tomas V.V.Cox
  • Devta at Jan 28, 2001 at 12:18 am

    Tomas V.V.Cox dixit:
    Este metodo me parece un poco ineficiente, ya que para cada pagina que
    visita el cliente se tiene que llamar a la base de datos. Un metodo
    mucho mas sencillo e igualmente seguro viene usando variables de
    session. Por ejemplo:
    Estoy de acuerdo, puedes autentificar contra la BD al principio y luego
    seguir con variables de sesion, pero si no tienes PHP4 tinenes que implantar
    PHPLIB o similar, lo decía por eso.

    Devta
  • Pablo Godel at Jan 29, 2001 at 2:31 pm
    No te parece que al saltear el paso de chequear con la base de datos queda medio
    vulnerable la seguridad? Las sesiones por lo general trabajar con un cookie,
    seteando un valor al azar, pero si no comprobas ese valor con algo guardado en la
    base de datos, ese valor puede ser cualquier cosa y puede ser puesto a mano.

    Que opinan?

    Saludos,
    Pablo Godel

    "Tomas V.V.Cox" wrote:
    Este metodo me parece un poco ineficiente, ya que para cada pagina que
    visita el cliente se tiene que llamar a la base de datos. Un metodo
    mucho mas sencillo e igualmente seguro viene usando variables de
    session. Por ejemplo:
  • Tomas V.V.Cox at Jan 29, 2001 at 2:42 pm

    Pablo Godel wrote:

    No te parece que al saltear el paso de chequear con la base de datos queda medio
    vulnerable la seguridad? Las sesiones por lo general trabajar con un cookie,
    seteando un valor al azar, pero si no comprobas ese valor con algo guardado en la
    base de datos, ese valor puede ser cualquier cosa y puede ser puesto a mano.

    Que opinan?
    Las variables se sesión se guardan en el servidor y no son manipulables
    por el cliente. Lo único que el cliente puede manipular es su ID de
    sesión, bien cambiando el cookie, bien cambiado la url, pero nunca el
    valor de las variables.
    Supongo que habrás visto la forma que tiene una variable de sesión, (que
    sin ser muy docto) creo que son alrrededor de 32 caracteres
    alfanuméricos. En 100 años con 100 personas probando dudo que
    consiguieras acertar con alguna de los IDs de sesión que algún cliente
    esté usando en ese preciso momento. Aún así y si eres muy paranóico, hay
    un truco muy bueno para evitar el "robo" de variables de sesión: Cuando
    alguien se logea, una de las variables de sesión que creas es la Ip de
    la persona, y en cada página compruebas que la Ip del visitante es la
    misma Ip que tienes guardada.

    Saludos,

    Tomas V.V.Cox

    Saludos,
    Pablo Godel

    "Tomas V.V.Cox" wrote:
    Este metodo me parece un poco ineficiente, ya que para cada pagina que
    visita el cliente se tiene que llamar a la base de datos. Un metodo
    mucho mas sencillo e igualmente seguro viene usando variables de
    session. Por ejemplo:
    ---------------------------------------------------------------------
    Archivo On-line: http://www.phpes.com/
    Manual PHP en español: http://www.php.net/manual/es/
    Para dar de baja la suscripción, mande un mensaje a:
    lista-unsubscribe@phpes.com
  • Devta Singh at Jan 29, 2001 at 3:14 pm
    De todos modos no creo que lo de los 100 años con 100 personas sea muy
    científico, creo recordar que hace uno o dos años un grupo de maquinas
    conectadas consiguieron romper (acertar) una clave RSA cuando iban por el
    24% de las posibilidades.

    Es cuestión de estadística, digamos 32 caracteres tomado de entre 32
    caracteres alfanuméricos (por decir algo) son: ¡¡¡CIELOS:
    1,4615016373309029182036848327163e+48!!!

    Bueno, efectivamente es difícil, al fin y al cabo si tienes
    100 maquinas intentanto 100 combinaciones por segundo, durante 1 año son
    864000000 combinaciones con lo cual tardarías unos
    1,6915528209848413405135241119401e+39 días es decir:
    4,6343912903694283301740386628497e+36 años, bueno como diría un sabio
    oriental, es mucho tiempo para un mosquito, poco para una montaña y nada
    para el universo.

    Solo que no somos una montaña, sino más bien un mosquito evolucionado...
    ------------------------------------------------------
    Devta Singh
    Webmaster ZDNet España
    devta@zdnet-es.com
    ------------------------------------------------------
  • Tomas V.V.Cox at Jan 29, 2001 at 9:41 pm

    Devta Singh wrote:

    De todos modos no creo que lo de los 100 años con 100 personas sea muy
    científico, creo recordar que hace uno o dos años un grupo de maquinas
    conectadas consiguieron romper (acertar) una clave RSA cuando iban por el
    24% de las posibilidades.
    Si, tienes razon, pero en ese caso era diferente, había que descubrir
    una contraseña (www.distributed.net). Una variable se sesión es algo así
    como el md5(uniq(rand())).
    Bueno, efectivamente es difícil, al fin y al cabo si tienes
    100 maquinas intentanto 100 combinaciones por segundo, durante 1 año son
    864000000 combinaciones con lo cual tardarías unos
    1,6915528209848413405135241119401e+39 días es decir:
    4,6343912903694283301740386628497e+36 años, bueno como diría un sabio
    oriental, es mucho tiempo para un mosquito, poco para una montaña y nada
    para el universo.
    Se te escapan un par de detalles importantes:
    - Las variables de sesion expiran cada tanto tiempo de inactividad, por
    lo tanto debería hayar una en ese tiempo
    - Para probar debes hacer una petición al server web, si haces toda esa
    cantidad de pruebas hay que ser un administrador de sistemas muy burro
    para no darse cuenta del "ataque masivo" que está sufriendo.

    Por lo tanto no creas que es tan descabellado que pase ese tiempo, si se
    tienen en cuenta estas dos reglas. Aun así ya comenté en el anterior
    mail el método de almacenar la IP para evitar el robo ("hijaking" o como
    narices se escriba :) de sesiones.
    Antes de intentar robar una sesión un hacker intentaría poner un snifer,
    acceder a la BD del server, modificar el código php, etc.
    Solo que no somos una montaña, sino más bien un mosquito evolucionado...
    Ese yoga que destila por tus poros :)

    Saludos,

    Tomas V.V.Cox
  • Pablo A. Godel at Jan 29, 2001 at 10:10 pm
    Hay que tener en cuenta en este punto que algunos ISPs (como por
    ejemplo AOL) por cada pedido HTTP utilizan distintos IP debido a
    sistema de proxies. Me ha pasado de tener problemas con las sesiones
    y tuve que remover la parte de chequeo de IPs porque cada request de
    AOL venia de un IP distinto.

    Saludos,
    Pablo Godel

    Quoting "Tomas V.V.Cox" <cox@idecnet.com>:
    Por lo tanto no creas que es tan descabellado que pase ese tiempo, si
    se
    tienen en cuenta estas dos reglas. Aun así ya comenté en el anterior
    mail el método de almacenar la IP para evitar el robo ("hijaking" o
    como
    narices se escriba :) de sesiones.
  • Devta at Jan 29, 2001 at 11:17 pm
    Si, claro que lo de pillar una clave de acceso es distinto a "secuestrar"
    (para ser puntillosos, seamoslo del todo) una sesion y claro habría que
    hacerlo antes de que fenezca.

    Pero simplemente puse los datos convencido de que no serían tanto tiempo y
    luego me quedé mudo, por eso los puse, una cura de humildad.

    ;-)

    -----------------------------------------------------------
    Devta Singh
    devta@yogakundalini.com

    www.yogakundalini.com
    La página de Yoga Kundalini en español
    -----------------------------------------------------------
  • Ruyman at Jan 31, 2001 at 9:30 am
    Buenos días a todos:

    Estoy trabajando con php contra Informix en un RH y tengo una duda.
    Resulta que hago una select algo compleja para mostrar un listado
    paginado(de 1 a 300 registros paginados de 20 en 20), pero el Informix se me
    pega mínimo 10 seg. para sacarme el resultado. Además cada vez que le doy a
    "siguiente" o "anterior" ejecuto la select otra vez, con lo que desplazarte
    por los registros puede llegar a ser desesperante (y eso que estoy en
    local). Mi pregunta es:

    ¿Si hago una conexión permanente a la base de datos, puedo pasar el cursor
    que me retorna la select como paramentro a las páginas siguientes para no
    tener que volver a ejecutarla?
  • Pablo Godel at Jan 31, 2001 at 1:58 pm
    No creo que funcione, ya que cuando cierres la ejecucion del primer script php
    que realiza la consulta sql, perderas el resultado de la misma.

    Una tecnica que puede servir, es guardar los IDs del resultado (todos los IDs de
    las filas que el select te dio) en una tabla y luego desplazarse por esos IDs
    unicamente sin hacer toda la consulta extensa.

    Saludos,
    Pablo Godel

    Ruyman wrote:
    Buenos días a todos:

    Estoy trabajando con php contra Informix en un RH y tengo una duda.
    Resulta que hago una select algo compleja para mostrar un listado
    paginado(de 1 a 300 registros paginados de 20 en 20), pero el Informix se me
    pega mínimo 10 seg. para sacarme el resultado. Además cada vez que le doy a
    "siguiente" o "anterior" ejecuto la select otra vez, con lo que desplazarte
    por los registros puede llegar a ser desesperante (y eso que estoy en
    local). Mi pregunta es:

    ¿Si hago una conexión permanente a la base de datos, puedo pasar el cursor
    que me retorna la select como paramentro a las páginas siguientes para no
    tener que volver a ejecutarla?

    ---------------------------------------------------------------------
    Archivo On-line: http://www.phpes.com/
    Manual PHP en español: http://www.php.net/manual/es/
    Para dar de baja la suscripción, mande un mensaje a:
    lista-unsubscribe@phpes.com
  • Andrés Said Bazurto Solarte at Jan 31, 2001 at 2:53 pm
    Hola

    Ruyman wrote:
    Buenos días a todos:

    ¿Si hago una conexión permanente a la base de datos, puedo pasar el cursor
    que me retorna la select como paramentro a las páginas siguientes para no
    tener que volver a ejecutarla?
    Segun entiendo, la consulta simepre la debes hacer, aunque la conexion
    perdsistente te evita el tener que abrir/cerrar la conexion a lDB y eso gana
    tiempo.

    yo en mis consultas X lo general hago lo siguietne:
    1. Hago un select count de la tabla ($found)
    2. Uso un posicionador de registro, el cual arranca en 0 (lo llamare $skip)
    luego hago un select limit $skip, $max donde $max es el # de registros que
    quiero obtener
    3. Genero $prev = $skip - $max y $next = $skip + $max
    aqui hay que tener en cuenta que si ($prev < 0) no genero link a anterior y
    si ($next > $found) no genero link siguiente
    4. si deseo paginar entonces hago un ciclo como este:
    $pages=$found / $max
    if ($found % $max != 0) { ++$pages}
    for ($i=1;$i<=$pages; $i++)
    {
    echo $data;$i <--- $data seria el skip para la pagina, $i el # de la pagina
    $data += $max;
    }

    Si alguien conoce una forma mas optima por favor me cuenta y con gusto cambiare
    mis codigos

    Saludos

    A. Said Bazurto S.
    PHP DeV (desempleado y buscando)
  • Antonio Salom Palliser at Jan 31, 2001 at 3:38 pm

    El Wed, 31 Jan 2001, escribiste:
    Hola

    Ruyman wrote:
    Buenos días a todos:

    ¿Si hago una conexión permanente a la base de datos, puedo pasar el cursor
    que me retorna la select como paramentro a las páginas siguientes para no
    tener que volver a ejecutarla?
    Segun entiendo, la consulta simepre la debes hacer, aunque la conexion
    perdsistente te evita el tener que abrir/cerrar la conexion a lDB y eso gana
    tiempo.

    yo en mis consultas X lo general hago lo siguietne:
    1. Hago un select count de la tabla ($found)
    2. Uso un posicionador de registro, el cual arranca en 0 (lo llamare $skip)
    luego hago un select limit $skip, $max donde $max es el # de registros que
    quiero obtener
    3. Genero $prev = $skip - $max y $next = $skip + $max
    aqui hay que tener en cuenta que si ($prev < 0) no genero link a anterior y
    si ($next > $found) no genero link siguiente
    4. si deseo paginar entonces hago un ciclo como este:
    $pages=$found / $max
    if ($found % $max != 0) { ++$pages}
    for ($i=1;$i<=$pages; $i++)
    {
    echo $data;$i <--- $data seria el skip para la pagina, $i el # de la pagina
    $data += $max;
    }

    Si alguien conoce una forma mas optima por favor me cuenta y con gusto cambiare
    mis codigos

    Saludos

    A. Said Bazurto S.
    PHP DeV (desempleado y buscando)


    ---------------------------------------------------------------------
    Archivo On-line: http://www.phpes.com/
    Manual PHP en español: http://www.php.net/manual/es/
    Para dar de baja la suscripción, mande un mensaje a:
    lista-unsubscribe@phpes.com
    Si no lo he entendido mal, sigues realizando la busqueda cada vez que
    se visita la página, no? La idea me parece buena, pero sigue siendo lento.

    Yo también tuve ese problema en una ocasión. Lo que hice fue fijarme en
    los índices. Tienes que intentar tener un índice para todas las claves foraneas
    que utilizas en la 'select'; es decir, tener índices en cada atributo que
    tengas detras del 'where'.
    Si no te sirve puedes intentar una cosa parecida a lo que ha dicho
    Pablo Godel, y guardar todos los resultados en una tabla y guardarla como
    variable de sesión. Ten cuidado con esta opción porque podrías saturar la
    memoria del servidor. Otra solución consiste en guardar solo 50, y mirar si se
    tiene que volver a buscar o la página actual ya está calculada. En el segundo
    caso no será necesario ni acceder a BBDD. Por otro lado si tienes muchas
    visitas podrías saturar el servidor.
  • Andrés Said Bazurto Solarte at Jan 31, 2001 at 4:20 pm
    >

    Holas
    Si no lo he entendido mal, sigues realizando la busqueda cada vez que
    se visita la página, no? La idea me parece buena, pero sigue siendo lento.
    mmmm esa no me la sabia epnse que al hacer la consulta para un limite el solo buscaba
    esos no mas pero veo logica en lo que dices
    Yo también tuve ese problema en una ocasión. Lo que hice fue fijarme en
    los índices. Tienes que intentar tener un índice para todas las claves foraneas
    que utilizas en la 'select'; es decir, tener índices en cada atributo que
    tengas detras del 'where'.
    de hecho por lo general tengo indexadas mis tablas segun los criteiros de busqueda :)
    y para elelmentos muy grnades o muchosmiles registros uso entonces views
    Si no te sirve puedes intentar una cosa parecida a lo que ha dicho
    Pablo Godel, y guardar todos los resultados en una tabla y guardarla como
    variable de sesión. Ten cuidado con esta opción porque podrías saturar la
    memoria del servidor. Otra solución consiste en guardar solo 50, y mirar si se
    tiene que volver a buscar o la página actual ya está calculada. En el segundo
    caso no será necesario ni acceder a BBDD. Por otro lado si tienes muchas
    visitas podrías saturar el servidor.
    entiendo, pero me parece un tanto peligroso esa forma por el consumo de memoria y lo
    que estas enviando/recibiendo

    Salu2 :)

    A. Said Bazurto
    (aun sigo desempleado)
  • Antonio Salom Palliser at Jan 31, 2001 at 4:35 pm

    El Wed, 31 Jan 2001, escribiste: Holas
    Si no lo he entendido mal, sigues realizando la busqueda cada vez que
    se visita la página, no? La idea me parece buena, pero sigue siendo lento.
    mmmm esa no me la sabia epnse que al hacer la consulta para un limite el solo buscaba
    esos no mas pero veo logica en lo que dices
    Yo también tuve ese problema en una ocasión. Lo que hice fue fijarme en
    los índices. Tienes que intentar tener un índice para todas las claves foraneas
    que utilizas en la 'select'; es decir, tener índices en cada atributo que
    tengas detras del 'where'.
    de hecho por lo general tengo indexadas mis tablas segun los criteiros de busqueda :)
    y para elelmentos muy grnades o muchosmiles registros uso entonces views
    Si no te sirve puedes intentar una cosa parecida a lo que ha dicho
    Pablo Godel, y guardar todos los resultados en una tabla y guardarla como
    variable de sesión. Ten cuidado con esta opción porque podrías saturar la
    memoria del servidor. Otra solución consiste en guardar solo 50, y mirar si se
    tiene que volver a buscar o la página actual ya está calculada. En el segundo
    caso no será necesario ni acceder a BBDD. Por otro lado si tienes muchas
    visitas podrías saturar el servidor.
    entiendo, pero me parece un tanto peligroso esa forma por el consumo de memoria y lo
    que estas enviando/recibiendo

    Salu2 :)

    A. Said Bazurto
    (aun sigo desempleado)


    ---------------------------------------------------------------------
    Archivo On-line: http://www.phpes.com/
    Manual PHP en español: http://www.php.net/manual/es/
    Para dar de baja la suscripción, mande un mensaje a:
    lista-unsubscribe@phpes.com
    Si con todo esto no te basta, tu busqueda será verdaderamente muy
    complicada. Este es un buen punto para que te plantees preguntas como:
    - ¿Realizas bien la busqueda?
    - ¿Existirían métodos más eficientes de realizar la busqueda?
    - ¿Es realmente necesaria?

    Ten en cuenta que si esta busqueda la puede realizar cualquier usuario,
    a la mínima que tengas 10 o 12 usuarios, puedes tener tu servidor por los
    suelos sin responder. Y también un ataque de denegación de servicio sería
    facilisimo de realizar.
  • Andrés Ferrando at Jan 31, 2001 at 6:05 pm
    Si querés complicar un poco la lógica del programa podés hacer esto:
    1. Guardás en una tabla la siguiente info: los datos recuperados, y como
    primary key el identificador de sesión.
    2. Cuando quiere ver los siguientes, los sacás de ahí, por el SID.
    3. Cuando sale, (o cada cierto tiempo con un script) limpias esa tabla.

    Con esto harías una sola vez esos querys hiper complicados :-)


    El Wed, 31 Jan 2001 16:36:09 +0100
    Antonio Salom Palliser <asalom@wanadoo.es> escribió:
    El Wed, 31 Jan 2001, escribiste:
    Holas
    Si no lo he entendido mal, sigues realizando la busqueda cada vez que
    se visita la página, no? La idea me parece buena, pero sigue siendo lento.
    mmmm esa no me la sabia epnse que al hacer la consulta para un limite el solo buscaba
    esos no mas pero veo logica en lo que dices
    Yo también tuve ese problema en una ocasión. Lo que hice fue fijarme en
    los índices. Tienes que intentar tener un índice para todas las claves foraneas
    que utilizas en la 'select'; es decir, tener índices en cada atributo que
    tengas detras del 'where'.
    de hecho por lo general tengo indexadas mis tablas segun los criteiros de busqueda :)
    y para elelmentos muy grnades o muchosmiles registros uso entonces views
    Si no te sirve puedes intentar una cosa parecida a lo que ha dicho
    Pablo Godel, y guardar todos los resultados en una tabla y guardarla como
    variable de sesión. Ten cuidado con esta opción porque podrías saturar la
    memoria del servidor. Otra solución consiste en guardar solo 50, y mirar si se
    tiene que volver a buscar o la página actual ya está calculada. En el segundo
    caso no será necesario ni acceder a BBDD. Por otro lado si tienes muchas
    visitas podrías saturar el servidor.
    entiendo, pero me parece un tanto peligroso esa forma por el consumo de memoria y lo
    que estas enviando/recibiendo

    Salu2 :)

    A. Said Bazurto
    (aun sigo desempleado)


    ---------------------------------------------------------------------
    Archivo On-line: http://www.phpes.com/
    Manual PHP en español: http://www.php.net/manual/es/
    Para dar de baja la suscripción, mande un mensaje a:
    lista-unsubscribe@phpes.com
    Si con todo esto no te basta, tu busqueda será verdaderamente muy
    complicada. Este es un buen punto para que te plantees preguntas como:
    - ¿Realizas bien la busqueda?
    - ¿Existirían métodos más eficientes de realizar la busqueda?
    - ¿Es realmente necesaria?

    Ten en cuenta que si esta busqueda la puede realizar cualquier usuario,
    a la mínima que tengas 10 o 12 usuarios, puedes tener tu servidor por los
    suelos sin responder. Y también un ataque de denegación de servicio sería
    facilisimo de realizar.

    ---------------------------------------------------------------------
    Archivo On-line: http://www.phpes.com/
    Manual PHP en español: http://www.php.net/manual/es/
    Para dar de baja la suscripción, mande un mensaje a:
    lista-unsubscribe@phpes.com
    --
    Andrés Ferrando <pruna@sinectis.com.ar>
  • Xabi Ochotorena at Jan 31, 2001 at 5:03 pm
    Hola Andrés,

    ASBS> 1. Hago un select count de la tabla ($found)
    ASBS> 2. Uso un posicionador de registro, el cual arranca en 0 (lo llamare $skip)
    ASBS> luego hago un select limit $skip, $max donde $max es el # de registros que
    ASBS> quiero obtener

    El problema es que la consulta se ejecuta igual y lo que es peor,
    "limit" no es SQL estandard. La mejor idea que he visto al respecto es
    generar una tabla temporal (en mysql, en otras BD's puedes usar
    vistas) con los resultados y luego hacer una consulta sobre la tabla
    temporal.

    ASBS> Si alguien conoce una forma mas optima por favor me cuenta y con gusto cambiare
    ASBS> mis codigos

    Lo mismo digo :)

    --
    Saludos,
    Xabi xochotorena@arista.es
  • Miquel piulats at Jan 31, 2001 at 1:05 am
    Necesito que los clientes puedan imprimir unas paginas generadas a partir de
    una base de datos, pero me gustaria saber si hay alguna forma de controlar
    esa impresion para que el explorador no imprimas mas informacion que la que
    sale por pantalla.

    Saludos.
  • Antonio Salom Palliser at Jan 31, 2001 at 3:23 pm

    El Mon, 29 Jan 2001, escribiste:
    Necesito que los clientes puedan imprimir unas paginas generadas a partir de
    una base de datos, pero me gustaria saber si hay alguna forma de controlar
    esa impresion para que el explorador no imprimas mas informacion que la que
    sale por pantalla.

    Saludos.
    El cliente solo puede imprimir la información que sale por pantalla y
    la que está en el código fuente. Si no quieres que se impriman los números de
    las tarjetas de crédito en un listado de clientes no se los envies, y ya está.
  • Norberto Lanosa [hogarenlaweb.com.ar] at Jan 25, 2001 at 3:29 pm

    - Imposibilitar que los usuarios se bajen los archivos fuente (.php) , es
    decir , ocultarlos.
    El servidor nunca devuelve la fuente de los php.
    - Y si fuese posible ,que los usuarios no pudieran ver el contenido html de
    las páginas devueltas por el servidor.
    ¿y eso que sentido tiene? el html no es gran cosa... Pero lo único que se me
    ocurre es que proceses todo en un archivo .PDF y muestres eso en el browser,
    pero te quita muchas opciones.

    Dese mi ignorancia.... ;-)
    Norberto
  • Juan Luca de Tena Riveiro at Jan 25, 2001 at 4:26 pm
    ----- Original Message -----
    From: "Norberto Lanosa [hogarenlaweb.com.ar]" <ncl@data54.com>
    To: <lista@phpes.com>; <practicas1@vallduixo.infoville.net>
    Sent: Thursday, January 25, 2001 3:15 PM
    Subject: Re: [PHP-ES] Mantenimiento de la seguridad

    - Imposibilitar que los usuarios se bajen los archivos fuente (.php) ,
    es
    decir , ocultarlos.
    El servidor nunca devuelve la fuente de los php.
    "El segundo de los problemas se da en entornos con múltiples hosts virtuales
    y se produce debido a la característica de PHP de inhabilitar su
    funcionamiento en alguno de dichos entornos. Debido a un bug en el módulo
    para Apache de PHP, si uno o más hosts virtuales dentro de un único servidor
    Apache se configuran con la opción "engine=off", este valor se propagará al
    resto de los hosts virtuales. Como resultado de esta acción se dejarán de
    ejecutar los scripts PHP, por lo que el código fuente de las páginas se
    visualizará en los clientes web."

    Publicado en http://www.hispasec.com/unaaldia.asp?id=814 el 16 de enero de
    2001

Related Discussions

People

Translate

site design / logo © 2022 Grokbase