vim /usr/local/cpanel/3rdparty/etc/php.ini
para corrigir os paus do rvsitebuilder, basta localizar as linhas abaixo:
upload_max_filesize — modifique o valor para 105M
max_execution_time — modifique para 180
post_max_size — modifique para 100M ou maior
Isto vai ajustar o problema no mantimento do rvsitebuilder.
gerar backup:
mysqldump –user=USER –password=PASS DBNAME > FILE.SQL
Restaurar:
mysql –user=USER –password=PASS < FILE.SQL
Para limpar o cache de dns pelo console siga os passos abaixo:
iniciar->executar-> cmd
digite: ipconfig /flushdns
Isto irá limpar o cache de dns de sua conexão.
Se você já não sabe o que fazer quanto ao charset, uma saída é criar um arquivo chamado php.ini e dentro dele colocar:
CharsetDisable = On
AddDefaultCharset = ISO-8859-1
#AddDefaultCharset = UTF-8
Isso, possivelmente resolverá
Se você está recebendo esta mensagem de erro, mesmo seguindo os roteiros da MailEnable para o envio de mensagens – se o seu erro é exatamente a mensagem abaixo:
Error Type:
Server object, ASP 0178 (0x80070005)
The call to Server.CreateObject failed while checking permissions. Access is denied to this object.
Para resolver isto, você fará o seguinte:
1 -> Acesse o administrador do IIS em iniciar-> programas -> ferramentas administrativas -> IIS administrator, vá no virtual host deste domínio e procure o arquivo asp que envia o email. Nele, pressione com o botão direito em propriedades e na primeira opção (athentication…) clique em “edit”.
Quando a janela abrir, cole o nome do usuário (deve ser algo do tipo IUSR_nomedousuário).
2 -> Procure (caso tenha o plesk instalado) – c:\program files\swsoft\plesk\mail servers\mailenable\bin e atribua a permissão de ler e executar ao arquivo MEASP.DLL , sendo esta permissão para o usuário que você copiou.
Bem, somente uma dica simples e Beta!
Se você está precisando desabilitar o mod_deflate com php, use a sintaxe abaixo:
apache_setenv('no-gzip', '1');
Isto deverá trabalhar corretamente.
Obs: Isto fica dentro de um script php, PLEASE!
Bem, existe na Web uma infinidade de documentação sobre arrays, e quem sou eu para dizer que a minha é justamente a maior/melhor de todas. Mas já que o assunto é array em php, vamos fazer o seguinte então, vou dar uma explicação sobre arrays multidimensionais com colchetes vazios para você desenvolver com mais “potência” (lol):
Assim como em Javascript, você não precisa declarar que a variável é um
array. Você pode simplesmente chamá-lo colocando um valor…
por exemplo, em vez de dizer:
$a = array();
$a[0] = ‘teste’;
você pode digitar direto:
$a[0] = teste;
não vai ter problema nenhum…
Colocando “[ ]” sem valor, indica que você vai armazenar o valor em um novo
índice do array…
então:
$b[] = ‘oi’;
$b[] = ‘tudo bem’;
Seria o mesmo que armazenar “oi” em 0 e “tudo bem” em um…
Ainda que para muitos não seja tão claro… é mais prático que ficar
declarando um array ou mesmo chamando um array_push();
Outra coisa…
Você pode usar um sem-número de sub-arrays de uma só vez…
<?php
$visitante[][][][] = “teste”;
print_r($visitante);
?>
vai retornar:
Array
(
[0] => Array
(
[0] => Array
(
[0] => Array
(
[0] => teste
)
)
)
)
É o tipo de coisa que os manuais não explicam!
Espero ter ajudado… e quero deixar aqui manifesta a minha alegria em poder
participar deste grupo.
Deixar claro que esta dica já foi repassada de um grande fera em php que eu conheci em um maillist, o o nome do cidadão é:
Thadeu A. Coelho de Paula – <thadeudepaula@gmail.com>
O tutorial de hoje mostra como fazer dinamicamente com php, 3 componentes do tipo select e preenche-los com dias, meses e anos. Deixando selecionada a data atual.
O código é bastante útil para evitar que tenhamos que cria-los e preenche-los.
Vamos ao código.
<?php
$dt_dia = date (”d”);
$dt_mes = date (”m”);
$dt_ano = date (”Y”);
$meses_nomes=Array(1=>”Janeiro”,”Fevereiro”,”Março”,”Abril”,”Maio”,”Junho”,”Julho”,”Agosto”,
“Setembro”,”Outubro”,”Novembro”,”Dezembro”);
echo “<select name=\”dia\”>\n”;
for ($contador=1; $contador <=31; $contador++)
{
if ($dt_dia==$contador)
{
echo “<option value=\””.$contador.”\” selected>”.$contador.”\n”;
}
else
{
echo “<option value=\””.$contador.”\”>”.$contador.”\n”;
}
}
echo “</select>\n”;
echo “<select name=\”mes\”>\n”;
for ($contador=1; $contador <=12; $contador++)
{
if ($st_mes==$contador)
{
echo “<option value=\””.$contador.”\” selected>”.$meses_nomes[$contador].”\n”;
}
else
{
echo “<option value=\””.$contador.”\”>”.$meses_nomes[$contador].”\n”;
}
}
echo “</select>\n”;
echo “<select name=\”year\”>\n”;
for ($contador=1980; $contador <=2010; $contador++)
{
if ($dt_ano==$contador)
{
echo “<option value=\””.$contador.”\” selected>”.$contador.”\n”;
}
else
{
echo “<option value=\””.$contador.”\”>”.$contador.”\n”;
}
}
echo “</select>\n”;?>
O roubo de sessões é, sem sombras de dúvidas, o tipo de ataque mais
comum às sessões. Da mesma maneira da fixação de sessão, se você
utiliza somente o session_start(), você está vulnerável, apesar deste
exploit não ser tão simples.
Ao invés de focar em como evitar que a identificação da sessão seja
capturada, vou focar em como evitar que a captura da id da sessão
traga problemas. O objetivo deste artigo é complicar ao máximo a
personificação, lembrando que cada complicação que aplicamos ao nosso
código aumenta a segurança e frusta o atacante. Para fazer isso, vamos
ver os passos necessários para roubar uma sessão. Em cada um dos
casos, vamos assumir que a identificação da sessão foi comprometida.
Com um mecanismo simples de sessão, apenas uma identificação da sessão
que seja válida é necessária. Neste caso, vamos melhorar nosso código
adicionando mais verificações através das requisições HTTP.
Lembre-se: Não é recomendável utilizar dados do nível do protocolo TCP/
IP (como o endereço IP), pois este protocolo não foi feito para
acomodar atividades no nível HTTP. Um único usuário pode ter diversos
endereços IP’s a cada requisição, assim como múltiplos usuários podem
ter o mesmo IP (um proxy, por exemplo).
Vamos lembrar uma típica requisição HTTP:
Código:
GET / HTTP/1.1 Host: uidroot.com User-Agent: Mozilla/5.0 Gecko/
20061010 Firefox/2.0 Accept: text/xml, image/png, image/jpeg, image/
gif, */* Cookie: PHPSESSID=1234
Apenas o cabeçalho Host é requerido pelo HTTP/1.1, logo, não é ideal
confiar nos outros dados. Entretanto, a única coisa que precisamos é
checar a consistência, porque queremos complicar a personificação sem
afetar os usuários legítimos, não é mesmo?!
Vamos imaginar que depois da requisição passada, vêm a seguinte
requisição, como um User-Agent diferente:
Código:
GET / HTTP/1.1 Host: uidroot.com User-Agent: Mozilla Compatible (MSIE
7) Accept: text/xml, image/png, image/jpeg, image/gif, */* Cookie:
PHPSESSID=1234
Veja que o cookie é o mesmo, mas devemos considerar esta requisição
como vindo do mesmo usuário?!
É MUITO improvável que o usuário mudaria o User-Agent entre
requisições, certo?! Vamos modificar nosso mecanismo de sessão para
fazer uma nova verificação:
Código:
<?php session_start(); if (isset($_SESSION[‘HTTP_USER
O código acima obriga o atacante a usar não apenas uma identificação
de sessão válida, mas também o user-agent correto. Isto complica um
pouco a vida do atacante e deixa a sessão um pouco mais segura.
Será que podemos melhorar o código?! Leve em consideração que o método
mais comum de obter os cookies é explorando falhas em um browser
vulnerável, como o Internet Explorer. Esses exploits geralmente
envolvem em redirecionar a vítima ao site do atacante, logo, o
atacante saberá qual o user-agent da vítima e poderá obtê-lo
corretamente e passar pela nossa verificação de user-agent.
Bom, imaginem se, além do md5 do user-agent, poderíamos passar mais
alguns pedaços de informação. Isto dificultaria e muito o nosso
potencial atacante. Temos que manter uma boa lógica para evitar que
usuários legítimos sejam afetados por verificações que sejam feitas de
maneira incorreta. Nosso objetivo é diminuir problemas e não aumentá-
los. Vamos escrever o seguinte código:
Página identifica.php
Código:
<?php session_start(); // Retira as variáveis da sessão. $_SESSION =
array(); //Destrói o cookie da sessão if
(isset($_COOKIE[session_name()])) { setcookie(session_name(), ”,
time()-42000, ‘/’); } // Destrói a sessão session_destroy(); //Inicia
uma nova sessão session_start(); $codigo =
$_SERVER[‘HTTP_USER_AGENT’]; $codigo .= ‘É com você Adeildo’; $digital
= md5($codigo); echo ‘<form action=”consulta.php?chk=’ . $digital . ‘”
method=”post”>’; //Seu formulario de autenticação ?>
Página consulta.php
Código:
<?php //Existe $_GET[‘chk’]? if(!isset($_GET[‘chk’]))
{ header(“Location:identifica.php”); die(); } $codigo =
$_SERVER[‘HTTP_USER_AGENT’]; $codigo .= ‘É com você Adeildo’; $digital
= md5($codigo); //O $_GET[‘chk’] bate com a id digital? if ($digital !
= $_GET[‘chk’]){ header(“Location:identifica.php”); die(); } //sessão
é válida session_start(); //Processa o resto do código ?>
Este código funciona assim:
O usuário normal faz login na página identifica.php e vai para
consulta.php
O atacante, de posse da id da sessão e user_agent, acessa direto a
página consulta.php, mas ele (assim esperamos) não tem o $_GET[‘chk’],
ou seja, a identificação virtual gerada unicamente na página de login
identifica.php. O código adicional “É com você Adeildo” não deve ser
divulgado, pois ele garante que o nosso md5() gerado seja único. Em
outras palavras, se o atacante tentar passar só o md5 do user-agent,
ele não conseguirá acesso, o md5 deve ser do user-agent + $codigo
secreto e não apenas do user-agent.
Existem ainda, muitas outras maneiras de melhorar o sistema de
sessões, mas isso depende da sua criatividade e do seu sistema de
sessões em si. Não se esqueça que o alvo são os atacantes e não os
usuários legítimos.
Ao pegar um exploit de sessão, nunca acuse o potencial atacante, mas
sim solicite a senha novamente. Se você pegar um usuário legítimo e
acusá-lo de algo que ele não fez, pode apostar, você terá que, além de
arrumar o sistema de sessão, dar uma boa explicação ao usuário (ou ao
seu chefe).
Little_Oak 