Permissions and roles

148 views
Skip to first unread message

lawrence...@gmail.com

unread,
Mar 15, 2015, 2:05:57 AM3/15/15
to refine...@googlegroups.com
I am trying to find out how permissions work in RefineryCMS. The wiki does not mention permissions, nor is there a guide on the official site about permissions. When I search this Google Group, almost all of the posts are from 2011 and 2012. When I search Google, I get pointed to plugins which have not been updated in 3 years, such as this one:


Judging by what I can find in Google, this issue of permissions and roles for users was something that got a lot of attention 3 years ago, but either gets less attention now, or gets less of the kind of discussion that Google is willing to rank highly. 

Can anyone point me to some basic info about how roles and permissions work in RefineryCMS? I am building a site that will have 2 roles: admins and visitors. I am curious if I can do this with RefineryCMS, or if I need to install Devise and then integrate the 2. 

Philip Arndt

unread,
Mar 15, 2015, 2:07:46 AM3/15/15
to refine...@googlegroups.com
Refinery doesn't really have anything to do with permissions out of the box. 

Is a visitor simply a logged out user?  If they are, and you're only concerned with visitors and admins, then it sounds like the current functionality would suit you just fine.

Otherwise you could leverage the built in `Refinery::Role` structures, but this depends on how complex you need it to be.

lawrence...@gmail.com

unread,
Mar 15, 2015, 4:02:21 AM3/15/15
to refine...@googlegroups.com
Can you point me to anything that might have been written about `Refinery::Role` structures? I tried various searches such as:

permissions site:refinerycms.com

but this comes up with nothing. I've also searches for words like "roles" and "membership", but Google can only find plugins that are 3 years old: 


I'm building a fairly simple site that needs 2 types of users who can log in:

1.) an admin type who can get to the RefineryCMS dashboard

2.) a "member" who is allowed to see some pages that are kept hidden from the general public

I am curious if I can do this with just RefineryCMS, or if I need go with Devise/CanCan to build the site, and then integrate that site with RefineryCMS? 

I found an article from 2011 where someone suggested they were going to build a site and create a unique engine that would have some unique content and which would be limited to a specific type of user, which sounds good to me. I am curious if that is still the current "best practice"? 

Philip Arndt

unread,
Mar 15, 2015, 4:58:39 AM3/15/15
to refine...@googlegroups.com
You could handle that with roles, by assigning normal users a role like `member` and letting Refinery users have the role `refinery` that they currently have.  Users can't access the Refinery backend unless they have the `refinery` role.

Whether this is straight forward or not depends a little on whether users can sign up by themselves or whether refinery users will create them.  Either way, you should just be able to extend the system like the membership plugin did, without rolling your own devise.

lawrence...@gmail.com

unread,
Mar 15, 2015, 11:36:25 AM3/15/15
to refine...@googlegroups.com
Thank you, I am grateful for your reply. As I now understand it, the site will have 3 roles:

1.) superuser

2.) refinery

3.) member

Members will be able to sign up on their own -- the accounts are not created for them by the superuser.

I am guessing that my best strategy is to start with the membership plugin and modify from there?

https://github.com/rbriank/refinerycms_membership

However, this has not been updated in 3 years. There are 53 forks -- I am curious, are any of these regarded as canonical?

lawrence...@gmail.com

unread,
Mar 15, 2015, 4:06:16 PM3/15/15
to refine...@googlegroups.com

Thank you again for your reply. I usually work with Java or Clojure and I have not done much Ruby programming, so I am grateful for your patience. I do have one more question. If I do:

bundle exec rake routes

then I see:

                           new_signup GET    /refinery/users/register(.:format)                              refinery/users#new
                               signup POST   /refinery/users/register(.:format)                              refinery/users#create

but if I point my browser at:

0.0.0.0:3000/new_signup

or:

0.0.0.0:3000/refinery/new_signup

I get 404.

Where should I point my browser to reach these routes?

Philip Arndt

unread,
Mar 15, 2015, 4:08:44 PM3/15/15
to refine...@googlegroups.com
The route is the part in the middle, so /refinery/users/register

lawrence...@gmail.com

unread,
Mar 15, 2015, 8:44:21 PM3/15/15
to refine...@googlegroups.com

> The route is the part in the middle, so /refinery/users/register


I am sorry, I should have explained the experimentation I'd done so far. If I point my browser directly at:

http://0.0.0.0:3000/refinery/users/register

I get redirected to:

http://0.0.0.0:3000/refinery/login

I can guess a few places where I might need to change the settings to fix that, but if you could suggest a place to look, I would be grateful.

Philip Arndt

unread,
Mar 15, 2015, 9:04:20 PM3/15/15
to refine...@googlegroups.com

lawrence...@gmail.com

unread,
Mar 15, 2015, 9:44:05 PM3/15/15
to refine...@googlegroups.com
Thank you. That does make sense.

lawrence...@gmail.com

unread,
Mar 16, 2015, 10:02:19 AM3/16/15
to refine...@googlegroups.com


I am wondering if RefineryCMS can be adapted to what I need. Can you suggest if my ideas here are correct?

The client is a company that owns many karate gyms. They work with famous fighters. The site will have 2 parts:

1.) a public area where anyone can browse what content the company makes available for free

2.) an area that only paying subscribers can get to

So, one idea I have for how to handle this:

1.) a visitor goes to the site, sees public content, decides they want to be a subscriber

2.)  we first offer them a fairly standard Devise signup form

3.)  they signup, at which point a record for them is created in the Users table -- they are given a role such as "non-member"

4.)  they are shown the page for paying, which they fill out and pay

5.)  the site waits for a pingback from our payment processor, or we have a cron script that constantly checks for the status of a transaction

6.)  once the payment processor says the payment has gone through, we change the role of the user to "member"

7.)  anyone with the "member" role is allowed to see those pages where we show the videos

Am I correct in saying that I should follow this guide?

http://refinerycms.com/edge-guides/with-an-existing-rails-31-devise-app

I think I have enough custom code to write that I'm basically writing a separate site, and then trying to integrate RefineryCMS into it, yes?

lawrence...@gmail.com

unread,
Mar 16, 2015, 11:31:57 AM3/16/15
to refine...@googlegroups.com
Oh, and, when I look here:

http://refinerycms.com/blog/whats-new-in-refinery-097

I see:

"You can now assign roles to users which makes it easy to make an area of your app a 'members only section' "

Is assigning roles something that can be done by the superuser from the GUI admin, or is something that a computer programmer needs to do from the console?

Philip Arndt

unread,
Mar 16, 2015, 7:37:50 PM3/16/15
to refine...@googlegroups.com
There's a config setting in config/initializers/refinery/authentication.rb which enables it in the GUI.

config.superuser_can_assign_roles

Assumedly the programmer would have coded it up to respond to that role, as the GUI has no control over what the role *does*, they can merely toggle a user having that role.

lawrence...@gmail.com

unread,
Mar 17, 2015, 10:27:46 PM3/17/15
to refine...@googlegroups.com
Thank you again. I am looking here:

http://refinerycms.com/guides/with-an-existing-rails-31-devise-app

Perhaps I am stupid, but I am not sure what user_plugin does:

app/model/user_plugin.rb
class UserPlugin < Refinery::Core::BaseModel
  belongs_to :user
  attr_accessible :user_id, :name, :position
end

What this to that my user model does not do?

Philip Arndt

unread,
Mar 17, 2015, 10:28:46 PM3/17/15
to refine...@googlegroups.com
I'm not sure whether that's the most appropriate guide to follow if you're just using the built in implementation with the few changes we've discussed already.
Reply all
Reply to author
Forward
0 new messages