ORDA – Permissões – Restringir / permitir o acesso da Web aos recursos com um só clique

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.