The second question I've got revolves around model scaffolds. The way in which scaffolds work strike me as having significant potential to be surprising/dangerous.
Right now if you have a model and create a controller you still get default behaviour of scaffolds unless you specifically overwrite all possible scaffold actions.
Although the possibility for code duplication would be higher for some applications, I believe for the vast majority of applications you'd want to customise the default scaffold behaviour anyway (my use cases for sails might be unusual, but I'd imagine not). It makes more sense to me if a controller was generated at the same time as a model, with the default actions. That way users of sails explicitly know how this works, can use the generated code as a starting point, and know that if they delete an action it's gone.
- taa
On the other hand, in production, for several of our customer apps, 80% of our backend is served using the scaffolds, and for a lot of basic functionality, they serve the purpose (search, sorting, pagination,
For instance, right now, if you set ?redirect=http://google.com when hitting /model/create, you'll get redirected to the destination you specify.
re: access control/multitenancyIn general, you shouldn't be mixing authentication/access control code into your controllers. Business logic and auth don't mix, and have very ugly offspring. In my experience, this is where most leaks occur.