Você sabia? CreatTimeSpan()

Nunca tinha parado para pensar nisso, mas gostei da dica que encontrei semana passada no HOF. Eis que temos o óbvio: a função CreateTimeSpan() – ou em “português” CriarIntervaloDeTempo() – é usada para se criar valores de tempo (em número de dias – um dia será 1, 1/2 dia será 0,5 e assim por diante).

Em 90% dos casos ela é usada para setar timeouts e outras informações de tempo como por exemplo o que a sua aplicação se manterá ativa (na tag cfapplication) e também em outras propriedades de tempo tal como num cache de query, pelo atributo cachedwithin (o quê? você não cacheia suas queries?!!). Neste último, é comum vermos sets para dias exatos, como um dia, dois e até um mês inteiro (queries de informações que nunca mudam, por exemplo).

Eis que lhe pergunto: você já experimentou rodar isso aqui e ver o que dá?

O resultado vai ser um sonoro “1” (sem aspas) na tela do seu browser. O que isso significa (além de que a função retorna valores em dias)? Significa que se você quiser determinar o tempo de permanência de uma query no cache do servidor você pode usar cachedwithin=”1″ e pronto. Não precisa ficar se lembrando de que na função CreateTimeSpan() o primeiro atributo significa dias, o segundo horas e assim por diante… (eu não consigo decorar essas coisas). Com essa abordagem você também pode poupar alguns nanosegundos de processamento já que o CFServer não vai precisar processar a função. Best-pratice? Nunca, never, nie! Esta é apenas uma curiosidade e uma abordagem diferente para você usar em suas aplicações caso esteja de saco cheio de ficar digitando CreateTime…. em todo lugar onde você quiser valores de dias inteiros para especificar.

O porém fica por conta de valores menores que um dia (comuns em cfapplication). Já pensou uma aplicação que só pode ficar ativa por 15 minutos? O valor de #CreateTimeSpan(0,0,15,0)# é “0.0104166666667”. Decida você o que é mais fácil digitar e entender…

Enquanto isso…

Mais um da série “Enquanto isso…”. Desta vez dou uma dica: trata-se de uma organização mantida por um grande (grande mesmo) banco brasileiro. O site é público e aberto, além de ser bem bonito e interessante, falando inclusive sobre cybercultura. As pastas safadas estão presentes no próprio domínio do site, não foi preciso fazer nenhum tracert, ping ou qualquer outra baboseira para encontrá-las sob um IP ou outro hostname.

A pasta CFDOCS contém inúmeros exemplos de aplicações, algumas delas podem ser usadas para fazer upload de arquivos em qualquer parte do servidor, por qualquer um!

Um diretório CFIDE/administrator pode ser facilmente quebrado usando um aplicativo “réquer” de brute-force, por exemplo. Além disso, no CF 4.0 temos um bug de buffer-overflow no administrator que, ao inserirmos uma string gigante (uma senha tem em média 8 caracteres, estamos falando de milhares, um doc do word de 30 páginas…) no campo onde se espera a senha de acesso o CFServer.exe cai e nunca mais volta (até alguém apertar o botãozinho de reboot)…

Os respectivos administradores de sistema do dito cujo já foram avisados e contactados sobre o assunto. Depois dizem que o CFServer é que é inseguro…

Leia algumas security best pratices que fiz sobre estes dois assuntos aqui.

Quando eu devo usar CFLOCK?

Esta semana andou rolando na lista CF-Brasil algumas perguntas sobre o uso da tag CFLOCK em CFMX. Não tem segredo ou complicação. Procure nos arquivos da lista ou então leia esta FAQ, feita por Ben Forta e disponível no CFFAQ.com:

A função da tag CFLOCK é a de controlar o acesso simultâneo de um pedaço de código ou mesmo de um escopo inteiro de variável. Versões anteriores do ColdFusion (pré CFMX) tinham uma limitação em que acessos simultâneos não protegidos à variáveis compartilhadas (como SESSION ou APPLICATION) podiam resultar em acessos indevidos à memória do servidor e, como consequência, falha do mesmo. Isso já não acontece com o ColdFusion MX, porém ainda existem casos onde devemos usar a tag CFLOCK. Primeiramente qualquer código que não é feito para acesso multi-usuário (tags de terceiros, acesso a arquivos de sistema, etc) deve ser protegido para garantir o acesso de forma sequenciada (em oposição ao acesso concorrente). Depois, mesmo que o acesso à variáveis compartilhadas não cause problemas no servidor, ele pode causar problemas de inconsistência na sua aplicação. Por exemplo, se uma aplicação atualiza um valor de uma variável do tipo APPLICATION e o código para esta atualização não está protegido com o lock, existe a possibilidade de usuários acessarem valores antigos (ainda não atualizados) e ao mesmo tempo valores novos (já atualizados). Talvez isso não seja um problema, dependendo da sua aplicação, porém se isso estiver afetando-a, é o caso de usar CFLOCK.

CF Technotes via RSS

Não usa nenhum feeder reader ainda? Então agora você tem mais um bom motivo para usar:

CFMX TechNotes RSS feed. Receba os TechNotes de ColdFusion direto da Macromedia no seu desktop.

Múltiplas instâncias de CFMX

