search

inossidabile / protector

Comfortable (seriously) white-list security restrictions for models on a field level
MIT License
270 stars 31 forks source link

Abandoned project? Anyone interested in collaborating on a fork? #59

Open mwalsher opened 9 years ago

mwalsher commented 9 years ago

It looks like @inossidabile has been inactive for quite some time. Are there plans to continue development of Protector?

If not, are there any maintainers that would be interested in collaborating on a fork? There are a few issues with Rails 4.1+ that I'd love to see resolved. I'd be happy to help contribute of course.

lessless commented 9 years ago

I think this a pretty important piece of software and hope anyone will pick it up

toxix commented 9 years ago

:+1:
Not sure if I can be helpful. If just done some changes to the new prepend syntax/logic. That seems more readable to me. But didn't solve the issues I had with rails 4.2 https://github.com/inossidabile/protector/issues/60 . So what are your issues with 4.2?

CyborgMaster commented 8 years ago

I don't think @inossidabile is completely inactive. His GitHub profile shows commits as recent as two days ago. However, it is true that he seems to have chosen to ignore protector (either too busy, lost interest, whatever. I can't judge; life happens). I would prefer to get @inossidabile's permission before officially forking his gem, but if that's the way things go, I wouldn't mind being involved.

We use protector extensively in production, along with its integrations with CanCan and InheritedResources. It has needed a few upgrades for our use and so I've made a few additions (see pull requests #64 #65 #66 & #67). So I guess I'm kind of already maintaining my own fork (all the pull requests are combined into a branch on my fork called cyborg-fixes).

@inossidabile, do you have any input?

inossidabile commented 8 years ago

That's true. I will unlikely support it reasonably well in any predictable future (read never). I can put the desired redirect info to the README. You don't really need permissions to do such things but thanks for asking. I'm glad it's useful to you and I'm glad there's someone to keep evolving the idea. If you need any other non-time-consuming things - feel free to ask.

My advise is that you would create an organization since there were at least few commiters that probably aren't active only because I lost my belief in OSS in its previous form. I'm confident they'd like to be involved as well. I'd also like to be a part of that organization. Not an active one but more for researching purpose (I still like the concept and I have ideas how to improve it).

CyborgMaster commented 8 years ago

@inossidabile, thanks for your input and permission. It's much appreciated.

Would anyone else like to be in charge of spearheading setting up the GitHub organization and repo? I would be happy to do it, I just haven't done it before and don't have the time at the moment. If no one else would like to, I'll probably get around to it in the next few months.

When we do get it set up, @inossidabile, it would be great if we could then get the rights to push to RubyGems as well so we can maintain the same gem name.

inossidabile commented 8 years ago

Yes, certainly.

akshah123 commented 5 years ago

@CyborgMaster I have setup an org in github called protector-ruby as protector is already taken by a user.

I can invite you to it if you want to bring the project over there.

CyborgMaster commented 5 years ago

Actually, we have gone a different direction at our company. We unified our model level permissions and field level permissions into the CanCanCan gem. It used to only provide model/action level, and we submitted a few large PR's that went into the 3.0 branch that handle field level permissions. We've found that having it all in one place has been highly beneficial and have removed protector in favor of CanCan.

If anyone would like my PR's / fixes on protector merged into a community version of the gem, I would be happy to submit them.

akshah123 commented 5 years ago

@CyborgMaster interesting. Do you know when 3.0 is expected to become GA? Also, how are you doing model level authorization there?

CyborgMaster commented 5 years ago

No, I wish I had better visibility into the release schedule, but I believe, like many community maintained project, it's a little ad-hoc.

CanCan pre 3.0 only does model / action level authorization using rules like can [:read, :update], Client. If you are asking about authorization from within each model file, then the answer is we've moved to centralized authorization rules in an Ability class, as that fit our domain better.

hidr0 commented 1 month ago

@CyborgMaster Can you please give a little inside on how you managed to pivot?

Let's say that we have a user, manager and admin. The object they should read is a Book. Which all have these read rights:

user -> name, pages manager -> name, pages, author admin -> id, name, pages, author, UUID

What we are doing with protector is:

Book.restrict(user).first.uuid and we know that we will get nil if we do not have access to that field.

We are thinking of ways to go out of protector as it is not maintained and this falls only on us. We want to understand how and why the community has moved on and nobody picked up the pieces to maintain it.