Permissão de acesso a determinado registros da tabelas
Ola pessoal,alguem poderia me dar uma ideia de como liberar acessos a tals registros de tabelas?
tenho uma tabela onde tenho cadastro de usuarios senhas e permissões, preciso que o administrator tenha acesso a tudo e o operador só tenha acesso ao eventos liberados pelo administrador .
Exemplo tabela eventos contem o nome e data do evento,preciso que conforme cadastre um usuario novo na tabela de usuarios,esse usuario tenha ou não acesso a esse certo evento.
tabela usuario.
Tabela eventos
Não Faço ideia de como fazer essa liberação com o banco , nao sei se crio mais uma tabela e faço relacaionameto,to meio perdido.
Eu preciso que de alguma forma depois q o usuario seja cadatrado com as pemissões dos eventos que ele possa ter acesso,quando ele logar, que em um combobox ou algo do tipo apareça todos os eventos que ele tem permissao, alguem pode me dar uma ajuda,nao sei se especifiquei legal?
tenho uma tabela onde tenho cadastro de usuarios senhas e permissões, preciso que o administrator tenha acesso a tudo e o operador só tenha acesso ao eventos liberados pelo administrador .
Exemplo tabela eventos contem o nome e data do evento,preciso que conforme cadastre um usuario novo na tabela de usuarios,esse usuario tenha ou não acesso a esse certo evento.
tabela usuario.
id nome senha permissao 1 Thallys 1234 admistrador 2 Victor 4321 Operador
Tabela eventos
id Evento Data 1 teste 01/01/24 2 teste 1 30/02/24
Não Faço ideia de como fazer essa liberação com o banco , nao sei se crio mais uma tabela e faço relacaionameto,to meio perdido.
Eu preciso que de alguma forma depois q o usuario seja cadatrado com as pemissões dos eventos que ele possa ter acesso,quando ele logar, que em um combobox ou algo do tipo apareça todos os eventos que ele tem permissao, alguem pode me dar uma ajuda,nao sei se especifiquei legal?
Alan
Curtidas 0
Melhor post
Arthur Heinrich
13/10/2023
event_types (event_type, event_name)
event_type event_name
---------- --------------
1 Security
2 Application
3 Administrative
events (id, event_type, event, date)
id event_type event date
-- ---------- ----------------------------- -------------------
1 1 User xpto failed to login 10/10/2023 14:52:00
2 2 Report sent 11/10/2023 10:00:00
3 3 Backup completed successfully 11/10/2023 21:35:00
roles (id_role, role__name)
id_role role_name
------- ---------------
1 Administrator
2 Normal User
3 Report Operator
users (id_usuario, Usuario, Login, Senha)
id_usuario Usuario Login Senha
---------- --------- ----- -----
1 Chefe chefe xxxx
2 Usuário 1 user1 xxyy
user_roles (id_usuario, id_role)
id_usuario id_role
---------- -------
1 1
2 2
role_event_types (id_role, event_types)
id_role event_types
------- -----------
1 1
1 2
1 3
2 2
GOSTEI 1
Mais Respostas
Arthur Heinrich
11/10/2023
Existem várias maneiras de controlar o acesso e algumas dependem do banco.
Por exemplo, através de recursos de mascaramento, podemos ocultar seletivamente dados de colunas que não podem ser exibidos para alguns usuários. Na sua tabela de usuários, os administradores enxergam as senhas, mas um usuário com menos privilégios poderia ver esta coluna mascarada. Isto pode ser feito em alguns bancos, como Oracle e SQL Server.
No seu caso, a ideia parece ser filtrar linhas da tabela que determinados usuários podem ou não acessar.
Em condições como estas, os bancos de dados não costumam oferecer um recurso específico, mas você pode utilizar views para isso.
Ao invés de conceder acesso direto à tabela de eventos, você pode construir uma view que faça join com uma tabela que contenha dados sobre os tipos de eventos que um usuário pode acessar.
No MySQL, existe uma função chamada USER(), que retorna o login e a máquina de origem, no seguinte formato: <login>@<machine>.
Você pode extrair o login usando: substring(user(),1,instr(user(),'@')-1)
Para criar um sistema adequado de permissões, pense no seguinte.
Você terá uma tabela de usuários, contendo (id, login, nome, ...).
Terá uma tabela para cadastrar os papéis (roles) de cada usuário. Por exemplo, 'Administrador', 'Usuário', etc.. Ela terá os campos (id_user, id_role)
Para cada perfil, você terá que relacionar os tipos de eventos que cada usuário tem acesso, contendo (id_role, event_type)
Na sua tabela de eventos, você terá uma coluna para indicar de que tipo de evento estamos falando: aplicação, segurança, administrativo, etc.
Então, sua view vai relacionar tudo isso:
Aí, você remove o acesso na tabela de eventos para todos os usuários, exceto o dono do banco e lhes dá acesso à view.
Na tabela user_roles você diz quais roles o usuário tem acesso.
Na tabela role_event_types você diz que tipos de evento cada role pode acessar.
Por exemplo, através de recursos de mascaramento, podemos ocultar seletivamente dados de colunas que não podem ser exibidos para alguns usuários. Na sua tabela de usuários, os administradores enxergam as senhas, mas um usuário com menos privilégios poderia ver esta coluna mascarada. Isto pode ser feito em alguns bancos, como Oracle e SQL Server.
No seu caso, a ideia parece ser filtrar linhas da tabela que determinados usuários podem ou não acessar.
Em condições como estas, os bancos de dados não costumam oferecer um recurso específico, mas você pode utilizar views para isso.
Ao invés de conceder acesso direto à tabela de eventos, você pode construir uma view que faça join com uma tabela que contenha dados sobre os tipos de eventos que um usuário pode acessar.
No MySQL, existe uma função chamada USER(), que retorna o login e a máquina de origem, no seguinte formato: <login>@<machine>.
Você pode extrair o login usando: substring(user(),1,instr(user(),'@')-1)
Para criar um sistema adequado de permissões, pense no seguinte.
Você terá uma tabela de usuários, contendo (id, login, nome, ...).
Terá uma tabela para cadastrar os papéis (roles) de cada usuário. Por exemplo, 'Administrador', 'Usuário', etc.. Ela terá os campos (id_user, id_role)
Para cada perfil, você terá que relacionar os tipos de eventos que cada usuário tem acesso, contendo (id_role, event_type)
Na sua tabela de eventos, você terá uma coluna para indicar de que tipo de evento estamos falando: aplicação, segurança, administrativo, etc.
Então, sua view vai relacionar tudo isso:
select e.*
from events e
where
e.event_type in (select ret.event_type
from
users u
join user_roles ur on ur.id_user = u.id
join role_event_types ret on ret.id_role = ur.id_role
where
u.login = substring(user(),1,instr(user(),'@')-1))
Aí, você remove o acesso na tabela de eventos para todos os usuários, exceto o dono do banco e lhes dá acesso à view.
Na tabela user_roles você diz quais roles o usuário tem acesso.
Na tabela role_event_types você diz que tipos de evento cada role pode acessar.
GOSTEI 0
Alan
11/10/2023
Arthur não entendi muito bem, no caso entao terei que ter a tabela de usuarios que contem os campos (id_usuario,Usuario,Login,Senha)
uma tabela de Pemissao com os campos (Id_permissao,Id_usuario,permissao) ,permissão no caso seria ADMINISTRADOR e USUARIO correto?
e na minha tabela Eventos teria que ter os campos (Id_evento, Id_permissao ,Evento,Data,Tipo_evento) é isso?
uma tabela de Pemissao com os campos (Id_permissao,Id_usuario,permissao) ,permissão no caso seria ADMINISTRADOR e USUARIO correto?
e na minha tabela Eventos teria que ter os campos (Id_evento, Id_permissao ,Evento,Data,Tipo_evento) é isso?
GOSTEI 0
Alan
11/10/2023
event_types (event_type, event_name)
event_type event_name
---------- --------------
1 Security
2 Application
3 Administrative
events (id, event_type, event, date)
id event_type event date
-- ---------- ----------------------------- -------------------
1 1 User xpto failed to login 10/10/2023 14:52:00
2 2 Report sent 11/10/2023 10:00:00
3 3 Backup completed successfully 11/10/2023 21:35:00
roles (id_role, role__name)
id_role role_name
------- ---------------
1 Administrator
2 Normal User
3 Report Operator
users (id_usuario, Usuario, Login, Senha)
id_usuario Usuario Login Senha
---------- --------- ----- -----
1 Chefe chefe xxxx
2 Usuário 1 user1 xxyy
user_roles (id_usuario, id_role)
id_usuario id_role
---------- -------
1 1
2 2
role_event_types (id_role, event_types)
id_role event_types
------- -----------
1 1
1 2
1 3
2 2
Blz Arthur deu certo aqui,Cara deixa eu te falar ,no sistema aqui que eu estou criando, vou precisar de fazer comunicação com várias controladoras conectadas ao mesmo tempo,usando o tcpclient e tcp server,hj eu consegui fazer a comunicação com uma só,seguindo um fonte do fabricante da controladora,não consegui achar artigo ou algo do tipo para fazer múltiplas conexões com o tcp server e o client,vou tentar mais algumas coisas aqui ,mas caso não consiga queria saber se você pode me passar um orçamento seu ,pelo seu conhecimento acho q você tiraria de letra ,se sim te passo meu email,pra você me chamar.Obrigado.
GOSTEI 0
Arthur Heinrich
11/10/2023
O componente "Server", que é quem fica "escutando" a porta, abre uma conexão para cada origem, armazenando um array de sockets com cada usuário conectado.
O componente "Client", por sua vez, é a origem de uma conexão. Cada componente só pode se conectar a um único destino, podendo o componente ser reutilizado para várias conexões serializadas, desconectando de um destino e reconectando em outro.
Para permitir múltiplas conexões simultâneas como origem, acessando diversos destinos simultaneamente, é necessário degenciar múltiplos componentes do tipo "Client", um para cada destino.
No momento, não estou aceitando serviços eventuais. Já tenho muitos compromissos e não poderia lhe dar a atenção que um cliente merece. Peço desculpas por não poder lhe ajudar nesse desenvolvimento.
O componente "Client", por sua vez, é a origem de uma conexão. Cada componente só pode se conectar a um único destino, podendo o componente ser reutilizado para várias conexões serializadas, desconectando de um destino e reconectando em outro.
Para permitir múltiplas conexões simultâneas como origem, acessando diversos destinos simultaneamente, é necessário degenciar múltiplos componentes do tipo "Client", um para cada destino.
No momento, não estou aceitando serviços eventuais. Já tenho muitos compromissos e não poderia lhe dar a atenção que um cliente merece. Peço desculpas por não poder lhe ajudar nesse desenvolvimento.
GOSTEI 0
Alan
11/10/2023
Tranquilo Arthur,sem problemas,eu super entendo,então no caso como vai ser difícil saber a quantidade de controladoras que serão conectadas o certo seria eu fazer uma varredura na tabela e criar o tcpclient em tempo de execução de acordo com o status das controladoras, seria mais ou menos isso ?
GOSTEI 0
Arthur Heinrich
11/10/2023
O ideal, aqui, é utilizar orientação a objetos.
Você pode definir uma classe para a controladora. Nesta classe você terá as informações que identificam a controladora, como nome, endereço de IP e porta.
Internamente, esta classe conterá um ClientSocket e métodos para abrir e fechar a conexão, bem como enviar e receber dados.
Assim, fica mais fácil controlar cada conexão, individualmente.
Depois, você pode utilizar um componente TObjectList, ou coisa do tipo, para armazenar sua lista de múltiplos objetos do tipo controladora, podendo adicionar ou remover controladoras, conforme a necessidade, ou criar uma estrutura sua, para armazenar os sockets, como um array dinâmico, ou outra forma qualquer.
Dependendo da classe de origem, utilizada para a criação da classe controladora, pode ser até mesmo um "componente", com propriedades visuais, que poderia ser exibido em um dashboard, por exemplo.
Você pode definir uma classe para a controladora. Nesta classe você terá as informações que identificam a controladora, como nome, endereço de IP e porta.
Internamente, esta classe conterá um ClientSocket e métodos para abrir e fechar a conexão, bem como enviar e receber dados.
Assim, fica mais fácil controlar cada conexão, individualmente.
Depois, você pode utilizar um componente TObjectList, ou coisa do tipo, para armazenar sua lista de múltiplos objetos do tipo controladora, podendo adicionar ou remover controladoras, conforme a necessidade, ou criar uma estrutura sua, para armazenar os sockets, como um array dinâmico, ou outra forma qualquer.
Dependendo da classe de origem, utilizada para a criação da classe controladora, pode ser até mesmo um "componente", com propriedades visuais, que poderia ser exibido em um dashboard, por exemplo.
GOSTEI 1
Alan
11/10/2023
O ideal, aqui, é utilizar orientação a objetos.
Você pode definir uma classe para a controladora. Nesta classe você terá as informações que identificam a controladora, como nome, endereço de IP e porta.
Internamente, esta classe conterá um ClientSocket e métodos para abrir e fechar a conexão, bem como enviar e receber dados.
Assim, fica mais fácil controlar cada conexão, individualmente.
Depois, você pode utilizar um componente TObjectList, ou coisa do tipo, para armazenar sua lista de múltiplos objetos do tipo controladora, podendo adicionar ou remover controladoras, conforme a necessidade, ou criar uma estrutura sua, para armazenar os sockets, como um array dinâmico, ou outra forma qualquer.
Dependendo da classe de origem, utilizada para a criação da classe controladora, pode ser até mesmo um "componente", com propriedades visuais, que poderia ser exibido em um dashboard, por exemplo.
Arthur consegue me dar um exemplo detalhado disso ?
Você pode definir uma classe para a controladora. Nesta classe você terá as informações que identificam a controladora, como nome, endereço de IP e porta.
Internamente, esta classe conterá um ClientSocket e métodos para abrir e fechar a conexão, bem como enviar e receber dados.
Assim, fica mais fácil controlar cada conexão, individualmente.
Depois, você pode utilizar um componente TObjectList, ou coisa do tipo, para armazenar sua lista de múltiplos objetos do tipo controladora, podendo adicionar ou remover controladoras, conforme a necessidade, ou criar uma estrutura sua, para armazenar os sockets, como um array dinâmico, ou outra forma qualquer.
Dependendo da classe de origem, utilizada para a criação da classe controladora, pode ser até mesmo um "componente", com propriedades visuais, que poderia ser exibido em um dashboard, por exemplo.
GOSTEI 0