Tudo o que você gostaria de saber sobre como instalar múltiplas instâncias do CFMX no Jrun (CFMX for J2EE) mas tinha medo de perguntar:

ColdFusion MX 6.1 Step-by-Step Creating and Configuring Multiple Instances

Leitura recomendada.

Blackstone: vídeos da MAX2003

Depois da excelente e divertidíssima apresentação feita pelo Marco Antonio (CFUG-Rio) direto da MAX2003, disponibilizo para download dois vídeos “undergrounds” de duas apresentações da MAX sobre o novo ColdFusion, codinome “blackstone”.

O primeiro é a apresentação oficial feita pelo Ben Forta ontem, dia 20 – veja o post relacionado. O segundo vídeo é da apresentação do Mike Nimer, feita hoje, durante o sneak peek, demonstrando (num protótipo “flexado”) algumas das prováveis novas funcionalidades do Blackstone.

Os vídeos estão em formato QuickTime e requerem o dito cujo para assistir. Estão um pouco escuros e desfocados, mas dá para entender e ver boa parte das apresentações, incluindo o figurino inusitado em que o pessoal da Macromedia se meteu: abelhas humanas! (juro que não entendi). Ambos foram gravados e disponibilizados por Ken Azuma, o qual somos imensamente agradecidos!!

– Blackstone, por Ben Forta (12Mb)
– Blackstone no sneak peek, por Mike Nimer (5Mb)

BTW: confiram também os comentários-calúnia do Jonas Galvez sobre a apresentação do Marco…

coldfusion.policy

Vendo o post abaixo do figuraça Alex Hübner, me lembrou que dia desses, logo após selecionar o “Enable ColdFusion Security” para ativar o Sandbox de um servidor ColdFusion, fui, como é de praxe – e necessário – reiniciar o serviço do ColdFusion.

E não é que o servidor não iniciava? Não dava nenhuma mensagem de erro? Simplesmente não iniciava! $%^&*!

Lá fui eu:

C:>cd d:cfusionmxruntimebin

D:CFusionMXruntimebin>

E lá fui agora no coldfusion.policy, que se encontrava da seguinte maneira:

// PERMISSIONS GRANTED TO EVERYONE

};

Olha, eu não sei porque diabos ele estava assim nessa indecisão de permito? ou não permito? ser ou não ser? ohhh…, mas tirando o deny {permission java.security.AllPermission;}, claro, ele funcionou numa boa.

Bug com CFFTP e sandbox security?

Não sou de ficar caçando agulha em palheiro mas hoje acredito ter encontrado um segundo bug no CFMX 6.1 (o primeiro pode ser visto aqui). Desta vez foi tentando encontrar a solução para um problema levantado por um cliente da MM Brasil (provavelmente o mesmo que postou uma mensagem sobre isso na CF-Brasil em setembro deste ano). Parece que a tag CFFTP (com seus atributos padrões) não funciona corretamente e numa pasta “sandboxizada” (seria melhor usar “contextualizada”?).

Sou um completo ignorante em RFCs, protocolos e afins, por isso me perdoem os puristas sobre o que vou falar sobre o protocolo FTP… Quando nos conectados a um servidor FTP usando a tag CFFTP, o ColdFusionMX (devemos encarar o ColdFusionMX/CFFTP como “clientes” FTP) usa – por padrão (?) – o modo PORT para se conectar ao host FTP solicitado. Desta maneira o tráfego de informações ficará “travado”, no lado do servidor FTP, somente nas portas 21 (cmd) e 20 (data). Qualquer um que já tenha configurado um firewall ou mesmo um cliente FTP já se deparou com esse comportamento (que na verdade é uma regra).

O cerne da questão é que, apesar de ter todas as permissões corretas e configuradas na seção “Server/Ports” de uma sandbox security, o CFMX não consegue completar a conexão, retornando um erro de java.net.SocketPermission denied, tal como reportado.

Mesmo quando não existe qualquer restrição de host/ips e portas no “Server/Ports” (default quando você configura uma nova sandbox) o CFMX é incapaz de se conectar via FTP em modo default (port). “Googlei” para todo o lado procurando alguém que tenha encontrado o mesmo problema mas só encontrei um relato semelhante, até agora sem resposta.

Estaria eu viajando de bonde ou trata-se realmente de um bug?

O workaround que encontrei para o problema é o seguinte:

1) No seu script CFML, use o atributo passive=”Yes” da tag CFFTP;
2) Prefira não configurar restrições dentro de “Server/Ports”. Caso isso seja imprescindível e inevitável, esta deverá conter as seguintes entradas: (1) “localhost:(todas as portas – basta deixar o campo “port” em branco)”, (2) “ftp.uol.com.br:21” (ou qq. outro host ftp), (3) “ftp.uol.com.br:1024-65535” (range dinâmico para retorno de conexões FTP em modo passive).

Veja no link continue lendo abaixo a mensagem que enviei à Macromedia (bug form) sobre o assunto.

Alguém aí consegue reproduzir o dito cujo?

UPDATE: A Macromedia Inc confirma o bug e este foi adicionado ao bug base sob o número 54053.

Leia o resto deste post »

ColdFusion Blackstone

Ben Forta solta algumas (poucas) palavras sobre a próxima versão do ColdFusion.