- Security: Sanitization and ACL.
- Sanitization is mostly in transport level. CSRF, CSS, DOS.
- ACL mostly in business logic. Roles, rules, fields. Controlled by us during software development.
- ACL: 1. Authentication, 2. Role matching / authorization, 3. Endpoint access like a controller, 4. Action access - something we can do, 5. Field access - whether the action can be done on these specific fields.
- Devise, CanCan are great. Things just basically work. But then it grows - 10s of roles, 100s of classes. Logical rules from CanCan define in a monolithical block. Then there are physical rules that are spread all over the application. Hard for new people in the team.
- Real-world example: Card model was nested through Account, Product, Widget, Sidekiq... each had different security. Difficult to handle through CanCan.
- Most apps are based on a data-centric design. Model + Concern. We want to split things based on what model they belong to.
- Concern: Presenter + CanCan + strong parameters.
- Implemented by Protector.
- Adds the dimension of a security context to models. Through a class or an instance, call
restrict!to scope everything to the context.
protectblock defined in a model class, takes the user as a block parameter, returns what that user can do using
- Can also pass the specific model instance to the block, to have permission in the scope of a single model instead of just per class.
- Nested attributes are a pain, especially with strong parameters. Rails tries to do everything in a nested save at once. If there's something invalid, you get a rollback. With protector, all associations are in the same context. You only need to protect the root of the scope.
- Can use any verbs in rules.
- Define a
scopein the protect block, to scope based on attributes based on who the user is. E.g. admins see all, otherr see
where(hidden: false). Always work, no matter how complicated your eager loading is.
- In controller, start from the
restrict!call, passing it the user that goes to the protect block, and then call the operation on that.
- ActiveRecord, Sequel, Mongoid.
- Designed so that it can be introduced to legacy code. Different modules for making existing stuff co-operate: Protector::StrongParameter, Protector::InheritedResources, Protector::SimpleForm, Protector::CanCan.
- Not just about security, but also metadata. You can introspect what's allowed or not, useful for generating routing, serialization, CRUD logic without specific code for everything.
- The Future: Finish Mongoind integration. Integrate with Data Mapper (recently resurrected as ROM)
- PaaS: JBuilder, Protector, Slash Admin.
- Projects like Meteor have a big problem with security; they don't have a good way to specify that. Something like Protector would help solving this for Ruby PaaS.
Know Your AngularJS Inside Out
Build Your Own AngularJS helps you understand everything there is to understand about AngularJS (1.x). By creating your very own implementation of AngularJS piece by piece, you gain deep insight into what makes this framework tick. Say goodbye to fixing problems by trial and error and hello to reasoning your way through them
- RuPy 2013: Building Ruby in Python
- EuroClojure 2013 - States and Nomads: Handling Software Complexity