Rails Course: Add lesson on authorization

[JoshDevHub]

Checks

• This is not a duplicate of an existing issue (please have a look through our open issues list to make sure)
• I have thoroughly read and understand The Odin Project Contributing Guide
• Would you like to work on this issue?

Describe your suggestion

This has been something that's long been on my mind as a bit of a gap in the current Rails course content. Authorization is never deeply discussed despite being an important concept in any real world app. The NodeJS course also at least touches on it some, requiring basic permission systems in some of the course's projects.

I'm not entirely sure about where the lesson should go. Placing it prior to Members Only feels slightly wrong because learners will have just been introduced to authentication, and that's a whole big thing to itself. I think before Private Events could be nice, and authorization concepts fit that project nicely. But also authorization doesn't have much to do with that course section's focus on Advanced Forms and Active Record. This is definitely one of the big things I'd like some feedback on.

For the proposed content, here's a brief outline of what I had in mind. Again, I'm definitely open to feedback:

• Introduction to authorization. What is it? What is its relationship to authentication?
• A basic authorization rule for most CRUD apps: respecting a user's "ownership" over the resources they create (ie. in a blog app, User1 shouldn't be able to edit or delete User2's blog posts)
  • Talk through some solutions:
    • For privileged actions, scope queries to the current user.

      def edit
        # probably not good
        @post = Post.find(params[:id])
      
        # good
        @post = current_user.posts.find(params[:id])
      end

    • Avoid embedding the current user's id in parameters and relying on that to tell who the user is on the backend. Even hidden form fields can be tampered with. Instead, always use the session to get the current user (ie. through Devise's current_user method).
• Permission systems and Role Based Access Control (RBAC).
  • What is this? Mention examples.
  • Keeping things completely separated when possible
    • For example, maybe to view the admin dashboard, you have to visit an admin login portal and enter credentials to login as an admin. The implementation for the admin section (routes, controllers, views, user model) is completely distinct and disconnected from the implementation of the flow for normal users. Discuss the benefits of this separation.
  • Sometimes not possible or practical to separate. Users with different roles/permissions may be using the app in similar ways and take actions that heavily overlap (good example might be a discord server?). Introduces the concept of the user having "roles", which are then checked to determine what actions they can take.
• Implementation Stuff
  • Maybe stuff about encoding role info? enum on user model or Role model where a user has_many :roles (depending on how complex your needs are)
  • Policy Objects: What are they? How are they used?
• Library solutions: Pundit, CanCanCan, ActionPolicy
  • Good to be aware of and can be good to read docs on these to grok some authorization patterns
  • Mention that this kind of solution is probably overkill for any app the learner is building in the curriculum.
• And of course, finding some external sources to link to that cover the topic in a Rails context.

Glad to accept any comments/feedback on this!

Path

Ruby / Rails

Lesson Url

Rails Course

(Optional) Discord Name

No response

(Optional) Additional Comments

No response

[KevinMulhern]

I think this would be a great addition, @JoshDevHub. The outline looks like it covers every important - 10/10, no notes.

For placement, I’d lean slightly toward the Forms and Authentication section as the most natural fit, since authorization builds directly on authentication. We could extend Members Only with an admin-specific requirement (e.g., allowing admins to pin posts), and reinforce the concept by adding a few role-based access requirements to Private Events or Flight Booker.

But, placing it right before Private Events would work just as well. We introduced enums in that section, but they aren't meaningfully practiced afterward I think. An authorisation lesson here would help close that loop and turn the concept into something learners could apply in a real-word kind of context.