¿Qué es el "?" símbolo en URL utilizado en php?


10

Soy nuevo en PHP. En el camino de aprendizaje del lenguaje PHP, noto que, algún sitio web haría este tipo de URL:

www.website.com/profile.php?user=roa3 & ...

Mis preguntas:

  1. ¿Qué es "?" símbolo utilizado para?

  2. Si tuviera un sitio web de php, ¿debo usarlo en mi URL? Por ejemplo, después de un usuario (Roa3) exitosa iniciada la sesión, voy a redirigir a "www.website.com/profile.php?user=roa3" en lugar de "www.website.com/profile.php"

  3. ¿Cuáles son las ventajas y desventajas de usarlo?

21

buenas preguntas, brevemente,

  1. "?" significa el inicio de la consulta cadena que contiene los datos que se pasado al servidor. en este caso está pasando user = roa3 a profile.php page. Puede obtener los datos utilizando $ _GET ['user'] dentro de profile.php. querystring es uno de los métodos para enviar datos al servidor desde el agente del cliente. El otro coloca los datos en el cuerpo HTTP y POST en el servidor, usted no ve los datos HTTP POST directamente desde el navegador.

  2. querystring puede ser editado por el usuario y es visible al público. Si www.website.com/profile.php?user=roa3 está destinada a ser pública, entonces es bien, de lo contrario es posible que desee utilizar sesión para obtener contexto del usuario actual.

  3. es una forma flexible para pasar datos a el servidor, pero es visible y editable a los usuarios, para algunos datos sensibles, al menos producir algún tipo de hachís antes de colocar a la cadena de consulta , esto evita que los usuarios de lo editen o entiendan el significado de este. Sin embargo, este no impide que un hacker decente haga algo mal con respecto a su sitio web . Diferentes navegadores soportan diferentes longitudes máximas de URL, la larga URL está formada por esos parámetros de cadena de consulta. Si desea enviar una gran cantidad de datos, coloque los datos en el cuerpo HTTP y POST en el servidor.


0

Desde el punto de vista del servidor,? es solo otro personaje. PHP proporciona métodos fáciles para partes de la URL después de? personaje, p. para "/profile.php?user=roa3", PHP establecerá $ _GET ['user'] = 'roa3'.

¿La razón? es útil en las URL es que los navegadores pueden construir URL dinámicas usando formularios; en el caso anterior, esperaría que la URL se creara mediante un formulario HTTP con un campo "usuario", en el que el usuario humano haya tecleado "roa3".

  0

Esto está mal. Los "?" no es "solo otro personaje" para el servidor. El servidor divide la URL en "?" (si hay uno). La parte anterior es el archivo solicitado, y la parte posterior es la "cadena de consulta", presentada al CGI como la variable de entorno QUERY_STRING. 22 feb. 092009-02-22 07:14:31

+1

Probablemente debería haber dicho que los servidores * en general * no se espera que lo traten especialmente. En el caso de PHP (y la mayoría de los otros marcos web), se proporciona algún tratamiento, como lo discutí. La pregunta no especifica CGI en ninguna parte. 22 feb. 092009-02-22 07:46:21

+1

Puede no ser especial para el servidor, pero es parte del estándar HTTP en lugar de php. 22 feb. 092009-02-22 08:34:06

  0

Manteniéndose obstinadamente en mis pistolas aquí :-) ¿Hay solo una distinción efectiva de? en RFC21616, S13.9: "las memorias caché no deben tratar las respuestas a [URI de consulta] como nuevas a menos que el servidor proporcione un tiempo de caducidad explícito". Eso apenas parece relevante. 22 feb. 092009-02-22 09:20:46

+1

De acuerdo, cuatro votos a favor por una respuesta fundamentalmente correcta (con una pequeña advertencia) son ciertamente excesivos y marcarlo ofensivo es puramente ... ¡bueno, ofensivo! 22 feb. 092009-02-22 10:59:14


0
  1. "?"se usa para separar el URL y los parámetros. Por ejemplo, es como http://www.url.com/resourcepath?a=b&c=d. En este caso a = b es como request_parameter = request_value.

  2. Ya, No es recomendable usar muchos de los parámetros porque el total El tamaño de la url es limitado y es como la solicitud GET, donde todos los parámetros se muestran en la url y el usuario puede modificarla. En su ejemplo, indique qué pasa si un usuario modifica la url a "usuario = techmaddy".

  3. La ventaja es que se puede utilizar para el tipo de solicitudes GET. La desventaja es baja seguridad, limitación de tamaño.


