Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

A Convention for Displaying Privileged Links

January 28th, 2013 · 4 Comments

I really hate view code like this:

- if can_manage_users
  = link_to 'Add a user', new_users_path

I want to get rid of it for a number of reasons, but the biggest reason is for cacheing. It really complicates my cacheing strategy because then I have to make keys that take into account the logged-in user or the privileges they possess, both of which will reduce the benefit of cacheing because I need a different cache for every user or privilege combo. Pfft.

Here’s what I’m replacing it with:

.privileged.can_manage_users = link_to 'Add a user', 
  new_users_path

Or maybe this…

= link_to 'Add a user', new_users_path, 
  'data-privileged' => 'can_manage_users'

To make it all work, I’ve also added the privileges to the body tag using a helper method. So, the body tag for a given user might look like this:

<body class="can_manage_privileges can_manage_users 
  can_manage_leadership can_manage_events">

Then, all I need is a little CSS to make the right links show up, like so:

.privileged {
  display: none;
}
.privileged.can_manage_users, 
.privileged.can_manage_leadership, 
.privileged.can_manage_events {
  display: block;
}

Obviously, you could do the same thing with javascript. You could argue that it makes more sense to do it with javascript because it’s a bit weird to use CSS like this and my response is… Shrug. You might be right. I’m just figuring stuff out here and am open to that approach to.

One more caveat. Obviously, this doesn’t secure your controller actions, so it’s not a replacement for authentication and privilege checking in your controllers. Sheesh, I can’t believe I felt the need to write that.

Please note this is only a half-baked idea, so feel free to suggest better ways but try not to judge me if you think this is stupid.

If you enjoyed this post, make sure you subscribe to my RSS feed!
Stumble it!

Tags: Uncategorized

4 responses so far ↓

  • 1 Drew // Jan 28, 2013 at 12:47 pm

    I guess I’m the guy you needed to write that caveat for. As I was reading it I thought, “Hold on, that’s not secure.” Because I’ve worked on systems where they used javascript to render admin links like you’re showing, and there *was no* secondary authentication on the back end.

    So while you can’t believe you need to write that … you *do* need to write it, because there are people who don’t get it.

  • 2 Anthony Panozzo // Jan 28, 2013 at 11:43 pm

    Thanks Dave, I thought this was a useful post. I haven’t worked on Rails apps with caching, so this is a good thing to keep in mind when that day comes.

  • 3 Josh // Feb 1, 2013 at 2:01 pm

    Really like this tip. I couldn’t disagree with Drew more. The server-side security isn’t a ‘secondary’ authentication – it’s _the_ authorization. The views aren’t, and shouldn’t be, responsible for ‘securing’ (which I obnoxiously put in quotes, because obviously it does nothing to secure it) links by just not showing them.
    If you read enough web server logs, the sheer number of attackers trying random URLs against your site is staggering. Not rendering the link (vs not displaying it in css) gives no security advantage.

  • 4 David Christiansen // Feb 1, 2013 at 3:40 pm

    Hi Josh,
    I think Drew actually meant the same thing as you… that the real security is on the server. And, I’m glad you like the tip!

    Dave

Leave a Comment