Camada de segurança

[gabriel-laet]

Braindump do que poderia ser essa camada.

Collections

• Controlar quais métodos você permite para uma collection (GET, POST, PUT, DELETE)
• Como os campos de uma collection devem se comportar dependendo do verbo (por exemplo: você não quer que e-mail/password apareçam no GET de users)
• Atrelar rows de Collections a usuários. Proteger rows a partir de autenticação: um item criado pelo usuário X, não pode ser atualizado/apagado pelo user Y;
• Adicionar "roles" no middleware de autenticação, para identifiicar se um usuário é superadmin ou não;

Keys / servers

• Registrar junto com o API key uma lista de allowed hosts, e travar requests a partir do HTTP_REFERER;

Acho que o formato disso pode ser bem declarativo, em um JSON ou mesmo em um settings.php do teu app, que é registrado junto da aplicação. Podemos definir também que o default já cuida do básico: não permitir drop de uma tabela, e nem DELETE sem autenticação;

[endel]

Para referência:

• JSON Hijacking: http://stackoverflow.com/questions/2669690/why-does-google-prepend-while1-to-their-json-responses

[gabriel-laet]

Outras possibildadedes:

• http://www.jcryption.org/
• Pensar também em algo mais simples, tipo um JSON obfuscator

[endel]

Fechando aqui, vamos quebrar essa issue com essas:

• https://github.com/doubleleft/dl-api/issues/73
• https://github.com/doubleleft/dl-api/issues/75
• https://github.com/doubleleft/dl-api/issues/76
• https://github.com/doubleleft/dl-api/issues/77
• https://github.com/doubleleft/dl-api/issues/79
• https://github.com/doubleleft/dl-api/issues/80