dependiendo cual sea tu objetivo es la opcion que puedes usar. Get solo te permite pasar datos a otra pagina no mayores de 256 kbs mientras que Post es ilimitada la cantidad que peudes pasar.

Ultimamente Get ha tomado fuerza nuevamente con Ajax debbido a que es su metodo mas usado para la comunicacion entre las paginas de proceso y tus vistas.

Tanto Get como Post viajan por el URL, no te deberia preocupar mucho ese aspecto de la seguridad ya que en el mundo web nada es totalmente seguro, lo que si debes poner atencion es en usar procedimiento en tu base apra las isnerciones, updates, deltes etc. ya que si pasas datos por url y los cachas por consulta directa eres candidato de inyeccion de sql.

Espero te sirva esta info.

Saludos!!!

mira amigo bakuno, si la informacion que vas e enviar al servidor que tendra alojada tu aplicacion web,no es de importancia y no requiere seguridad utiliza get,pero si los datos son confidenciales y requieren mayor seguridad debes utilizar POST ya que a diferencia de get, la informacion no va en el URL si no que se envia despues junto con la info. que se envia a tu aplicacion para que sea procesada.

te recomiendo mejor utilizar java2ee ya que realmente se pueden hacer cosas poderosas a nivel empresarial y al igual que PHP no requiere licencia...pero si te vas iniciando en esto de las aplicaciones web esta bien php bye....

yo te recomendaría que si vas a enviar variables por get trates de utilizar algún tipo de encriptacion pero si las vas a pasar por post no es necesario ya que esas variables el usuario nunca las podrá ver.

si quieres mas información te comparto un libro de php en español es lo mas completo que e encontrado en la web y lo mejor es que esta en español.


http://www.megaupload.com/?d=68AJOUWS

de acuerdo con los post anteriores. Como dato extra te digo que con el addon de firefox "web developer" puedes convertir los POST a GET y viceversa. Asi que si hablamos de seguridad, ambos practicamente carecen de ella.

Para mi es practicamente lo mismo, ya que ambas variables viajan por la web, es decir si ves los 'headers' ahi se ven ambas (POST y GET), ya depende de tu lógica y que quieras hacer con c/u, por ejemplo: no puedes enviar un archivo a través de GET...
Debido a algunos programadores piensan que las variables POST son más seguras truenan los sitios por ese lado.

Gracias por sus respuestas hermanos bakunos, entonces lo que estoy viendo es que ya sea GET o POST son inseguros, entonces que se puede usar???.... o que tan inseguros son no entiendo eso bien :S

get y post da = si te preocupa la seguridad de tu aplicacion sanea tus variables al recibirlas del lado del servidor, googlea un poco sobre como evitar vulnerabilidades en aplicaciones web hay mucho acerca del tema

TIGRE985 dijo:

Gracias por sus respuestas hermanos bakunos, entonces lo que estoy viendo es que ya sea GET o POST son inseguros, entonces que se puede usar???.... o que tan inseguros son no entiendo eso bien :S

Click para expandir ...

https...
Por otra parte la seguridad no depende si ven o no la variable, sino que tu script no acepte códigos o datos que no esten previstos...

nukerkun dijo:

https...
Por otra parte la seguridad no depende si ven o no la variable, sino que tu script no acepte códigos o datos que no esten previstos...

Click para expandir ...

Exacto!! realiza las debidas validaciones al recibir las variables por ejemplo: si el parametro "nombre" que pasa por POST, por alguna razon se altera y llega vacia o con numeros pues habra que mandar un mensaje de error.

Ahora, que si te preocupa que informacion confidencial sea vista, te recomiendo que la uses, si necesitas usan un numero por ejemplo de tarjeta de credito pues realiza una consulta a una base de datos por medio de un id y x ningun motivo la pases en POST o GET, o la guardes en cookies

correcto, te han dado buena infromacion pero, una cosa

el post, es algo menos visible que get

esto es, si tu pagina no tiene problema en que la gente se avive y cambi la url no hay problema. el post, les daria mas trabajo, pero si uno no revisa bien, un campo de texto pr ejemplo, en la validacion de regreso al lado servidor, podrian inyectar sql y yo una vez lo hice, no soy hacker, pero haciendo paginas, descubri esa complicacion en mis propias paginas.

asi llegue a entrar a algunos sitios similares, año 2004 (era en asp y habia sido hecho el año 2001, cunado todavia no se cocia bien el guiso), y entrar al panel de administracion, y hacer travesuras, lo que me valio la amistad de el dueño de la pagina por que le envie la solucion (era victima de ese tipo de abusos), el no sabia nada de programacion y habia conseguido ese sistema donado. pero ahora es mas dificl encontrar esa situacion por que se suele usar sistemas de codigo abierto que no tienen esas vulnerabilidades, o los privativos estan algo mas maduros en ese sentido, mas que el año 99 o 2000

bueno, puedes encriptar, y evitar pasar datos sensibles por url, pero yo he visto navegadores que te muestran el contenido de las varaibles post, es decir de los campos de formulario de el lado navegador

seria facil hacer un codigo fuente, en marcos html, que por javascript manipule los valores de esos campos, asi que debes darle tu logica

yo una vez tuve que agregar un par de campos de formulario cuyo nomre se generaba aleatoriamente, entonces vez que cargaba eran distintos, para evitar un tipo de automatizacion tipo spambot

aun asi, con mas codigo podian, buscar por la metrica, el nombre de el campo pero hubiera dado mucho mas trabajo

el tema es que si miras, el codigo fuente, veras los nombres de eso campos y puedes diseñar un spambot, para eso hay librerias de seguridad, o puedes implementar algo, pero es mejor tener en cuenta lo que mencionan los foristas de pensar bien que datos sensibles, quedan de el lado de el navegador, o de el servidor, en una base de datos

saludos