Nenhuma dessas mudanças devem impactar código PHP moderno. Se de alguma forma você é mordido por qualquer dessas mudanças, as chances são de que seu código de data do PHP 4 era.
O modo seguro foi preterido em PHP 5.3, e agora foi totalmente removido. Modo de Segurança foi um conjunto de controlos de funções de manipulação de muitos arquivos que * tentou * para restringir o acesso com base na propriedade do arquivo. Ele acabou sendo bem mais difícil do que útil, principalmente porque a tentar calçar apoio modo de segurança em extensões alimentados por bibliotecas de terceiros foi uma dor tremenda.
O open_basedir e directivas disable_functions INI não fazem parte do modo de segurança e continuar a existir.
Remoção Modo de Segurança não deve afetar todos os scripts existentes. O caminho normal para verificar o modo de segurança é verificar o resultado de ini_get ('safe_mode'), que agora irá retornar falso como sempre faz quando dado um valor INI inválido. Isto acontece por ser exatamente o mesmo resultado que obteria se o modo de segurança estava desligado.
A configuração INI register_globals foi preterido em PHP 5.3, e agora foi totalmente removido. Quando ativado, seria criar novas variáveis globais de GET, POST e dados de cookies automaticamente. Caminho de volta em tempos pré-históricos, esta PHP ainda mais fácil de pegar para novos usuários. Infelizmente é também uma causa enorme de bugs e problemas de segurança, mesmo no código completamente moderno que nunca invoca. Por exemplo:
function user_is_admin() {
$res = false;
$sth = /* There's a query here. */
if($sth->rowCount()) {
$row = $sth->fetchColumn(0);
$res = !!$row[0];
}
return $res;
}
if(some_other_thing())
$is_admin = user_is_admin();
if($is_admin)
echo "You are an admin!";
Código perfeitamente sensato, certo? Nope.
E se eu chamar o script com uma seqüência de consulta como? Is_admin = 1? Withregister_globals habilitado, o PHP automaticamente criar uma variável chamada $ is_admin e configurá-lo para 1. O código de exemplo acima, nunca inicializa $ is_admin! Se a chamada para some_other_thing () retorna falso, nunca user_is_admin () na verdade é chamado. Porque nunca é chamado, nunca o valor de retorno substitui o valor já dentro $ is_admin.
Oops. Seu usuário tornou-se apenas um administrador por causa de um bug no código que só foi possível graças a register_globals
Esta é apenas uma das muitas razões que todos nós estamos contentes de ver register_globalsmurdered.
Se o seu código ainda conta com ele e você ainda não ter corrigido isso, você está ferrado dez maneiras de domingo e provavelmente deve considerar a atualização do código com os padrões deste século.
import_request_variables () já foi totalmente removido. Ao contrário da maioria das outras funções removidos e configurações, ele não foi substituído.
import_request_variables () permite que você seletivamente importar todos theGET POST / / cookie em matrizes globais, com um prefixo opcional. Você pode conseguir a mesma coisa usando o extrato, se você está determinado a tiro no próprio pé.
A configuração INI register_long_arrays foi preterido em PHP 5.3, e agora foi totalmente removido.
Eu não tenho certeza de quando veio à existência, mas era tanto durante PHP 4 ou tarde no PHP 3. Eu gostaria de pensar que eles eram uma reação ao descobrir que register_globals era uma idéia horrível. Então, o que são eles? Bem, os seus nomes deverão ser do tipo familiar: HTTP_GET_VARS $, $ HTTP_POST_VARS, HTTP_COOKIE_VARS $, $ HTTP_SERVER_VARS, HTTP_ENV_VARS $ e $ HTTP_SESSION_VARS.
É melhor que estar familiarizado! Você pode conhecer seus primos, introduzidas no PHP 4.1: as "curtas" superglobals, $ _GET, $ _POST, $ _COOKIE, $ _SERVER, $ _SESSION _ENVand $.
Os curtas estão hospedados. Os longos estão indo.
Se você ainda tem alguma forma de código que usa estes em produção, você deve ser capaz de fugir com uma busca em massa e substituir e não quebrar nada.
allow_call_time_pass_reference foi preterido em PHP 5.0, emite anE_COMPILER_WARNING em PHP 5.3, e agora foi totalmente removido.
Quando ativado, ele permite que você passar referências em funções que normalmente não esperam-los durante a função de chamar a si mesma. O que isso significa?
i_mangle_your_variable função ($ coisas) {
$ Stuff = strtr (coisas $, 'a', 'A');
return $ coisas;
}
Herp $ = 'aaab';
eco i_mangle_your_variable (& $ herp); / </ - KABOOM
echo $ herp;
A função do mal inesperadamente muda a variável que foi passado. Quando você passar um argumento para ele por referência, ele vai continuar a trabalhar com essa referência diretamente. Em vez de receber de volta uma cópia do seu original, o original ficou desconfigurado.
Este comportamento é terrível e assustador, e eu estou tendo dificuldade em encontrar por que ele nunca existiu. Espero que provavelmente era por causa da maneira como o PHP 4 objetos não foram passados por referência por padrão.
Às vezes você quer passar variáveis para funções como referências. É por isso que o PHP já permite que você declarar uma variável passada como uma referência quando se declara a função:
função i_will_manipulate_your_variable (e outras coisas) {/ * ... * /}
Se o seu código ainda depende de tempo de permanência de passagem por referência, provavelmente você está em apuros. Felizmente este comportamento foi reprovado por idades e emite vários avisos. Você testou seu código com error_reportingcranked todo o caminho, certo? Certo?
define_syslog_variables () ea configuração INI nomes idênticos foram preteridos no PHP 5.3, e agora foi totalmente removido.
Ao usar syslog, você precisa passar um valor que indica a gravidade da mensagem de log. Estes têm sido definida como a * LOG_ conjunto de constantes. Aparentemente, estas nem sempre existe. Esta função parece registar variáveis globais com nomes idênticos aos constantes.
A atualização do código deve ser um simples pesquisa / substitua trabalho. Eu espero.
A configuração INI highlight.bg foi removido completamente. Mais uma vez, nenhum sinal de desaprovação. Por que não? Bem, aparentemente, nunca funcionou. Razão boa o suficiente para a remoção, eu acho.
O session.bug_compat_42 e configurações INI session.bug_compat_warn foram totalmente removidos. Mais uma vez, nenhum sinal de desaprovação. Considerando que é um hack de compatibilidade para PHP 4.2, é provavelmente seguro para remover.
Como parte da batalha contra o register_globals, que foi desligado por padrão no PHP 4.2. Apesar disso, 4,2 deixá-lo acidentalmente criar variáveis globais quando você trabalhou com $ _SESSION. Oops. Infelizmente código no selvagem contou com este comportamento buggy, portanto, a configuração INI.
Se o seu código ainda depende da bug, eu sugiro seppuku ritual.
session_register (), session_unregister () andsession_is_registered (), foram preteridos no PHP 5.3, e já foram totalmente removidos.
Caso você não tenha notado a evisceração metodológica de amigos register_globalsand, em seguida, considerá-lo apontado para você. Esta família de funções foi feito para os maus velhos tempos do PHP 4, onde você iria registrar uma variável global como ligado a uma sessão. Com sessões que vivem dentro de $ _SESSION no mundo moderno, essas funções não têm razão de existir.
Se você ainda dependem dessas funções, o código é podre e você deveria ter vergonha disso. Corrigi-lo. Fixitfixitfixit!
A configuração INI y2k.compliance foi removido completamente.
Eu não estou indo para sugerir uma opção de migração, porque se você desligou-o e em produção como se fosse 1999, você não deveria estar escrevendo código. Você só não deve.
Nenhum comentário :
Postar um comentário