Opa. Não havia visto essa mensagem antes... ressuscitando-a...
2013/12/2 Guimarães Faria Corcete DUTRA, Leandro <[email protected]> > 2013/12/2 Charles França <[email protected]>: > > Tenho uma aplicaçao web em c# e tenho uma string de conexao com um > usuario e > > senha pra conectar ao banco. > > O temido usuário genérico, né? > > Temido? Opa... Nem sempre, há sempre prós e contras, cada ambiente dar-se-á melhor com um ou outro... Aliás, nem sempre se tem usuário logado na aplicação, não se esqueçam disso. (ou melhor, não em todas aplicações). > > > Existe algum problema ou degradaçao de performace se eu criar usuarios no > > postregres e a cada acesso dos usuarios eu utilizasse o usuario > cadastrado > > no postegres para conexão? > > Não, por que haveria? > > A princípio podemos pensar que não tem. Mas se formos pensar com mais carinho, verás que tem sim. Quando se usa usuários logados na aplicação para logar no banco também, fica praticamente impossível utilizar pool de conexões. Simples assim. Uma conexão é sempre associada ao par usuário+banco, e, se você quer trocar de usuário (mesmo que esteja no mesmo banco), terás de fechar a conexão e abrir uma nova. Eu disse que poderia não ter, porque se pensarmos só no PostgreSQL em si, não teria diferença, já que ele não tem pool de conexões nativamente mesmo. Mas impossibilitaria uso deste externamente (como com o pgBouncer). E, todo DBA sabe, que para aplicação com muitos usuários o pool de conexão se torna essencial. MAS... (acharam que não tinha um MAS ??). Existe uma solução para esse problema. Eu, particularmente, acho meio feinha, mas se queremos associar usuário da aplicação ao usuário do banco por causa das permissões, é uma boa. A ideia é simples, supondo que temos os usuários huguinho, zezinho e luizinho; podemos criar um usuário genérico para a aplicação conectar da seguinte forma: CREATE ROLE my_app_user LOGIN PASSWORD 'sua senha' ROLES huguinho, zezinho, luizinho; Daí, a aplicação conecta-se sempre com o mesmo, my_app_user, e, após o login do usuário (em geral ao "pegar" a conexão do pool), executa: SET ROLE huguinho; Pronto. Todas as permissões do huguinho entrarão em uso. Novamente, eu acho uma solução feia e um tanto frágil, por exemplo, não podemos, em hipótese alguma, esquecer de executar o SET ROLE. Em aplicação bem feitas, a conexão é sempre recuperada de um único lugar e isso fica fácil de resolver. Outro problema é que a autenticação do usuário deverá ser feita pela aplicação (já que a string de conexão será a mesma). Apesar de que eu acho que usar a senha do banco na aplicação é uma tremenda falha de segurança. Assim como permitir acesso direto ao banco. > E ainda podes aí ter controles mais efetivos de acesso. > Isso é verdade. Mas lembrem-se que não podemos limitar a visualização de tuplas por valores. Por exemplo, se quisermos limitar um usuário a enxergar dados de uma tabela que seja somente pertencente ao mesmo (coisa do tipo WHERE user_id=XXX), não poderíamos fazer com GRANT/REVOKE. Bom, passei o problema, agora vamos à solução deste também =). Existem formas de resolver esse problema, como a utilização do SELinux, mas não vou entrar em detalhes sobre o mesmo. Ou ainda permitir acesso a tabelas como essa passando apenas por funções que verificam o current_user. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
