This might be a duplicate of a question already asked but i haven't found the one that suits my condition yet.
I am developing a system where there's a user (not an admin) who is registering himself using devise. What i want is to allow this user to create different users and provide them different set of permissions (so can't be predefined permissions and hence, cant use cancan as far as i am aware). To clarify more, this is the table structure i have come up with yet. Please guide me if i am going on the wrong path here.
USER:
id,
name,
other-details
PERMISSION
id,
name, (name of the section such as gallery, report or users)
create,
edit,
view,
user_id (the user whose permissions are defined here)
Here, create, edit and view are the permissions that the user would have. If the edit is true, he'll be able to edit that particular section. I'm sorry if this is not clear. I found Johan's answer (last one) Database schema for ACL match my scenario however i am not sure if its the right way. Also, i am not sure how to implement the SET mentioned there.
Thanx in advance. Also please feel free to ask for more details if required. I'm clueless about how right this method will be.
P.S: Newbie in Rails Here.
You should use gem devise , cancancan & rolify for it.
Check here for references https://github.com/RolifyCommunity/rolify/wiki/Devise---CanCanCan---rolify-Tutorial.
You should add your all roles with permissions in the ability.rb file
Related
I have a webapp build with rails. Nothing complicated so far. Now I would like to restrict some areas for the user. I would like to implement two roles, User and Admin. Clearly the admin can do much more, like use DELETE in some of the controller methods. But there is even more. The user should be able to set some settings. For example he can set his profile to private, so only his friends can see his content. I am not sure how to build all of this with rails.
I did some research and found those two:
https://github.com/elabs/pundit
https://github.com/ledermann/rails-settings
Maybe a combination of those two would get me to the way I want the app to be?
If the app is going to be used used by real users i would go for the devise gem(https://github.com/plataformatec/devise) It allows user to create accounts, retrieve lost passwords etc. By default it allows users to edit their "profile"(rather their personal data), it should be easy to add a checkbox to toggle public/private profiles.
In conjunction with cancancan(https://github.com/CanCanCommunity/cancancan) you can assign roles to users, without having two different classes(Users and Admins for example).
VS2013, MVC5
I was reading another SO post to solve a record updating problem (I did solve it thanks to the post). But in studying the many answers and comments on this post I found one that caused me pause. link.
The comment is by Serj who comments that putting a UserID as a hidden item in the Edit form is a security flaw. I understand his post and it makes sense we wouldn't want to expose anything we don't need to.
But it made me think about my particular Edit view I was working with. I am creating Role management for my MVC5 site and I'm passing my Role ID through the Edit page. Now that Id is not an integer like many tables have, but rather a long string that I assume was done for security purposes. But it's the primary key for the record and I don't see how I can avoid not passing that Id through the Edit page.
So I thought I would ask if I'm not thinking this through clearly, or it is a risk but there's nothing I can do about it?
If I should not expose that Id, how would I edit the Role table without passing the record's Id?
So I thought I would ask if I'm not thinking this through clearly, or
it is a risk but there's nothing I can do about it?
Yes, it's a risk. Just because the id is hard to guess doesn't mean that you are safe. You should never expose such information without performing the necessary validation steps on the server.
If I should not expose that Id, how would I edit the Role table
without passing the record's Id?
You should pass the record Id, that's for sure, otherwise you will never be able to edit anything. But on the server you should verify that the currently logged-in user has the necessary permissions to modify the roles for this particular id.
I'm currently working on a RoR application where users are able to register and have a list of (lets say 20) image-formats. These image-formats have their own model. The admin of the website is able to add or remove formats. The users should be able to activate certain formats or deactivate.
I was thinking of just adding the 20 formats to the database for each user, but that wouldn't be flexible if the admin chooses to delete or add one. Their should be a more maintainable way?
Your explanation isn't very detailed. Especially I'm missing the "default" settings from the question.
First thing (easy one):
The Admin can create an entry for each format he wants to allow on the website. So there should be exactly one such entry in the table
Users can select from these formats several (up to a limit?) Why do they need to specially choose them? Can't they just use everything the admin allows? What would happen to uploaded images if the admin deletes a format?
Anyway, best would be a has_and_belongs_to_many relationship between the User and ImageFormat. Or another Model (UserImageFormat) that builds this bridge if any additional data is necessary.
For the case, that the Admin removes some formats, you can handle this in several ways. Either you add an "active" flag to the format record and then check for this each time you use the model or you actually just delete this record (in this case, make sure your associations are set with :dependent => :destroy so all the records that connect users to formats get destroyed too. (Write tests to ensure this)
Maybe you can find some gems or plugins that help with that. This article may give you some more help. Maybe some of the authentication plugins can add access control. But I think your need (user can in some way influence what he can use/access) could be too special, since most gems for this kind of work will more likely address an admin centered access control.
my first entry here.
I'm trying to add a comment system to our Posts model. However, I am not sure of the best way to go about it for a number of reasons. I'd like the comment system to be similar to that on Forrst.com but i'd rather have visitors who comment not need an account as the site is our company site not a large community.
Outline of features are:
Visitor can comment on post, entering name, email and comment.
Our team members can comment, i'd like these to be styled differently so would like the system to know it was from one of our team, they will be logged into the system when leaving a comment.
Visitors and team members can reply to a comment. The system needs to know which comment it was in reply to.
Lastly i'd like the system to know if the comment was written by the post author.
I have looked and been trying out acts_as_commentable_with_threading which seems perfect except everyone needs a user account to leave a comment, something I am trying to avoid unless anyone has other thoughts on that?
I have also implemented this myself by creating a comments model and using awesome_nested_set for the threading. Within the comments model I have a user_id which is only populated if the user is logged in (meaning they must be a team member), this seems a little messy though.
Does anyone have any thoughts on this?
Oh, and I would love each person to be notified of a reply to their comment (if pos).
Thanks in advance.
There are lot of tools available to post comments and working with ruby on rails.
http://ruby-toolbox.com/categories/rails_comments.html
also you can customize according your own requirement instead of writing a messy code.
If you do not want to integrate a third-party service like Disqus, you have Juvia The Comments and Commontator. Also you can count with opinio as alternative. but only with Rails 3 and at the moment and as notice the development seems stalled.
What would be the best way to go about giving users the ability to share a private link that enables anyone who clicks it to view a certain page/document/item that have privacy restrictions in place?
In my case:
A User creates events which are limited to certain groups of relationships in the database (namely: friends, friends of friends, etc.) I have a :before_filter in the event controller that checks the eligibility of the current logged in user to make sure that that user has permission to see the event. If they don't they get booted to the root page with an error message.
However, I want a special scenario to exist where a user can create an event with those same privacy settings and IN ADDITION, be able to share a special link with his or her friends via e-mail, facebook, etc. Those users do NOT need an account (but will need to make one in order to sign up for the event). This is important because there is also a :before_filter in the application_controller which makes sure a user is logged in.
I'm thinking there is something I could do with routing here... Right now I just have the simple /events/72 setup. Should each event have two different links: a normal one, and a "special code" version which enables them to bypass those two :before_filter?
What are people's thoughts?
I agree with David Lyod's answer (separating this concern in a different controller).
But for creating the hash I strongly recommend you salting the hash with some secret phrase.
require "digest"
Digest::SHA512.hexdigest("#{created_at}#{user_id}.mysupersonicsecretSALT")
Doing this it is not possible, without the knowlegde of the secret phrase, to calculate the hashes and test them against your system until it hits an existing one.
If you're handling sensitive data you should not be lazy.
Cheers,
Lukas
I would have a separate controller that uses a hash value to reference the event.
Something simple like the created_at + user_id hashed to create a unique reference.
You could also simply skip the check on a certain action but I would much prefer the first solution .