Simple authorization solution for Rails which is decoupled from user roles. All permissions are stored in a single location.

Simple authorization solution for Rails. All permissions are stored in a single location.

YamlDb is a database-independent format for dumping and restoring data. It complements the database-independent schema format found in db/schema.rb. The data is saved into db/data.yml. This can be used as a replacement for mysqldump or pg_dump, but only for the databases typically used by Rails apps. Users, permissions, schemas, triggers, and other advanced database features are not supported - by design. Any database that has an ActiveRecord adapter should work.

GitLab fork. YamlDb is a database-independent format for dumping and restoring data. It complements the the database-independent schema format found in db/schema.rb. The data is saved into db/data.yml. This can be used as a replacement for mysqldump or pg_dump, but only for the databases typically used by Rails apps. Users, permissions, schemas, triggers, and other advanced database features are not supported - by design. Any database that has an ActiveRecord adapter should work

Dynamically defines roles and grants it permissions

Define your permission rules as role- or role group specific permits. Integrates well with multiple Devise user acounts. Includes rules caching. Store permissions in yaml file or key-value store

Define your permission rules as role- or role group specific permits. Integrates well with multiple Devise user acounts. Includes rules caching. Store permissions in yaml file or key-value store

A Vagrant plugin to automate bindfs mount in the VM. Allows you to change owner, group and permissions on files and work around NFS share permissions issues.

Use LDAP permissions in PostgreSQL

File permissions management for Capistrano 3.x

This gem is designed to provide a Ruby interface to the gitolite git backend system. This gem aims to provide all management functionality that is available via the gitolite-admin repository (like SSH keys, repository permissions, etc)

Easy and modular way to secure applications and handle permissions.

Aegis is a role-based permission system, where all users are given a role. It is possible to define detailed and complex permissions for each role very easily.

Aegis is a role-based permission system, where all users are given a role. It is possible to define detailed and complex permissions for each role very easily.

Simple permissions that I have used on my last several projects so I figured it was time to abstract and wrap up into something more easily reusable.

decko permissions

Admin Web UI to manage permissions - Who can do What on Which objects

Authzed is the best way to build robust and scalable permissions systems. See https://authzed.com for more details.

Admin/role subsystem for releaf

= DESCRIPTION: Provides a Chef handler which can report run status, including any changes that were made, to a Graylog2 server. In the case of failed runs a backtrace will be included in the details reported. = REQUIREMENTS: * A Graylog2 server running somewhere. = USAGE: This example makes of the chef_handler cookbook, place some thing like this in cookbooks/chef_handler/recipes/gelf.rb and add it to your run list. It also assumes your Graylog2 server has set the attribute rsyslog_server to true. log_server = search(:node, "rsyslog_server:true").first if log_server include_recipe "chef_handler::default" gem_package "chef-gelf" do action :nothing end.run_action(:install) # Make sure the newly installed Gem is loaded. Gem.clear_paths require 'chef/gelf' chef_handler "Chef::GELF::Handler" do source "chef/gelf" arguments({ :server => log_server['fqdn'] }) supports :exception => true, :report => true end.run_action(:enable) end Arguments take the form of an options hash, with the following options: * :server - The server to send messages to. * :port (12201) - The port to send on. * :facility (chef-client) - The facility to report under. * :host (node.fqdn) - The host to report messages as coming from. * :blacklist ({}) - A hash of cookbooks, resources and actions to ignore in the change list. = BLACKLISTING: Some resources report themselves as having updated on every run even if nothing changed, or are just things you don't care about. To reduce the amount of noise in your logs these can be ignored by providing a blacklist. In this example we don't want to be told about the GELF handler being activated: chef_handler "Chef::GELF::Handler" do source "chef/gelf" arguments({ :server => log_server['fqdn'], :blacklist => { "chef_handler" => { "chef_handler" => [ "nothing", "enable" ] } } }) supports :exception => true, :report => true end.run_action(:enable) = LICENSE and AUTHOR: Author:: Jon Wood (<jon@blankpad.net>) Copyright:: 2011, Blank Pad Development Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.