Quando você precisa autenticar em uma aplicação, um banco de dados de credenciais está lá para verificar se a informação que você está colocando é realmente verdadeira. Só que isso não é o suficiente para garantir permissões de acesso corretamente.
E enquanto isso a Shodan fica de olho nessa zueira aí que você ta fazendo.
Esse é o Hardcore Devel! E acho que eu vou começar a colocar a SHODAN, ou talvez a GladOS pra ilustrar isso porque elas são excelentes inteligências artificias. Hoje vamos falar sobre um protocolo de bancos de dados hierárquicos.
Mentira eu não vou falar do protocolo não. Até porque você pode achar toda a especificação do protocolo nas RFCs. LDAP é apenas um DAP, que nada mais é que um protocolo de acesso de diretórios. O L do LDAP significa Lightweight, o que quer apenas dizer que o protocolo evoluiu para uma coisa melhor.
Como todo bom protocolo, o LDAP não é uma aplicação e sim um padrão de envio e recebimento de mensagens antes da camada de aplicação, ou então sendo o próprio protocolo da camada de aplicação. Essas aplicações que suportam LDAP são geralmente aplicações no estilo cliente x servidor. Esse segundo é geralmente um servidor de banco de dados.
E nesse caso, um banco de dados hierárquico.
Tá. O que que isso significa? Isso significa que a estrutura dos dados não é mais em forma de tabela, e sim em forma de árvore, igual as pastas que você tenta organizar no seu computador. Pois é, essas pastas estão organizadas como uma árvore. Obviamente você não mexe na organização da árvore pra ela não ir toda pros cacete e você não achar mais pasta nenhuma.
E é bem nesse sentido mesmo. O LDAP organiza pastas de hierarquia. Geralmente quem está mais perto da pasta raiz tem mais privilégios e permissões e podem mandar mais no sistema, mas obviamente é possível trocar essa regra, afinal quem está mexendo com o banco de dados hierárquico que define como é que ele vai funcionar.
A grande brincadeira é que ele é um protocolo muito interessante para autenticação de usuários e concessão de permissões. Se você tentar conceder permissões em um banco de dados relacional você vai sofrer muito, pois você vai ter que trabalhar com várias flags de atributos. Coisas que os containers do LDAP podem fazer facilmente.
Existem outras coisas interessantes que os bancos de dados hierarquicos conseguem fazer. A unicidade do objeto é geralmente garantida pela existência dele na árvore. Se ele for um vértice da árvore, ele certamente é único, e não é incomum que esses vértices façam referências uns aos outros, referências que são atualizadas automaticamente caso você queira mudar um vértice de lugar.
Eu aprendi a pouco tempo a mexer com esse tipo de banco de dados e posso dizer certamente que é uma coisa interessante, e que a informática tem muitas soluções para os problemas. Tem tantas que chega a ser dificil escolher quando usar qual.
Mas o LDAP vale bastante a pena para criar bancos de dados hierárquicos de autenticação, hehe.
Esse é o Hardcore Devel! E acho que eu vou começar a colocar a SHODAN, ou talvez a GladOS pra ilustrar isso porque elas são excelentes inteligências artificias. Hoje vamos falar sobre um protocolo de bancos de dados hierárquicos.
Mentira eu não vou falar do protocolo não. Até porque você pode achar toda a especificação do protocolo nas RFCs. LDAP é apenas um DAP, que nada mais é que um protocolo de acesso de diretórios. O L do LDAP significa Lightweight, o que quer apenas dizer que o protocolo evoluiu para uma coisa melhor.
Como todo bom protocolo, o LDAP não é uma aplicação e sim um padrão de envio e recebimento de mensagens antes da camada de aplicação, ou então sendo o próprio protocolo da camada de aplicação. Essas aplicações que suportam LDAP são geralmente aplicações no estilo cliente x servidor. Esse segundo é geralmente um servidor de banco de dados.
E nesse caso, um banco de dados hierárquico.
Tá. O que que isso significa? Isso significa que a estrutura dos dados não é mais em forma de tabela, e sim em forma de árvore, igual as pastas que você tenta organizar no seu computador. Pois é, essas pastas estão organizadas como uma árvore. Obviamente você não mexe na organização da árvore pra ela não ir toda pros cacete e você não achar mais pasta nenhuma.
E é bem nesse sentido mesmo. O LDAP organiza pastas de hierarquia. Geralmente quem está mais perto da pasta raiz tem mais privilégios e permissões e podem mandar mais no sistema, mas obviamente é possível trocar essa regra, afinal quem está mexendo com o banco de dados hierárquico que define como é que ele vai funcionar.
A grande brincadeira é que ele é um protocolo muito interessante para autenticação de usuários e concessão de permissões. Se você tentar conceder permissões em um banco de dados relacional você vai sofrer muito, pois você vai ter que trabalhar com várias flags de atributos. Coisas que os containers do LDAP podem fazer facilmente.
Existem outras coisas interessantes que os bancos de dados hierarquicos conseguem fazer. A unicidade do objeto é geralmente garantida pela existência dele na árvore. Se ele for um vértice da árvore, ele certamente é único, e não é incomum que esses vértices façam referências uns aos outros, referências que são atualizadas automaticamente caso você queira mudar um vértice de lugar.
Eu aprendi a pouco tempo a mexer com esse tipo de banco de dados e posso dizer certamente que é uma coisa interessante, e que a informática tem muitas soluções para os problemas. Tem tantas que chega a ser dificil escolher quando usar qual.
Mas o LDAP vale bastante a pena para criar bancos de dados hierárquicos de autenticação, hehe.
Nenhum comentário:
Postar um comentário