Kraig's Profile

The Stack question, and hopefully answer...

I came back to this solution while I was trying to teach myself code optimization and refactoring.

I tried as an exercise refactoring class MemberPermission < BasePermission to class MemberPermission < GuestPermission, seeing as how much of the static pages logic, etc. is being duplicated. I thought that is Members could inherit all the permissions of a guest, then it would be better.

However, the filter chain halts as :authorize redirects in an infinite loop. Generally, this means that a permission hasn't been defined for that user and it's trying to redirect to static#home.

I was wondering if anyone has any insight on this? I'll post to Stack as well..

While Ryan is on his Sabbatical, I think it important to keep some of this information up-to-date with the changes. Ryan developed a well-deserved reputation and his RailsCasts are referenced just about anywhere you can google a rails problem/solution.

As such, I want to comment on a couple of things regarding this episode.

The strong_parameters gem is automatically implemented in this episode. This is confusing because the docs for s_p shows controller-level checking, which has now become the standard for all Rails 4 apps.

You may notice that there isn't a method permitted_params inside the application_controller. All whitelisting logic has been moved to the application controller via the authorize method, which calls current_permission. All strong_parameters checking is now handled by base_permission.rb inside the permit_params!(params) method and delegated to each of the permission classes - Admin, Member and Guest.

I found it very advantageous to rename some of Ryan's code. In the video, he recommends renaming the allow method to allow_action. DO THIS. Also, I took the liberty of renaming the allow_param method to allow_attribute, since that is what is being allowed and it removes identity confusion with the params hash.

All-in-all, this is a great starting point for any Rails-based app. All you need to do is fork the code from GitHub, include the rename gem to change the name of the app, and start building your models. For each model you include, go back and whitelist the appropriate attributes (model fields) with the appropriate authorizations (admin, guest, etc.) Voila! Instant authorization including mass-assignment protection.

Now, just pop on over to RC#250 (revised) and roll your own authentication. Both episodes merge without problems. Now you have a fully functional template for building just about anything.

One thing that isn't clear is this: Does a User have to authenticate with Twitter (through, like OmniAuth), or can they just authorize an app with read | read/write access?

I would like to know if anyone has ever implemented their own registration/login system like what Ryan demonstrates here, and also include OmniAuth for authorizing external APIs like Facebook, etc.?

I have a specification that requires the user to register/login through our system, but they still need external API authorization(account access, data sharing, etc.) this means that even though they can tie in social media account and share information back and forth, they can't use an external API to register for our site. Does anyone have any suggestions? I guess my first question is - is what we need to do compatible with what OmniAuth allows?

Has anyone tried to implement an Activity tracker (see ep. 407, et.al) with this?

I prefer this approach to that of StrongParameters, which is now part of Rails4. Anyone have an idea of how this approach compares to SP? I ask because this episode was produced after your StrongParameters episode.