Skip to content

Instantly share code, notes, and snippets.

@alvesjnr
Forked from wycats/security.md
Created March 5, 2012 13:01
Show Gist options
  • Save alvesjnr/1978219 to your computer and use it in GitHub Desktop.
Save alvesjnr/1978219 to your computer and use it in GitHub Desktop.

Proposal for Improving Mass Assignment

For a while, I have felt that the following is the correct way to improve the mass assignment problem without increasing the burden on new users. Now that the problem with the Rails default has been brought up again, it's a good time to revisit it.

Sign Allowed Fields

When creating a form with form_for, include a signed token including all of the fields that were created at form creation time. Only these fields are allowed.

To allow new known fields to be added via JS, we could add:

<%= f.allowed_fields "foo", "bar", "baz" %>

Mark accessible fields in the controller

The first strategy will not full satisfy apps that support a lot of HTTP requests that do not come from forms generated by Rails.

Because accessible fields is usually a function of authorization, and is not global, we should move allowed fields into the controller. The basic idea is:

import tests_runner

ROOT_PATH = "~"
DEFAULT_TARGET_PATH = '~'
DIST_FILE_VERSION = 'v0'
FOLDER_SEPARATOR = os.sep
WINDOW_TITLE = 'Dist Share'

class App(object):

    origin_path = ''
    
    def __init__(self,root):

        
        self.root = root

        self.tree_view = None
        self.changed = False

        #Project issues
        self.project_name = None
        self.project_file_path = None #path of the file .dist

        self.menubar = tk.Menu(self.root)
        self.filemenu = tk.Menu(self.menubar, tearoff=0)
        self.filemenu.add_command(label="Open Project", command=self.load_project)

I would imagine that Rails authorization frameworks like CanCan could add sugar to make this even easier in common cases.

Conclusion

The core problem with Rails mass assignment is that attribute protection is an authorization concern. By moving it to the controller, we can have smart defaults (like signed fields in form_for) and in more advanced cases, make it easier to decide what fields are allowed on a per-user basis.

By moving it into the correct place, we will probably find other nice abstractions that we can use over time to make nice defaults for users without compromising security.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment