tmcdonald

The main exception to this was for 2.0, which had a separate branch for a while so that people could still use bootstrap-sass while updating their application to the new syntax. When 2.0 was merged into master, since it had been under such heavy development I reconverted the entire codebase.

There are a few quirks with the conversion from Less to SCSS, but these tend to be few and far between, and are usually down to me missing a variable somewhere. The main one is the use of namespaced mixins[1]. SCSS doesn't support this, so I have to prefix/suffix the namespace to each mixin within the namespace. Aside from that, and method names/variable notation, there (appears to be, can't speak authoritatively since I haven't really used Less) little difference between the two.

  - Every GitHub Repository could be access by anyone as if they had full administrator privileges.
  - This means that anyone could commit to master. 
  - This means that anyone could reopen and close issues in issue tracker. 
  - Even the *entire* history of a project could be wiped out. Gone forever.

By default, if you have an new, create or update_attributes (and more, I imagine) call which changes various attributes based on a hash from parameters (eg params[:post], where you have params[:post][:title], params[:post][:body] etc) Rails allows mass assignment of every attribute on that model, since attr_accessible is not called.

There is a method you can call in the model called attr_accessible that restricts the columns that can be updated through mass assignment, while still allowing for manual assignment of other columns.

An example of this might be a post's user_id, which you would usually want to set to the current user while not allowing mass assignment. Without specifying attr_accessible it would mean that if a malicious user added params[:post][:user_id] to their POST/PUT, the Rails application would update the user_id as per the params value. If attr_accessible had been called, defining the columns that the developer wanted to be mass assigned (say post and title), it would mean that the user_id would not be mass assigned and Rails would log that this was the case.

attr_accessible therefore acts as a whitelist for columns that can be mass assigned. It just so happens that the Rails default is to have no whitelist and allow all columns to be mass assigned, despite the fact that the sensible option is to always have a call to attr_accessible in your models.