Fernando. deixe-me palpitar aí na conversa de vcs : primeiro de tudo,
SE vc puder usar o recomendado, o fácil, o built-in,o nativo do banco,
que é CADA usuário do sistema corresponder a um usuário no banco, aí
vc NÂO TEM necessidade alguma de tabelas extras, o banco controla
isso, é função dele, além de vc ganhar ENORME facilidade em traces de
usuário, em auditorias, etc... Nesse cenário, vc não teria uma tabela
chamada usuário, mas um uma VIEW chamada usuarios, que busca a info
necessária dba DBA_USERS, DBA_TAB_PRIVS, trazendo nome da tabela, do
usuário, e teria colunas INSERT, UPDATE, DELETE, SELECT, que estariam
vazias pros privs de tabela que o usuário não tem, etc. A sua
aplicação de controle de usuários consulta essa view, a mostra na
tela, e o usuário tem chance de clicar nos campos que hoje estão
vazios ou nos que estão preenchidos, se clicou numa coluna vazia
(digamos, na coluna de UPDATE) a aplicação monta e envia pro banco um
SQL dinâmico tipo GRANT UPDATE ON nomedatabela TO usuáriodestino, caso
clicou num campo não-vazio quer remover o privilégio, aí a aplicação
monta um REVOKE - já que nome do usuário e da tabela taria na view,
problema nenhum.... Eu acho que REALMENTE não é necessário se criar
tabela pera isso, MAS se vc quiser criar deve funcionar também.
 Agora, se por qquer mau motivo vc não puder ter o ideal e correto,
que é cada usuário da aplicação ter o seu usuário de banco, aí o
negócio complica mais... 

[]s

 Chiappa
 
--- Em oracle_br@yahoogrupos.com.br, Fernando Paiva
<[EMAIL PROTECTED]> escreveu
>
> É estou vendo mesmo que é complicado de explicar. Bem! Vou te dizer o
> que estou tentando fazer.
> 
> Tenho uma tabela chamada "usuarios", que é onde vou cadastrar meus
> usuários, depois tenho uma outra tabela chamada "permissoes", que é onde
> eu "pretendoooo" gravar o nome da tabela o código do usuário juntamente
> com suas permissões insert/update/delete/select.
> Ex:
> Cod.Usuario = 001
> tablename | insert | update | delete | select
> cliente   |   v    |   v    |    v   |   v
> estoque   |   v    |   v    |    f   |   v
> 
> Seria + ou - isso. O que naum estou achando uma maneira é fazer com que
> as permissões sejam dadas partindo desse principio, onde o codigo
> daquele usuario tera as permissoes, entende ?
> 
> Talvez vc possa me dar uma outra idéia.
> 
> []'s
> Fernando Paiva
> 
> 
> 
> Em Ter, 2007-05-15 às 15:04 -0300, FERNANDES Marco A SOFTTEK escreveu:
> > Amigo,
> > não é nada de espetacular não.
> > 
> > Temos algumas tabelas auxiliares para controlar nome do usuário e
> > outros dados, e usamos algumas views do sys
> > pra ter os objetos do banco. Daí por diante é tudo código embarcado
> > pra dar os grants... o detalhe é que
> > temos algumas roles padrões para os usuários comuns do sistema
> > (consulta, alteração, acesso) e
> > algumas coisas também fazemos por módulos e menus do sistema.
> > Ficou um pouco confuso porque foi feito aos poucos e por isso meio
> > remendado.
> > 
> > Os acesso mais gerais são controlados por roles, por exemplo, execução
> > de procedures do banco.
> > Já para os menus e módulos fazemos o controle a nível de usuário, ou
> > seja, tem que dar direito
> > pra cada transação da tela da aplicação.
> > 
> > A tela básica é sim de cadastro de usuários... nesse cara temos a
> > criação do usuário a partir
> > de roles básicas (como acesso por exemplo). Temos uma outra tela de
> > cadastro de transações
> > e uma tela para associação dos dois cadastros. Estas transações podem
> > estar ligadas aos
> > objetos do banco (tabelas) e aos objetos da aplicação (menus,
> > módulos).
> > 
> > Nada muito complexo de fazer e nada muito simples de explicar... risos
> > 
> > Abraço,
> > Marco.
> > 
> > ________________________________
> > 
> > From: oracle_br@yahoogrupos.com.br
> > [mailto:[EMAIL PROTECTED] On Behalf Of PUB:
> > pythondeveloper
> > Sent: terça-feira, 15 de maio de 2007 14:17
> > To: oracle_br@yahoogrupos.com.br
> > Subject: [oracle_br] Re: Segurança no sistema ?
> > 
> > Opa
> > 
> > Vc pode me dar + ou - a explicação de como fizeram ae ? Tipo, com o
> > cadastro de usuários e tals ?
> > 
> > Obrigado
> > 
> > --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%
> > 40yahoogrupos.com.br> , "FERNANDES Marco A SOFTTEK"
> > <mfernandes@> escreveu
> > >
> > > Amigo,
> > > aqui nós temos exatamente isso... cada usuário que loga no sistema é
> > > um usuário de banco e existe uma tela de controle de segurança que
> > > faz todo o serviço sujo... existe pouca intervenção do DBA e o
> > trabalho
> > > fica mesmo a cargo do Analista de Segurança.
> > > 
> > > É um precinho meio caro ter isso... mas o controle fica ótimo.
> > > 
> > > A outra possibilidade que já vi em outros locais é o uso de uma
> > tabela
> > > de controle de usuários e permissões apenas na aplicação (menus,
> > botões, etc).
> > > Mas isso tbém dá um bom trabalho !
> > > 
> > > Abraço,
> > > Marco.
> > > 
> > > ________________________________
> > > 
> > > From: oracle_br@yahoogrupos.com.br <mailto:oracle_br%
> > 40yahoogrupos.com.br> 
> > [mailto:oracle_br@yahoogrupos.com.br <mailto:oracle_br%
> > 40yahoogrupos.com.br> ] On Behalf Of PUB: pythondeveloper
> > > Sent: terça-feira, 15 de maio de 2007 13:29
> > > To: oracle_br@yahoogrupos.com.br <mailto:oracle_br%
> > 40yahoogrupos.com.br> 
> > > Subject: [oracle_br] Segurança no sistema ?
> > > 
> > > 
> > > 
> > > Saudações
> > > 
> > > Estou precisando criar um sistema, mas estou emperrado na parte de
> > > segurança do mesmo, estou emperrado em decidir como faze-la.
> > > 
> > > A pergunta é: "Como fazer para criar um mecanismo dinâmico de
> > > segurança do meu sistema, onde eu possa dar permissões aos usuários
> > de
> > > insert/update/delete/select nas tables, qual a técnica que vocês
> > usam ?"
> > > 
> > > Eu pensei em usar usuários do banco, acho que seria a maneira mais
> > > adequada, mas me vi meio perdido, pois iria precisar criar em minha
> > > aplicação uma tela para controlar esse esquema.
> > > 
> > > Alguma sugestão ?
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > [As partes desta mensagem que não continham texto foram removidas]
> > >
> > 
> > [As partes desta mensagem que não continham texto foram removidas]
> > 
> > 
> > 
> > 
> >
>


Responder a