There seems to be very little written about this in the Rails literature out there, so I thought I’d make a contribution. There’s very much posted about using authorization management gems like CanCan (which is well and good) but for those of us creating a small basic app, such gems are overkill. It’s also worth using a filter just to get an understanding of what’s going on if you’re new to rails (like me!)
To create a stupid-simple authorization system that makes sure that only admins and the owner of a post can edit that post.
- You are using the devise gem and have set it up
- You have created an Admin model (Option 1 in the Devise Wiki)
(It’s really short)
To only allow admins and users that own the given post edit authorization, put the following in your post controller:
before_filter :require_permission, only: [:edit, :update, :destroy]
if current_user != Post.find(params[:id]).user
redirect_to :root, notice: "Access Denied."
(Do make your indentation better than the code above; I’m up against wordpress’s auto-correct and don’t feel like fighting with it)
Anyway, that’s it!
So why? Let’s start with the top
- We’re adding a method, called require_permission which we are defining below to the methods edit, update and destroy. Meaning any users engaging these methods must fit the requirements outlined in require_permission
- Next we define require_permission and say that if the current user is NOT the user on file for the given post… proceed.
- Then we check if the session user is an admin or, more accurately, if the user is NOT the admin (note the exclamation point). Because user and admin are two different models, devise has defined two different sets of very similar methods when referring to either one. Check them out here. It helps clarify things.
- Finally we add the redirect to the homepage with an ominous “ACCESS DENIED” message at the top.
So to recap, if the user is not the owner of the post AND not signed into the admin model, they get booted back to the homepage. Otherwise, they can do whatever they want to the post.
I’ve been using the Devise gem for a couple apps in my recent exploration of Ruby on Rails. It works pretty well and has a lot of great features but the documentation on how to best go about setting up administrators on it is a bit vague. I would write up some notes on how to do it but I’d basically be plagiarizing another post on the matter which really cleared things up for me. Check it out: http://jonallured.com/2011/04/30/using-devise-for-admin-accounts.html
if you want to import a csv to a heroku table, execute the following command:
psql `heroku config:get DATABASE_URL -a your_app`?ssl=true -c "\copy your_table FROM '/tmp/rows.csv' WITH CSV;"
your_app with the appropriate info
As I’m learning postgresql to develop with Heroku, here are my notes on some of the basic commands that are necessary to move around within the command-line interface.
Logging in under the postgres user (this would be like root in mysql)
psql -U postgres -h localhost
To list all databases:
To connect to a database (similar to
use database in mysql):
To list tables in that database:
To list the columns in a particular table:
To view all rows in a given connected table (just the standard sql command):
select * from the_table
To quit out of the psql command-line utility:
To add an existing user “frank” to an existing group “ssh”:
usermod -a -G ssh frank
To add new user “mike” to existing group “friends.”
usermod -g friends mike
To show all members in a group “people”:
sudo apt-get install members
So today my computer threw this really strange error when I was booting it up. Still don’t know what caused it but you can bet your bottom dollar that I’m backing up that hard disk now that I recovered it. While I was booting up I was confronted with the following error:
Gave up waiting for root device
I’d never seen this before and the screen looked like this (though this isn’t my image):
I booted to a live cd and found that my root file system (sda2) wouldn’t mount, nor could it be repaired by gparted. After a lot of trial and error with other solutions, I gave fsck a try (with a little help from here) and it worked like a charm. Below is what I did:
- entered sudo fsck /dev/sda2/
- This scanned my disk and immediately reported that there were problems. It asked if I wanted to fix them.
- I entered y to signify that it should do so
- fsck came up with well over 100 block count errors, asking me each time if I wanted to fix it. I kept entering y and finally threw caution to the wind and held the key down until it finished.
- I restarted and it worked.
Of course this isn’t guaranteed to fix everyone’s issue but if you’re out of ideas, give it a try. I’m sure glad that I did!
Today, I was looking to rebrand the KDE desktop with my own flair. I read this very good tutorial at techbase.kde.org. However, there were a few subtleties that I found it lacking with regard to editing the brand.svg file, as well as any other icon in a theme’s library.
A little background:
Theme data can be found in one of two key directories:
There are a couple other files that can be found here and there (for example, Ubuntu declares their own default branding for the Air theme in /usr/share/kubuntu-default-settings/kde4-profile/default/share/apps/desktoptheme/) but most themes reside in one of those two directories above.
To create one’s own theme, I recommend finding something close to what you want to create in KDE’s theme library, then access its files in one of the directories above. Virtually all of the theme’s graphics are contained in some sort of .svg file.
The tricky stuff:
The particular element that I wanted to edit is the little bit of branding in the upper right-hand corner of the application launcher menu as depicted below. However this procedure applies to just about all aesthetic edits in the theme.
Now the particular theme that I happened to be editing was called “Androbit.” But this principle should work for all themes (maybe with some minor variation).
- To edit the icon, I navigated to the file /home/sam/.local/share/Trash/files/Androbit/widgets/branding.svg. The file for this in pretty much all themes seems to be branding.svg or branding.svgz.
- An svg is a vector image. The go-to open source tool to edit one of these is Inkscape. Don’t open it in Gimp or alike because, while gimp can open vector graphics it will save them as bitmaps which is no good for what we’re doing. So, open it in Inkscape.
- Once you’re in inkscape, you’ll need to grab some key info from the existing icon that’s necessary to properly insert your brand object into the theme.
- Select the item and right click on it and select “Object Properties”.
- Within the “Object Properties” window, you will find two text strings: “Id” and “Label”. Write down both strings; you’ll need them in a couple steps.
- Now, go ahead and delete the original bit of branding and put your own in its place.
- Now, to make this text show up, we have to convert it to a path. This step is a bit odd and I can’t tell if it’s a glitch with Inkscape or if it’s meant to be that way but in either case, here we go. Note: if it’s just an image that you put in, you won’t need to do this step.
- Select the text object you just wrote in.
- Next, go up to path and select “Object to Path.”
- There, now the text will show up in the theme (only took me a couple hours to figure that out).
- Now, remember that text string from step 2? Good, you’ll need them. Right click on your new object and select “Object Properties.” (Just like before)
- Then write in the two text strings for “Id” and “Label.”
- Now save the file and that’s it. Your new branding should be in your application launcher menu.