Speakerline

Edit a proposal

Title Tags (comma-separated, max 3) Body

# Abstract

Rails brings us a lot of useful tools out-of-the-box, but there are missing parts too. For example, for such essential task as **authorization** we are on our own.

Even if we choose a trending OSS solution, we still have to care about the way to keep our code maintainable, efficient, and, of course, bug-less.

Working on Rails projects I've noticed some common patterns in designing access systems as long as useful code techniques I'd like to share with you in this talk.

# Details

Let's discuss first what _authorization_ is:

- When we need it?

I want to provide some simple examples of plain old Ruby authorization techniques in our controllers (e.g., "no one can delete my tweet except from myself and superadmin").
That's a problem statement; just to make sure that everyone is familiar with what I'm going to talk about.

- What is the place of authorization layer in Rails application?

We've already learned about controllers. What else? Views, channels, etc.

- What are the main paradigms?

A note about activity-based checks vs. role-based checks (_RBAC_). We're gonna talk about activity-based checks only in the rest of the talk.

Unfortunately, Rails doesn't provide authorization framework out-of-the-box. So, we have to choose an existing library or build one ourselves. Anyway, we need a way to organize our access-related code.

What about existing solutions? There are two popular libraries: **cancan(can)** and **pundit**. I've been actively using both (though finally migrated to the latter one) and none of those two satisfied all my needs. That's why I started thinking about a new, _ideal_, framework for authorization (spoiler: it's already WIP, and some ideas from it have been in production for years already).

What do I want (and, I guess, most of you too) from this dream-library? There are some keys points:

- Magic vs. boilerplate balance
- Performance (per-thread memoization, cache)
- Namespaces (_modules_)
- Testability (Where to test authorization policies? How to do that efficiently?)
- Frontend vs. Backend
- More meaningful "Access Denied" message (i.e., how do I know why a feature was authorized or not?)

I want to discuss this features, show some examples and demonstrate some techniques for writing efficient authorization-level code.

This talk is a **missing guide to authorization in Rails**. At least, that's what I want it to be)

So, it fits everyone from newcomers to experienced Rubyists (and event non-Ruby-lovers).

# Pitch

Can you imagine a Rails app without any access checks? I guess you can _imagine_. But what about real-world? It's not easy to find one (though possible, of course).

Does this problem deserve too much attention (_the whole talk_)? I believe it does. That's why I'm here)

There are a lot of questions when dealing with authorization:

- Which approach/framework to choose?
- How to test user-resource access?
- How to organize policies/abilities/whatever?
- What are the typical caveats/pitfalls?
- ...and more.

And it's not easy to find all the answers (well, at least it was not easy for me), especially in one place–and I want to fix it.

The title of talk describes the main idea–provide a useful piece of information for everyone struggling with authorization in Rails.

Back to Speaker Directory