Anderson... o que o Chiappa falou está 100% correto. Quando tudo está indo bem, surge algum diretor com idéias mirabolantes, aí todo o software acaba tendo que ser reescrito (e o pior é que a manutenção nunca acaba). Eu também li sobre o VPD, e que considero ser a opção mais fácil de implementar e utilizar, porém essa opção só vem com o banco enterprise :-( Por outro lado, deve-se levar em consideração que as aplicações atuais que utilizam todo aquele esquema de orientação à objetos vem a dar uma grande ajuda à esse problema (que acredito eu muitos desenvolvedores possuem esse problema) Uma solução que vi ser utilizada é: Os desenvolvedores compilam dois módulos esatamente iguais, porém impõem parâmetros para esses módulos, os quais restringem os dados. Mas o problema é: se eu tiver 950 telas no sistema, e tiver que impor regras à algumas isso vai crescre exponencialmente, sem contar que a manutenção vai ficar complicada. Estou pensando/montando algo que seja fácil de utilizar e simples de atualizar. Quando estiver mais completo envio para vocês, assim poderemos trocar idéias sobre isso. Obrigado pela ajuda. --- Em oracle_br@yahoogrupos.com.br, Anderson Haertel Rodrigues <[EMAIL PROTECTED]> escreveu > > No projet atual que estamos desenvolvendo iremos > implementar algo neste sentido pela aplicação. Mas, as > regras são muitos dinâmicas (umas 12 regras de > visualizações, que em momento podem virar 13,14...cair > para 11, etc). > > Uma solução interessante que vi/li também é Label > Security - um built do VPD citado pelo Chiappa. > > --- jlchiappa <[EMAIL PROTECTED]> escreveu: > > > Paulo, eu discordo de se colocar segurança de acesso > > na aplicação, > > pelo seguinte : por mais que os usuários finais > > jurem de pé junto que > > a aplicação atual é suficiente, que os gerentes > > assinem embaixo que > > os dados TEM que estar "trancados", acessíveis só > > pela aplicação, > > CEDO ou TARDE vai sim chegar uma hora em que > > > > a) a aplicação não atende mais e vai ter que ser > > re-escrita, talvez > > até em outra linguagem/tool > > > > e/ou > > > > b) os dados terão que ser acessados/manipulados por > > outra > > aplicação/outras fontes. > > > > Aí se acontecer a), ** todas ** a segurança que vc > > escreveu terá que > > ser re-escrita (talvez re-aproveitando-se um pouco > > do código, mas às > > vezes não), e se acontecer b) , ao invés da outra > > fonte acessar > > diretamente os dados vc VAI ter que escrever alguma > > interface pra > > ela, mais e mais trabalho, e nem sempre é possível - > > aqui mesmo no > > cliente atual, temos uma aplicação que tinha regras > > de acesso > > codificadas, era escrito de pedra e cal que ninguém > > podia acessar os > > dados fora dela, um belo dia algum diretor > > casca-grossa cismou que > > tinha porque tinha que ter acesso a esses dados via > > tool front-end X, > > QUEBROU TUDO, é isso... E pra piorar X só tinha > > acesso à dados via > > SQL e retsrições do tipo, então NÃO tinha como > > montarmos uma API de > > acesso, basicamente o que vai ser feito é ter-se um > > OUTRO banco com > > esses dados.... Numa palavra, segurança fora do > > banco é uma furada, > > é uma bomba q cedo ou tarde vai explodir na cara de > > alguém, IMHO. Em > > verdade, o que eu vejo cada vez mais é que as > > aplicações tem um ciclo > > cada vez mais curto, PORÉM os dados permanecem, > > então penso ser > > razoável deixar as regras de acesso junto com os > > dados, são itens > > indissociáveis IMHO... > > > > Edson, ** facílimo ** de tudo vc ter essa segurança > > de acesso no > > banco : a opção mais simples é vc ao invés de dar > > GRANTs direto da > > tabela, vc ter uma VIEW que só busque os dados a que > > o cara tem > > direito, e vc dá os GRANTs apropriados da view pros > > usuários finais, > > tipo : > > > > CREATE VIEW V_CLIENTES as SELECT * FROM CLIENTES > > WHERE COD_EMPRESA > > = :valordaempresa; > > > > onde esse :valordaempresa pode ser uma var global, > > um context, uma > > sub-query numa tabelinha oculta, qquer coisa do > > tipo. > > > > Uma outra opção boa seria o VPD (Virtual Private > > Database), com ela > > o banco automaticamente adiciona as regras que vc > > especificar nos > > SQLs que receber, daí automaticamente um comando > > tipo : > > > > SELECT nnn FROM CLIENTES WHERE campo=X; > > > > ia ser transformado em : > > > > SELECT nnn FROM CLIENTES WHERE campo=X and > > COD_EMPRESA = nnn; > > > > ==> Óbvio, ambas as opções podem interferir em > > performance SE não > > forem bem-planejadas e testadas, mas isso é default > > de > > desenvolvimento, qquer coisa que vc for fazer SEMPRE > > tem que ter uma > > fase adequada de teste e planejamento... > > > > []s > > > > Chiappa > > Anderson Haertel Rodrigues > Administrador de Banco de Dados - DBA > Florianópolis/SC > > > > _______________________________________________________ > Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! > http://br.acesso.yahoo.com >
-------------------------------------------------------------------------------------------------------------------------- Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ --------------------------------------------------------------------------------------------------------------------------__________________________________________________________________ Moderador e Fundador: Dorian Anderson Soutto [EMAIL PROTECTED] __________________________________________________________________ Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