4

1) Si un usuario inicia sesión en su sitio, se utilizarían Sessions para almacenar allí nombre de usuario en lugar de pasarlo en el ejemplo url profile.php?username=roa3

2) El uso de un símbolo ? en las URL generalmente se consideran malas para Search Engine Optimization. Además, las URL se ven un poco feas. Con mod_rewrite puede hacer lo mismo que profile.php?user=roa3 o products.php?id=123&category=toys con: site.com/profile/roa3 o products/toys/123.

El uso del marco CodeIgniter le dará URL amigables por defecto y eliminará la necesidad de ? s en sus direcciones URL. Ver this page para un ejemplo.

3) El símbolo ? también se utiliza dentro del código de una página php. Por ejemplo, un if else bloque tales como:

if ($x==1) 
    $y=2; 
else 
    $y=3; 

también se puede escribir como: "?"

$y=($x==1) ? 2 : 3; 

3

El significa que algunas variables GET deben seguir. Tu ejemplo usa una variable llamada "usuario" y asigna una variable llamada "roa3".

Ventajas del uso de las variables GET:

  • que se pueden marcar como parte de la URL

Desventajas

  • son públicos .. Cualquier persona puede interceptar y ver esta información . Estas solicitudes de URL incluso son almacenadas en caché por los servidores a lo largo del viaje. Por lo que cualquiera puede hacerse pasar por el usuario Roa3 con tan sólo escribir esa información en la mano ... también podrían cambiar la Roa3 a un usuario diferente y hacerse pasar por ellos ..

también puede utilizar un símbolo "&" para separar muchas variables, por ejemplo: www.website.com/profile.php?user=roa3&fav_colour=blue

Otras opciones:

  • variables POST

    • Puede enviar sus variables a través de las variables POST.Estas variables se pasan en el encabezado de la solicitud, no en la url de la solicitud. no son inmediatamente obvios, y los servidores no los guardan en la memoria durante el viaje, pero aún se pueden leer. a menos que tenga una conexión HTTPS establecida.
    • Las variables en un formulario se pueden enviar mediante métodos POST o GET. Especifique esto en el "método" del formulario. <form action="index.php" method='post'/>
  • variables de sesión

    • Las variables de sesión se almacenan en el servidor. Se pasa una identificación de sesión al usuario, y esta identificación de sesión se devuelve al servidor cada vez que el usuario realiza otra solicitud. Esta identificación de sesión se puede usar para obtener las variables de sesión que se almacenaron. Por lo tanto, podría almacenar el color favorito de un usuario, su nombre y dirección IP, etc., pero podría almacenarlo en el servidor en lugar de en la computadora del hogar del usuario.
      Los identificadores de sesión se pueden suplantar, por lo que es bueno verificarlos contra la IP del usuario o para envolverlos en una conexión segura. por ejemplo, https.
    • Las variables de sesión no pueden ser cambiadas por alguien que haya interceptado la solicitud.
  • variable de cookie:
    similares a las variables de sesión, excepto que se almacenan en el ordenador del usuario, no el servidor. Se almacenan contra un dominio, y cuando van a ese dominio, vuelven a enviar las variables en el encabezado de la solicitud al servidor ... esto significa que el usuario podría cambiar y piratear las variables, o que alguien más podría hacerlo.

