Descubra aqui como, nos processos web, pode proteger os seus recursos (dados + lógica comercial) de acessos maliciosos e de utilizadores não autorizados… com um clique.
No modo de desenvolvimento, defina a propriedade Restringir o acesso por defeito como FALSO para se concentrar na organização do seu código, no modelo de dados, na arquitetura das páginas Qodly, nos testes… sem qualquer restrição à utilização de dados ou à chamada de funções.
Quando estiver pronto para implementar perfis de utilizador, basta definir a propriedade Restringir acesso por predefinição como VERDADEIRO para garantir que ninguém acede aos seus dados e à sua lógica comercial sem ser explicitamente autorizado.
Lembrete
Desde 4D 20, 4D oferece um sistema poderoso e totalmente personalizável para proteger os recursos (dados + lógica de negócios) de usuários não autorizados.
Esse sistema oferece um nível personalizável de granularidade e se baseia na presença de privilégios na sessão. Os privilégios devem ser configurados no ficheiro roles.json e autorizados a executar algumas acções (Ler, Criar, …) em alguns recursos (classes de dados, atributos, funções).
Os privilégios são aplicados em processos da Web usando sessões da Web escalonáveis, por exemplo: Pedidos REST, repositórios de dados remotos, aplicações Qodly.
Quando o utilizador tem autorização para entrar na aplicação, a implementação da autenticação tem de colocar os privilégios adequados na sessão.
Depois, quando a aplicação recebe um pedido Web, é feito um controlo da presença de privilégios na sessão. Apenas as acções autorizadas podem ser executadas.
É apresentado um erro de permissão se a ação no recurso não for permitida.
a propriedade restringir o acesso por defeito
Com o 4D21, uma nova propriedade booleana está disponível no ficheiro roles.json: restrictedByDefault.
Ela permite configurar o comportamento padrão em relação aos acessos web aos recursos abaixo:
- o datastore
- uma classe de dados
- um atributo
- uma função de classe de modelo de dados
- uma função singleton
Isto afecta apenas os recursos para os quais não foram definidas permissões.
Se FALSO: os recursos estão acessíveis por defeito
Se não definir quaisquer permissões, todos os seus recursos estão acessíveis relativamente a qualquer ação Criar, Ler, Atualizar…
Se definir permissões, todos os seus recursos não envolvidos em permissões permanecem acessíveis.
Se VERDADEIRO: o acesso aos recursos é restringido por defeito
Se não configurar quaisquer permissões, nada nos seus recursos está acessível.
Se configurar as permissões, todos os seus recursos não envolvidos nas permissões permanecem inacessíveis.
A interface de funções e privilégios do Qodly
É provável que já tenha utilizado a interface de funções e privilégios do Qodly studio. Esta interface oferece uma interface de utilizador simples para configurar as permissões da sua aplicação. Essa interface agora oferece a possibilidade de atualizar a propriedade Restrict access by default.
com versões 4D anteriores
Se sua aplicação roda com uma versão 4D anterior, é equivalente a ter restrictedByDefault definido como FALSE. Pode obter um nível semelhante de segurança criando um privilégio all, concedido para executar todas as acções no Datastore.
E nunca dê esse privilégio all a nenhum usuário.
Iniciar um novo projeto
Quando você cria um novo projeto, o arquivo roles.json é configurado como está:
Como restrictedByDefault é False, isso ajuda a iniciar um novo desenvolvimento. Pode concentrar-se no seu código, no design dos formulários, nas chamadas de função e no acesso aos seus dados sem ser impedido.
melhores práticas
Para uma segurança óptima, quando estiver pronto para implementar perfis de utilizador, recomendamos que defina a propriedade restrictedByDefault como True e que configure privilégios para garantir:
–os seus recursos estão protegidos contra acessos maliciosos externos
–cada utilizador só pode executar acções autorizadas em dados permitidos
exemplo
No exemplo abaixo, o modelo de dados é:
No ficheiro roles.json:
assim:
– é impossível aceder à classe de dados SecretInfos (Ler, Criar, Atualizar, …)
– o privilégio viewPeople é necessário para ler a classe de dados People, outras acções na classe de dados People não são concedidas
A IDH em anexo demonstra-o.
Não espere para definir permissões para proteger a sua aplicação e os seus dados, ao mesmo tempo que trata de perfis de utilizador precisos e adequados.