entrecode / shiro-trie Goto Github PK

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

The typings provided do not compile in strict mode, the definition of the constructor does not define a return type:

index.d.ts(14,5): error TS7010: 'constructor', which lacks return-type annotation, implicitly has an 'any' return type.

Hi,
Wonderful library for permission management.

Can we store this data onto a database?

Seems to be a major bug in the way that Shiro-Trie is handling wildcards in the middle of the permission.
Per Apache Shiro design, something like:
printer:*:lp7200 is a valid permission.

See doc mentioning wildcard here:
https://shiro.apache.org/permissions.html

However, according to the documentation, this does NOT mean that the user has ALL on ALL, as for example "printer:*:*" It simply means that the user has all of the middle layer on the printer lp7200. Assume that the middle layer is action, as with most implementations, it's not valid to assume that "printer:*:lp7200" is equivalent to "printer:*:*" aka all actions on all printers. It simply means that the user has all actions on the lp7200 printer.

In our case, the wildcard permission looks like, "events:*:123"

However when Shiro-Trie checks permissions based on something like "events:view:?", it returns "*" incorrectly.

This code, however:

function _permissions(trie, array) {
  var current, results;
  if (!trie || !array ||
    typeof trie !== 'object' || !Array.isArray(array) ||
    Object.keys(trie).length < 1 || array.length < 1) {
    // for recursion safety, we make sure we have really valid values
    return [];
  }
  array = [].concat(array);
  // if we have a star permission, we can just return that
  if (trie.hasOwnProperty('*')) {
    return ['*'];    // <<--- THIS IS THE ERRANT CODE
  }
...

is causing the permission check to be short-circuited as soon as it encounters the first "*" wildcard in a permission having matched so far. In our case, as soon as it sees "events:*" in the permission "events:*:123" it returns "*" when we're checking for "events:view:?", thereby telling the calling code that the user has view rights on ALL events, which is incorrect. This seems very contrary to the Shrio Java implementations, where an "events:*:123" explicitly means that a user has all rights on event 123, but does not have all rights on any other event.

To be clear, what we're trying to do here is get all the permissions the users has that match events:view:? which should IMHO return 123 when the user has permission events:*:123 but instead is returning *

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.

Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.

If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.

We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

Once you have installed CI on this repository, you’ll need to re-trigger Greenkeeper’s initial Pull Request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper integration’s white list on Github. You'll find this list on your repo or organiszation’s settings page, under Installed GitHub Apps.

Hi,

Depending on the order of adding permissions to the tree, the tree may not be correctly constructed. As a result, some checks may fail while they should succeed.

This works as expected:

var shiroTrie = require('shiro-trie');

var account1 = shiroTrie.newTrie();

account1.add([
  'domain:*',
  '*:*:read',
]);

account1.check('domain:resource:create'); // true

But this fails:

var shiroTrie = require('shiro-trie');

var account1 = shiroTrie.newTrie();

account1.add([
  '*:*:read',
  'domain:*', // domain does not get a * leaf
]); 

account1.check('domain:resource:create'); // false