Para acceder a estas variables en PHP que puede utilizar:

  • $x = $_GET['user'] de obtener la variable
  • $x = $_POST['user]
  • $x = $_REQUEST['user'] - la combinación de GET, POST y de la galleta variables de
  • $x = $_COOKIE['user'] - variables de cookie
  • $x = $_SESSION['user'] para acceder a las variables de sesión

(user se podría sustituir por el nombre de la variable que está utilizando)

cosas bastante simple, pero importante saber lo que realmente hacen.

+1

La comprobación de id. De sesión contra IP no es tan buena si las personas se sientan detrás de una granja de servidores proxy con varias direcciones IP. Además, aquellos que comparten un proxy aún no estarían protegidos de otro. La aplicación tiene que manejar esto de otra manera: si maneja datos confidenciales: use https. 22 feb. 092009-02-22 08:22:07

  0

sí, eso es cierto. Controlar las sesiones de ip daría mayor seguridad, pero dejaría algunos agujeros grandes. Establecer la sesión después de que se haya establecido https es siempre la más segura. 22 feb. 092009-02-22 09:41:42

  0

Solo una nota al margen: es legal usar ';' para separar vars GET también. Aunque nunca lo he visto y, por lo tanto, no lo recomendaría. 06 may. 102010-05-06 07:35:19


6

La mayoría de las respuestas que he visto hasta ahora han sido en términos de PHP, cuando en realidad esto no es específico de un idioma. Las respuestas dadas hasta ahora han sido desde la vista de PHP y los métodos que usaría para acceder a la información difieren de un idioma al siguiente, pero el formato en el que se encuentran los datos en la URL (conocido como la Cadena de consulta) permanecerá lo mismo (Ej: página.ext? clave1 = valor & clave2 = valor & ...).

No sé su formación técnica o conocimiento, por lo que por favor, perdóname ...

Hay dos métodos diferentes para una página web para proporcionar datos al servidor web. Estos se conocen como los métodos POST o GET. También hay un montón de otros, pero ninguno de ellos debe utilizarse en ningún tipo de diseño web cuando se trata de un usuario normal.El método POST se envía de forma invisible al servidor y está destinado a "cargar" datos, mientras que el método GET es visible para el usuario como la Cadena de consulta en la URL y solo pretende "obtener" información literalmente.

No todos los sitios siguen esta regla de oro, pero puede haber motivos de por qué. Por ejemplo, un sitio podría usar POST exclusivamente para evitar el almacenamiento en caché de los servidores proxy o su navegador, o porque usan lenguajes de doble byte y pueden causar problemas al intentar realizar un GET debido a la conversión de codificación.

Algunos recursos sobre los dos métodos y cuándo usarlos ...

http://www.cs.tut.fi/~jkorpela/forms/methods.html http://weblogs.asp.net/mschwarz/archive/2006/12/04/post-vs-get.aspx http://en.wikipedia.org/wiki/Query_string

Ahora desde una posición estrictamente PHP, ahora hay 3 conjuntos diferentes que puede utilizar para obtener el información que una página web ha enviado al servidor. Usted tiene a su disposición ...

  • $ _POST [ 'nombre de clave'], para agarrar sólo la información de un método POST
  • $ _GET [ 'nombre clave'], para tomar sólo la información de un GET método
  • $ _REQUEST ['keyname'], para permitirle tomar la POST, GET, y cualquier información de COOKIE que pueda haber sido enviada. Una especie de catchall, especialmente en los casos en que no sabes qué método puede utilizar una página para enviar datos.

No te descuides yendo directamente con el método $ _REQUEST. A menos que tenga un caso como el que mencioné anteriormente para la variable $ _REQUEST, entonces no lo use. Desea probar y utilizar un enfoque de 'denegar todo, y solo permitir x, y, z' cuando se trata de seguridad. Solo busque los datos que sabe que su propio sitio enviará, solo busque las combinaciones que espera y borre toda la información antes de usarla. Por ejemplo ..

  • Nunca haga una evaluación() sobre cualquier cosa pasada a través de los métodos anteriores. Nunca he visto esto hecho, pero eso no significa que las personas no lo hayan intentado o lo hayan hecho.
  • Nunca utilice la información directamente con las bases de datos sin limpiar ellos (la investigación de los ataques de inyección SQL si usted no está familiarizado con ellos)

Esto es, con mucho, no es el fin de todo, ser-todo a la seguridad de PHP , pero no estamos aquí para eso. Si quieres saber más a lo largo de la línea, bueno, esa es otra pregunta para SO.

Espero que esto ayude y no dude en hacer cualquier pregunta.

+1

También puede acceder a la información de cookies con $ _COOKIE. 22 feb. 092009-02-22 11:22:23


1

? es parte del estándar HTTP y no es parte de PHP. Pensé que debería señalar eso, así que cuando pasas a otro idioma y vuelves a verlo, no te confundas pensando que PHP está involucrado.

De lo contrario, hay algunas respuestas excelentes arriba.