2008-09-20 17 views
21

Pregunta en el título.

y qué sucede cuando los 3 de $_GET[foo], $_POST[foo]$_COOKIE[foo] exist? y cuál de ellos se incluye para $_REQUEST?

+1

Las variables se sobreescriben de acuerdo con gpc_order en php.ini, también debe acceder a las variables con comillas, como esta: $ _GET ['foo'] –

Respuesta

49

yo diría que no.

Si quisiera que algo se establezca a través de varios métodos, codificaría cada uno de ellos para recordarme a mí mismo que lo había hecho de esa manera; de lo contrario, podría terminar sobrescribiéndolos sin darme cuenta.

¿No debería funcionar así:

$ _GET = no acciones destructivas (clasificación, grabación de acciones, consultas)

$ _POST = acciones destructivas (eliminación, actualización)

$ _COOKIE = configuraciones triviales (preferencias de hojas de estilo, etc.)

$ _SESSION = configuración no trivial (nombre de usuario, ¿inició sesión?, niveles de acceso)

+0

Excelente punto en los métodos GET versus POST, están diseñados para diferentes propósitos. Pocas aplicaciones web funcionan de esa manera estos días, sin embargo ... –

+0

Siempre pensé que la idea era que si usabas para eliminar cosas, entonces los bots podían rastrear esos enlaces y por lo tanto borrar todo en la base de datos ... Parecía una historia de terror , así que siempre me he apegado al esquema anterior. –

+0

Estamos luchando con esto en mi trabajo. Nuestro producto es un sistema CMS que * no * se adhiere a la regla anterior. Nos gustaría proporcionar los dispositivos de Google Mini www.google.com/enterprise/mini/ a nuestros clientes, pero es imposible dejar que rastree una extranet de CMS porque se desataría el infierno:/ –

2

Cuando no estás seguro de dónde se rellenan los valores o cuando se utiliza tanto y desea reproducir indefinidamente todos los valores por ambos métodos POST y GET.

7

A veces es posible que desee que se invoque el mismo script de varias maneras. Me viene a la mente un envío de formulario y una llamada AJAX. En la mayoría de los casos, sin embargo, es mejor ser explícito.

También, vea http://docs.php.net/manual/en/ini.core.php#ini.request-order sobre cómo las diferentes fuentes de variables se sobreescriben si hay una colisión de nombre.

4

$_REQUEST es solo un atajo para evitar que pruebe publicar, obtener y cocinar si los datos pueden provenir de alguno de estos.

hay algunas trampas:

  • datos se toman de GET, POST y COOKIE finalmente. La última anula la primera, así que ten cuidado con eso.
  • arquitecturas REST requieren para separar el POST y GET semántica, no se puede confiar en $_REQUEST en ese caso.

Sin embargo, si usted sabe lo que está haciendo, entonces es sólo otra mano PHP truco.

Lo usaría si quisiera actualizar rápidamente una var que puede venir de varias fuentes. E.G:

  • En su controlador, para decidir qué página servir sin verificar si la solicitud proviene de un formulario de acción o un enlace de hipertexto.
  • Para comprobar si una sesión todavía está activa, independientemente de la forma en que se transmiten las identificaciones de sesión.

1

Uso POST cuando no quiero que las personas tengan fácil acceso a lo que se está pasando y utilizo GET cuando no me importa que vean el valor en la url. Por lo general, no uso cookies por mucho porque creo que SESSION está bien para valores persistentes (aunque tener un registro adecuado es la mejor manera de utilizar eso).

4

Para responder a la pregunta "¿Qué pasa cuando los 3 existen?", La respuesta es "depende".

PHP rellena automáticamente $ _REQUEST según la directiva request_order (o variables_order if request_order ausente) en PHP.INI. El valor predeterminado es generalmente "GPC", lo que significa que primero se carga GET, luego se carga el POST (sobrescribiendo GET si hay una colisión), luego se cargan las cookies (sobrescribiendo get/post si hay una colisión). Sin embargo, puede cambiar esta directiva en el archivo PHP.INI. Por ejemplo, al cambiarlo a "CPG" las cookies se cargan primero, luego se publican y luego se obtienen.

¿En cuanto a cuándo usarlo? Me haré eco del sentimiento de "nunca". Ya no confías en el usuario, entonces ¿por qué darle al usuario más herramientas? Como desarrollador, debe saber de dónde espera que provengan los datos. Se trata de reducir el área de su superficie de ataque.

Cuestiones relacionadas