Novidades do Interbase 7.5
Lí o artigo de capa da clubedelphi.net: ´Artigo - InterBase 7.5 – uma prévia do que vem por aí´
Dentre as novidades temos: ´[b:74b74cceb2]Embedded user authentication (EUA)[/b:74b74cceb2] – no bom português poderíamos falar o seguinte, autenticação de usuário por banco de dados, ou seja, usando este recurso ao copiar o banco de dados para outro servidor só terá acesso ao mesmo quem tiver a senha do banco de dados, pois [b:74b74cceb2]a mesma fica gravada no seu “.GDB” ou “.IB” [/b:74b74cceb2]e não mais no admin.ib. Será permite as duas formas de autenticação, por servidor ou por banco de dados ficando a critério de cada um qual irá usar. ´
Há alguma vantagem real nisso?
Qual a opinião de vocês?
Dentre as novidades temos: ´[b:74b74cceb2]Embedded user authentication (EUA)[/b:74b74cceb2] – no bom português poderíamos falar o seguinte, autenticação de usuário por banco de dados, ou seja, usando este recurso ao copiar o banco de dados para outro servidor só terá acesso ao mesmo quem tiver a senha do banco de dados, pois [b:74b74cceb2]a mesma fica gravada no seu “.GDB” ou “.IB” [/b:74b74cceb2]e não mais no admin.ib. Será permite as duas formas de autenticação, por servidor ou por banco de dados ficando a critério de cada um qual irá usar. ´
Há alguma vantagem real nisso?
Qual a opinião de vocês?
Fsflorencio
Curtidas 0
Respostas
Vinicius2k
29/09/2004
Sim. Creio que haja vantagem. Mas de absoluta necessidade não creio que seja (se todos utilizassem com seriedade os recursos de segurança do IB)...
Nem seria tão mais seguro do que a autenticação no servidor, já que em poucos meses vão ´chover´ quebradores de senha de banco assim como vc encontra aos montes para o Access...
A vantagem real nisso está ligada ao enorme transtorno que existe quando vamos instalar nossa aplicação num cliente que já possui outra aplicação baseada no IB e o ´nobre colega´ usa o SYSDBA travado dentro do componente de conexão da aplicação que ele desenvolveu e alterou a senha sem informar ao cliente. Já passei muita, mas muita, raiva por conta disso...
T+
Nem seria tão mais seguro do que a autenticação no servidor, já que em poucos meses vão ´chover´ quebradores de senha de banco assim como vc encontra aos montes para o Access...
A vantagem real nisso está ligada ao enorme transtorno que existe quando vamos instalar nossa aplicação num cliente que já possui outra aplicação baseada no IB e o ´nobre colega´ usa o SYSDBA travado dentro do componente de conexão da aplicação que ele desenvolveu e alterou a senha sem informar ao cliente. Já passei muita, mas muita, raiva por conta disso...
T+
GOSTEI 0
Vinicius2k
29/09/2004
Em tempo:
Eu havia visto esta notícia no site da FireBase, mas esquecí-me de postar o link...
http://www.firebase.com.br/cgi-bin/firebase.cgi/news?newsid=961
T+
Eu havia visto esta notícia no site da FireBase, mas esquecí-me de postar o link...
http://www.firebase.com.br/cgi-bin/firebase.cgi/news?newsid=961
T+
GOSTEI 0
Afarias
29/09/2004
O novo recurso de usuários no banco de dados não tem o objetivo de aumentar a segurança (e nem fará isso) -- as questões de segurança no IB continuam as mesmas. O objetivo desta nova funcionalidade é prover maior praticidade quanto a mobilidade do banco (e seus usuários) de um servidor para outro ou mesmo usuários próprios sem se preocupar com os usuários do servidor em servidores ´compartilhados´
T+
T+
GOSTEI 0
Vinicius2k
29/09/2004
Anderson,
Fiquei um pouco curioso sobre esta funcionalidade...
Vc já tem notícias de como vai ser implementada?
Pq se um usuário poderá ser um objeto do banco, teoricamente, poderemos utilizar DDLs do tipo ´create user´, não ficando presos à API...
T+
Fiquei um pouco curioso sobre esta funcionalidade...
Vc já tem notícias de como vai ser implementada?
Pq se um usuário poderá ser um objeto do banco, teoricamente, poderemos utilizar DDLs do tipo ´create user´, não ficando presos à API...
T+
GOSTEI 0
Afarias
29/09/2004
|Pq se um usuário poderá ser um objeto do banco, teoricamente,
|poderemos utilizar DDLs do tipo ´create user´, não ficando presos à
|API...
Exato. Será possível criar/manipular usuários com comandos DDL (SQL).
Também será possível definir ROLES padrão para os usuários, criar usuários ´SYSDBA´ por banco, cada usuário poderá alterar sua própria senha (sem precisar de artifícios como hoje em dia :))
T+
|poderemos utilizar DDLs do tipo ´create user´, não ficando presos à
|API...
Exato. Será possível criar/manipular usuários com comandos DDL (SQL).
Também será possível definir ROLES padrão para os usuários, criar usuários ´SYSDBA´ por banco, cada usuário poderá alterar sua própria senha (sem precisar de artifícios como hoje em dia :))
T+
GOSTEI 0
Vinicius2k
29/09/2004
Muito bom isso !
Permite a verdadeira integração entre usuário da aplicação e banco sem precisar ficar ´dando´ voltas e/ou replicando informações em tabelas de usuários próprias. :D
Basicamente, resolve meu problema de estar trabalhando agora com DBX, mas ainda depender do IBX para manipulação de usuários... Para os serviços de back-up, restore e reparação eu solucionei facilmente criando processos externos que executam o GBAK e GFIX, mas confesso que a manipulação de usuários ainda é uma ´pedra no meu sapato´...
Valew Anderson. :wink:
T+
Permite a verdadeira integração entre usuário da aplicação e banco sem precisar ficar ´dando´ voltas e/ou replicando informações em tabelas de usuários próprias. :D
Basicamente, resolve meu problema de estar trabalhando agora com DBX, mas ainda depender do IBX para manipulação de usuários... Para os serviços de back-up, restore e reparação eu solucionei facilmente criando processos externos que executam o GBAK e GFIX, mas confesso que a manipulação de usuários ainda é uma ´pedra no meu sapato´...
Valew Anderson. :wink:
T+
GOSTEI 0
Gandalf.nho
29/09/2004
O pessoal do Firebird tb está planejando pôr algo nesse estilo para o Firebird 2.0
GOSTEI 0