Oleg Andreev



Software designer with focus on user experience and security.

You may start with my selection of articles on Bitcoin.

Переводы некоторых статей на русский.



Product architect at Chain.

Author of Gitbox version control app.

Author of CoreBitcoin, a Bitcoin toolkit for Objective-C.

Author of BTCRuby, a Bitcoin toolkit for Ruby.

Former lead dev of FunGolf GPS, the best golfer's personal assistant.



I am happy to give you an interview or provide you with a consultation.
I am very interested in innovative ways to secure property and personal interactions: all the way from cryptography to user interfaces. I am not interested in trading, mining or building exchanges.

This blog enlightens people thanks to your generous donations: 1TipsuQ7CSqfQsjA9KU5jarSB1AnrVLLo

Mass assignment

1. Controller is not aware of our business logic and that’s a good thing.

 Project.new(params[:project])

2. Initializing objects using hashes is convenient. Also, DataMapper uses it internally to initialize associations.

 Project.new(:any => :param, :goes => :here)

3. Some params are special and are not allowed to be manipulated by user.

 Project.new(params[:project].reject{|k,v| 
    k.to_s =~ /^id|owner(_id)?$/ 
 })

4. Some params are not so special, but are accessible by specific user groups.

 @project.update_attributes(params[:project].reject{|k,v| 
    k.to_s =~ /^owner(_id)?$/ && 
    @project.owner != current_person  
 })

5. While models maintain consistent state of the system (key uniqueness, correct data formats and relationships), controllers maintain control flow (hence the name) along with authentication and authorization.

6. Therefore, currently used mass assignment protection implementations do not solve the problem. attr_accessible/attr_protected methods in ActiveRecord get in your way. A plugin for DataMapper I wrote yesterday also doesn’t help.

7. The right solution is a mix-in module for controllers with before filters, which should safely instantiate all necessary models.