CFMX Sandbox Security para ambientes compartilhados
Publicado; 25/01/2004 Arquivado em: ColdFusion 14 ComentáriosDurante este final de semana terminei de escrever um pequeno tutorial sobre como criar e quais são as configurações que recomendo para sandbox security em ColdFusion MX. Trata-se de uma “receita de bolo” que espero seja útil para quem oferece hospedagem compartilhada de ColdFusion MX.
“CFMX Sandbox Security para ambientes compartilhados”
Também disponível em formato PDF, 170K clicando aqui.
UPDATE: acrescentei algums comentários sobre a necessidade de se armazenar variáveis de cliente em banco de dados ao invés das opções padrões disponíveis (cookies e registry) e sua relação com a sugestão de desabilitar a tag CFREGISTRY.
UPDATE2: já existe uma versão deste tutorial atualizada para a versão 7 do ColdFusion Server. Acesse aqui.
Muito bem! Já era tempo de você criar vergonha na cara e publicar isso!
Não vou perder meu tempo falando sobre o quão importante esse documento é para programadores e administradores de servidores. Isso é óbvio.
Parabéns Alex, a comunidade precisava de um artigo sobre o assunto.
[]’s
Vicente Marçal
Desenvolvedor ColdFusion
Illume Design
Londrina-PR
Alex,
não encontrei em lugar algum sobre isto, mas tive alguns problemas em desabilitar o CFregistry e armazenar as variáveis de sessão no registro.
Acredito que o CFMX utiliza o CFregistry para esta função, mesmo não estando declarado no código.
confirmas?
[]’s
marcel
Até que enfim alguma coisa util nesse blog heim…..
Hahahahahahahaha to brincando.. Muito boa a matéria, quem sabe agora os servers aprendem a configurar essa porra direito né!
[]’s
Marcel, bem lembrado. É exatamente isso. Se você estiver armazenando as variáveis de cliente (opção ‘Client Variables’ no Administrador) no registro as contas não podem ter esta tag desabilitada. Vou fazer esta observação no documento, obrigado por lembrar.
Eu recomendo fortemente que você armazene estas variáveis num banco de dados ao invés de no registro. Veja a opção “Select Data Source to Add as Client Store” em Client Variables do administrador do CFMX.
Eu acho meio doido para o lado do provedor (de hospedagem compartilhada, conforme indica o artigo postado) guardar as client variables em banco de dados.
Em sites bem-visitados esse treco cresce em ritmo igual ou maior que os logs de acesso.
Fora o fato de que cada vez que as variables forem consultadas, lá vai uma conexão ao banco, ocupando e desperdiçando processador, memória (para a busca da variable ou criação dela, se o cliente não existisse previamente no banco) e tempo (várias camadas de aplicação / JDBC / ODBC). Se o banco estiver em outra máquina, pior ainda, tem a perda de tempo da comunicação entre os dois servidores.
Quando eu tinha 3 sites mega-movimentados rodando ao mesmo tempo na mesma máquina (agora eles estão separados e as CVs em cookie), e usando client variables em banco de dados, em 2 dias o banco chegou a quase 3GB de tamanho. Imagino num webhost com 300 sites em CF rodando client variables em banco de dados…
Por isso, como host, prefiro setar via cookie. Aí é o indivíduo quem guarda as suas próprias configurações. E não tem desperdício de processador/memória/tempo/espaço em disco nem de poder de processamento do banco de dados, que fica lá quieto, em paz. Tem seus revezes? Tem sim, tem os neuróticos que bloqueiam todo e qualquer tipo de cookie, mas fazer o quê?
Salve Rafael! Bem, como disse no documento, são sugestões pessoais, cada um faz o que acha melhor. Eu sinceramente NUNCA soube ou ouvi relatos iguais ou parecidos com o problema que você mencionou.
A Macromedia recomenda esta configuração, acredito que exista um bom motivo. O armazenamento no registro é absolutamente inviável e ridículo. Usar cookies é interessante e economiza espaço em disco, porém é, de longe, a segunda pior opção. Como você mencionou, a quantidade de browsers que não aceitam cookies (seja pela configuração explícita do usuário, seja pelo firewall/privacy software pessoal etc) é imensa. Há, tem também o lance de ficar comendo cookies (são apenas 20 por domínio/host) e o consumo adicional de banda. Cada cookie tem aproximadamente 3kb. Some 3Kb a CADA request http no seu servidor e você verá a conta ficar grande no final do mês.
Além disso se o problema é espaço em disco, bastava configurar a opção “Purge data for clients that remain unvisited for X days” de maneira inteligente e de acordo com o gigantesco volume de tráfego que você tem. Adicionalmente a opção: “Disable global client variable updates” poderia estar desabilitada para ajudar.
Sobre o tempo de processamento e de manutenção de conexões JDBC/ODBC, acho que você está exagerando um pouco. O tempo de processamento disso é bastante menor que o tempo que o CF leva para, a cada request (repito, A CADA request) ler o cookie enviado pelo visitante. Faça um teste e comprove o que estou dizendo.
Uma coisa que me surpreendeu e que tenho que perguntar: você põe o banco de dados na mesma máquina que o CFServer? Pergunto isso porque parece que o tráfego entre máquina com DB e máquina com CF parece ser um motivo de preocupação para você, quando realmente não deveria, mesmo num volume tão grande de dados. #Gb em dois dias dá uma média de 64 megas por hora, uma rede local dá conta facilmente deste volume sem atrasar nada. Outro dia estava pensando numa coisa engraçada: o throughput de um disco Serial ATA 150 é mais baixo que o de uma placa de rede Gigabit Ethernet… Num datacenter decente de hoje esta abordagem é usada no esquema “splited servers”, um com DB e outro com o servidor de aplicação. Tráfego entre DB server e o servidor CF, definitivamente não é uma coisa que me preocupa muito.
Me conte uma coisa, qual MAINFRAME você estava usando para suportar dois sites que juntos, geravam 3GB de CDATA e CGLOBAL em apenas dois dias? Quais eram estes sites? Estou impressionado com este volume.
[quote]
Há, tem também o lance de ficar comendo cookies (são apenas 20 por domínio/host) e o consumo adicional de banda. Cada cookie tem aproximadamente 3kb. Some 3Kb a CADA request http no seu servidor e você verá a conta ficar grand no final do mês.
[/quote]
Isto não é problema, visto que tenho banda suficiente (servidores nos EUA). Já aqui no Brasil seria caso a se pensar.
[quote]
Além disso se o problema é espaço em disco, bastava configurar a opção “Purge data for clients that remain unvisited for X days” de maneira inteligente e de acordo com o gigantesco volume de tráfego que você tem. Adicionalmente a opção: “Disable global client variable updates” poderia estar desabilitada para ajudar.
[/quote]
E aí vem sempre um mané reclamando que as configurações dos clientes deles não estão sendo salvas e que ele quer isso permanentemente para lembrar de todos os clientes. Já aconteceu isso.
[quote]
Sobre o tempo de processamento e de manutenção de conexões JDBC/ODBC, acho que você está exagerando um pouco. O tempo de processamento disso é bastante menor que o tempo que o CF leva para, a cada request (repito, A CADA request) ler o cookie enviado pelo visitante. Faça um teste e comprove o que estou dizendo.
[/quote]
Bem, suponhamos que o datasource CF para o banco das client variables seja um datasource JDBC comum, mas ligado ao driver ODBC que é quem conecta ao banco.
Então temos cliente -> servidor CF -> jdbc -> ODBC -> banco (login e consulta) -> ODBC -> jdbc -> servidor CF.
Já via cookie: cliente -> servidor CF -> cliente -> servidor CF.
Com certeza os 500ms do tempo de transferência do cookie (considerando 6k/seg de velocidade) é menor que toda a movimentação de conexão e consulta ao banco. Só as camadas de conexão devem levar muito mais tempo do que a transferência desse cookie, sem incluir o tempo levado para se escrever no log.
[quote]
Uma coisa que me surpreendeu e que tenho que perguntar: você põe o banco de dados na mesma máquina que o CFServer? Pergunto isso porque parece que o tráfego entre máquina com DB e máquina com CF parece ser um motivo de preocupação para você, quando realmente não deveria, mesmo num volume tão grande de dados. #Gb em dois dias dá uma média de 64 megas por hora, uma rede local dá conta facilmente deste volume sem atrasar nada. Outro dia estava pensando numa coisa engraçada: o throughput de um disco Serial ATA 150 é mais baixo que o de uma placa de rede Gigabit Ethernet… Num datacenter decente de hoje esta abordagem é usada no esquema “splited servers”, um com DB e outro com o servidor de aplicação. Tráfego entre DB server e o servidor CF, definitivamente não é uma coisa que me preocupa muito.
[/quote]
Depende muito. Alguns setups temos com o SQL dentro da própria máquina, outros com SQL em servidor separado; depende muito do cliente, da necessidade (aplicações e sistema operacional requisitados, espaço em disco contratado), das licenças disponíveis (o CF e o SQL a gente aluga do datacenter por uma ninharia mensal, mas ainda é caro). Quando você trabalha com mais de um datacenter, com políticas diferentes, e ainda por cima vai montando a sua rede aos poucos, não é fácil ficar reconfigurando a mesma o tempo todo. Você começa com uma máquina mixuruca com tudo instalado nela (CF, PHP, SQL Server, mySQL, email), por causa da contenção de gastos, e depois vai migrando e redimensionando. Porém alguns clientes ficam “com arrepios” só em pensar em trocar o código para refletir uma mudança de servidor de banco de dados, e exigem que mantenhamos aonde está. Há gostos e loucos para tudo… Temos sim servidores de banco de dados separados, mas ao mesmo tempo ainda mantemos clientes antigos com bancos no próprio servidor web, clientes estes que não quiseram a mudança – e temos que respeitar. Quando você chega a 25 servidores gerenciados e cada máquina com 250 a 400 domínios – cada um configurado de um jeito – não é “fácil”. Até mesmo para fazermos upgrade para um hardware melhor é trabalho hercúleo, sempre com a desculpa de que “em time que está ganhando não se mexe”.
Além do mais, no tráfego entre servidores diferentes, nem sempre é possível interligá-los através de gigabit ethernet, ou via vlan privada/switch interno, ou seja, o tráfego entre eles às vezes é contabilizado dentro do seu limite global de tráfego que o datacenter disponibiliza (i.e., a comunicação sai através da porta internet do roteador para alcançar a porta internet do outro servidor, e isto é contabilizado como tráfego internet e não intranet).
Isso se aplica a pelo menos 80% das empresas de hospedagem que conheço, idem a datacenters (creio que só a The Planet e a GNAX, lá fora, deixam fazer VLAN privada com placa de rede secundária).
[quote]
Me conte uma coisa, qual MAINFRAME você estava usando para suportar dois sites que juntos, geravam 3GB de CDATA e CGLOBAL em apenas dois dias? Quais eram estes sites? Estou impressionado com este volume.
[/quote]
Três sites: http://www.forrobrasil.com, http://www.cgfocus.com, e http://www.clubemix.com.br. Este último, sentou meu servidor completamente. Estavam na época num Dual Pentium III 1.13Ghz, com então 512M de RAM e 2 HDs de 36GB SCSI. Ele tinha o SQL dentro dele mesmo.
Resultou em sempre eles estarem fora do ar. O CGFocus foi movido para um dedicado, o clubemix para outro, e resolveu-se o problema.
Esqueci de mencionar: “a Macromedia recomenda esta configuração”. Mas não esqueça de levar em conta também que eles desenharam o produto para ser um servidor dedicado (vide o CF Administrator não ter níveis de segurança nem logins/senhas, por exemplo), e não compartilhado.
Salve Rafael, boa discussão!
Vamos aos meus comentários:
1) Sorte sua estar nos EUA! 🙂 Aqui no Brasil banda custa caro pra caramba. Eu pago 50 reais por cada 1GB adicional transferido em meu datacenter, em compensação a velocidade é melhor;
2) Sobre o purge de variáveis de cliente, isso é algo a ser levado em consideração sem dúvida, porém confesso que eu ainda continuo abismado com este volume de dados gerado (3Gb), pelo que você diz, em dois dias, para três sites. Ou os sites tem uma visitação EXTREMAMENTE grande ou o programador abusou (mais do que deveria) de variáveis client. Idependentemente disso, eu acho que uma aplicação/site que precise manter variáveis client por mais de dois dias é, no mínimo, uma aplicação “exótica”, mas vai saber… Vejo cada monstro por aí 😉 Não é de se espantar que qualquer servidor fique “sentado”, com sites assim;
3) Você está enganado sobre como o CFMX faz conexões ao banco de dados. Esta seqüência que você mencionou “cliente -> servidor CF -> jdbc -> ODBC -> banco (login e consulta) -> ODBC -> jdbc -> servidor CF” não existe. O CFMX usa drivers JDBC Type 4, que acessam nativamente o RDBMS, sem qualquer ponte ou firula (obs: eu uso o driver JDBC da própria Microsoft para acessar o SQL Server). Além disso, login no banco de dados não é executado a cada consulta (claro, se você não desabilitou manter a opção de manter o pipe aberto). Não estava me referindo ao tempo de latência na rede para transferir o cookie, mas sim o tempo de leitura e parsing deste pelo cfmx que, somado ao tempo de transferência em rede (obrigado por lembrar), é mais lento e consome mais CPU do que buscar as informações num banco de dados da mesma rede, com base no CFID/CFTOKEN do usuário.
4) Ok sobre o lance de separar as máquinas. Entendo que as vezes não podemos ter a estrutura ideal;
5) Sobre os três sites que você mencionou: haja visitação para gerar 3GB em dois dias apenas com variáveis de cliente! Eu gerencio um site que considero ter um volume bastante alto de visitação (somos a 1a referência para a palavra “Amazonia” no Google), passando inclusive alguns sites considerados “grandes”, dentro de portais como o UOL. Nosso volume de variáveis de cliente armazenado em 90 dias (purge default) em sql server: 5 Megs!
6) O argumento de que a MM recomenda (me esqueci de mencionar: quase todos que conheço, exceto você, também recomendam) armazenar variáveis de cliente em banco de dados por ser (o CF) um produto para ambientes dedicados não tem fundamento. A recomendação não se dá pelo tipo de modalidade de servidor (dedicado ou não) ou mesmo se ele tem um, dois ou 300 aplicações/sites na mesma máquina. Ela se dá pelo VOLUME de transações existentes, o que obviamente independe da quantidade de sites ou se o servidor é compartilhado ou não. Por isso digo: a opção de armazenamento em banco de dados é, na minha opinião e de muitos outros administradores de sites “menos visitados”, a abordagem mais estável, rápida e adequada para se armazenar variáveis de cliente. Especificidades e situações diferentes, que requerem abordagens diferentes, sempre existirão sem dúvida, entretanto eu não me baseio pelas exceções, mas sim pela regra.
BTW: o programador de um site “altamente visitado” também pode escolher ONDE armazenar (usando o atributo CLIENTSTORAGE) as variáveis de cliente entre as opções banco de dados (default na configuração que recomendo) ou cookies se este gerar um volume estupendo de armazenamento de variáveis client. Registry não poderá ser usado considerando-se que a tag cfregistry está desabilitada para a sandbox dele.
cara,quem escreve-te é um leigo at all.
já publiquei páginas em html e tenho um livro de asp,mas enfim,quero saber que linguagem devo estudar pra criar softwares,quero dizer,se existem algumas quero saber qual a mais indicada pra quem não saca coisa alguma,se poderias me indicar sites com turotiais,cursos on line,livros,o que caracteriza coldfusion,pra onde os patos do central park voam quando chega o inverno,essa coisas da vida.
é isso.
desde já agradeço.
Muito bom.
só um pequeno problema, eu nunca consegui descobrir alguma senha de e-mail,ja criei varios e-mails para eu ver se consigo algum sucesso,mais ianda não:( sou inesperiente ainda para obter esse tipo de sucesso.
aguem se abilita me dá dicas,ate mesmo alguma aula rapida por msn,telefone,encontros.
gostaria muito de aprender não para fazer o mau e sim para se tornar mais uma defesa para meus estudos. .. bjos .
eu quero saber fazer como é senha tbm orkut hotmail