Hacking Goldberg’s Security
Goldberg’s security all revolves around its before-filter in RAILS_ROOT/vendor/plugins/goldberg/lib/goldberg_filters.rb. The filter method in there —goldberg_security_up— used to be one big monolithic method. It worked, but unfortunately it wasn’t very flexible. Developers started to want to hack Goldberg’s security: to change the way it works, or simply to perform their own custom logging.
So now Goldberg’s before-filter has been broken up into parts. It now calls a series of protected methods, each of which you can amend or override using module_eval:
set_user:This calls Goldberg::AuthController.set_user, to set the current user based on what the session says about who’s currently logged in.check_not_pending: If self-registration is enabled, Goldberg needs to check whether the user who’s trying to access the site has had their registration confirmed properly. The risk is that someone who has self-registered could try to log in and start using the site before they’re confirmed. If so, this method kicks the user to an error page.check_not_expired: Checks whether the user’s session has expired. If so they get redirected to the session expired page.check_page_exists: Goldberg automatically tries to route unknown actions to a content page. But what if that page doesn’t exist? What if the user enters gibberish into the address bar of their browser? This method redirects the user to the “not found” page.check_permissions: Having covered all the above, Goldberg is now in a position to make a decision: does the user have the permission to invoke this action or content page, or not? It usesGoldberg.credentialsto make that decision.
