How do I setup basic user permissions so users can't run commands like "Hubot die" or "Hubot show storage"?
I can see there is a script called hubot-auth but that seems to be for implementing it in other scripts and not controlling existing commands.
There is a small chapter about it in Automation and Monitoring with Hubot book (shameless plug). Excerpt:
Assigning Roles
Only Admin users can assign roles. You don't have to create a role before assigning. All you have
to do is tell Hubot who is who using hubot <user> has <role> role. And you no longer have to use
those cryptic IDs anymore:
Tomas hubot Jesse Pinkman has developer role
Hubot Tomas: Ok, Jesse Pinkman has the 'developer' role.
Check the assigned roles using hubot what roles does <user> have?:
Tomas hubot what roles does Jesse Pinkman have?
Hubot Tomas: Jesse Pinkman has the following roles: developer.
To remove the role from somebody, use hubot <user> does not have <role> role:
Tomas hubot Jesse Pinkman does not have developer role
Hubot Tomas: Ok, Jesse Pinkman doesn't have the 'developer' role.
You can assign multiple roles to multiple users.
Applying Roles
Now, time to break the bad news. While Hubot Auth is pretty flexible, you will have to edit your
scripts to apply those roles. Luckily, there is not much to edit. There is a simple function that
checks if user has a role - robot.Auth.hasRole(msg.envelope.user, '<role>').
This is how you use it in a script:
module.exports = (robot) ->
robot.respond /do dangerous stuff/i, (msg) ->
if robot.auth.hasRole(msg.envelope.user, 'developer')
doDangerousStuff(msg)
else
msg.reply "Sorry, you don't have 'developer' role"
doDangerousStuff = (msg) ->
msg.send "Doing dangerous stuff"
As stated in the original answer, you have to be a Hubot admin in order to assign roles. To define the Hubot admins, you have to set the HUBOT_AUTH_ADMIN environment variable to a comma-delimited string of IDs of the admins. If you're using Slack, you can use their API to figure the IDs of the users that should be admins. For Slack these IDs will look something like U123ABC1D.
I can see that hubot die is defined in the ping.coffee script. Maybe you can have a check there on authorized users when the command is run?
Something like this?
if msg.message.user.name in [authorized_user1, authorized_user2,..]
# Do more stuff
The same can be done for the other show storage script too. I am not really sure if this is the best way to go about it though as you will have to modify all the scripts that you do not want to be executed.
A cleaner approach would be to set the list of users as a env variable at startup(kind of like what hubot-auth does) and then check it inside each script instead of hard coding user names.
Hope that helps.
Related
First, thanks Hasura for incredible good product! I love it.
I have issue with derive action with Hasura Console. My use case:
I enable anonymous role for subscribe function (everybody can send email to subscribe)
I have configured permission on my subscribe table, everything is fine.
I want to validate the user input on server side, for example, validate email format. I have followed by this guide about derive action. I found no mistake here.
But I got the error "Type query_root must define one or more fields." when I hit "Derive action" at the first time.
According to this question, as I understand, I need to have object type for root query.
Of course, I will have object type for root query eventually. I can work around by giving some dummy queries for anonymous role. But I do not like that cheat anyway.
Any idea on that? Any help will be highly appreciated.
Edited:
My related current version:
Hasura 1.3.2
One click deployment using Docker on Digital Ocean.
I want to clean all the identities and their accounts roles etc associated with identities.
Is there any way to bulk delete identities?
Do you have shell access?
You can use the iiq console for this:
bash /path/to/iiq/WEB-INF/bin/iiq console
> delete Identity *
This should get rid of all identities except for the ones which are tagged as protected. Also all additional data (links, assignedRoles, scorecards,..) will be deleted.
I'm quite confused about the ACL in symfony/silex and how I can make them work for me.
I've been thinking about a solution based on modules -> actions. However, reading about ACL, everything seems to be based on roles, which is to broad for the implementation I'm trying to achieve.
I will have users, and all users do belong to a role (admins, users, etc...). However, the role is more of a guideline of what you can do (as it sets the default permissions a user with that role starts with) that an actual set of actions a user can perform. The actions, are really based on the modules the system has and the permissions that are actually granted to any of the users to read, add, update of delete and any other verb outside of those.
So for example:
ROLE #1: Is an Admin
can read users
can post users
can put users
can delete users
ROLE #2: Admin
can read users
can post users
cannot put users
cannot delete users
Since I'm planning to have several diferente modules (users, payments, products, etc..), and each admin can have privileges granted or revoked, they will not fit the ROLE_ADMIN, ROLE_SUPER_ADMIN, ROLE_USER type of roles.
I was thinking something on the lines of ROLE_VIEW_USERS, ROLE_ADD_USERS, ROLE_EDIT_USERS and that a User will probably have 100 of those little roles and have voters for each controller that will decide if you can perform certain action.
Does this make sense?
You are confusing ACL and roles. They both have to do with permissions but they approach and function differently from one another.
Roles aren't inherently tied to a specific resource. On the other hand, ACL is, and that link is persisted. Users can be tied to resources (or appear to be so) through the use of voters.
https://symfony.com/doc/current/security/voters.html#creating-the-custom-voter
User-specific ACL, e.g. where a user has specific access defined PER resource, you'll need quite a bit more stuff.
Take a look at the SF cookbook:
https://symfony.com/doc/current/cookbook/security/acl.html
https://symfony.com/doc/current/cookbook/security/acl_advanced.html
OWNER/MASTER/OPERATOR CAN
Edit
View
Delete
Create
ALL RESOURCES (This is done using ROLES)
ROLE_USER CAN
EDIT OWN
VIEW OWN
DELETE OWN
CREATE
OWN RESOURCES (This part is done with ACL or voter)
Voters are effectively creating your own ACL and therefore there is no persistent permission unless you make one explicitly (At this point I would go ACL). The use case for ACL is basically the same as the use case for a voter, and choosing one vs the other is a matter of complexity.
The built in ACL info is coming from the database, but as per SF documentation: "It can contain tens of millions [of records] without significantly impacting performance."
Extremely simple? Could use a voter.
If you don't want to maintain your own rules (voters) for resources and don't mind the complexity of the ACL, or like that permissions are persisted + cached, you could use ACL instead.
Note that the complexity of the ACL is generally the following when creating resources (although this could be put in a service):
$aclProvider = $this->get('security.acl.provider');
$objectIdentity = ObjectIdentity::fromDomainObject($resource);
$acl = $aclProvider->createAcl($objectIdentity);
$tokenStorage = $this->get('security.token_storage');
$user = $tokenStorage->getToken()->getUser();
$securityIdentity = UserSecurityIdentity::fromAccount($user);
$acl->insertObjectAce($securityIdentity, MaskBuilder::MASK_OWNER);
$aclProvider->updateAcl($acl);
For the previous scenario, you can use the ROLE_USER to make sure that the authenticated user is actually an actual user and not AUTHENTICATED_ANONYMOUSLY and the voter or ACL to make sure they can only edit their own resource, and override this if their ROLE is ROLE_ADMIN. (Assuming users are given ROLE_USER once they sign up)
Example in security.yml
# This could be done via #Secure(roles="ROLE_USER")
access_control:
- { path: ^/my/api/endpoint, role: IS_USER, requires_channel: https }
- { path: ^/my/admin/api/endpoint, role: IS_ADMIN, requires_channel: https }
Example in controller::action
// check for edit access
if (
false === $authorizationChecker->isGranted('EDIT', $resource) &&
false === $this->get('security.context')->isGranted('ROLE_ADMIN')
) {
throw new AccessDeniedException();
}
Here is another QA in StackOverflow that also provides some examples:
Symfony 2 ACL and Role Hierarchy
You can also use annotations for this stuff:
https://symfony.com/doc/current/best_practices/security.html#authorization-i-e-denying-access (It shows how one works vs the other).
Let me know if any part of this requires further explanation.
Thank you.
I have "You do not have sufficient permissions to access this page." issue when trying to access Wordpress wp-admin login as an administrator. The login page appears, but when the user details are entered the "You do not have sufficient permissions to access this page." appears.
The strange part is that I have another administrator account that accesses with no error.
I tried to create a new administrator account, but that also cannot access giving the above error message.
I have looked into the database and the users that don't work have wp_capabilities of a:1:{s:13:"administrator";b:1;}
The user that does work has: a:2:{s:13:"administrator";b:1;s:13:"bbp_keymaster";b:1;}
I am also running S2 Member plugin.
The only difference I can see between the account is this beginning section of a:1 and a:2. All of the sites I see say the account should be a:1
I don't think it is a plugin issue, as I assume then I would not be able to access either. I think perhaps something to do with s" Member plugin, but I'm now at a bi of a loss.
All plugins are updated and running Wordpress 4.0 (however this was an issue even before upgrade to 4.0)
All help gratefully received!
The only difference I can see between the account is this beginning section of a:1 and a:2.
Look more carefully. The working example has a whole extra section: s:13:"bbp_keymaster";b:1;
To understand why that matters, it helps to know that that is the format produced by by PHP's serialize() function.
If you unserialize each of those strings, you will find that the first is an array with 1 entry (hence a:1), with the key 'administrator' and a value of true. The longer string is an array with that entry plus another one, with the key 'bbp_keymaster', also set to true.
From this, it's easy to surmise that 'administrator' and 'bbp_keymaster' are the internal names for permissions which can be granted to a user, and the page in question is only available to users with the 'bbp_keymaster' permission.
I am trying to do some development to the LogisticsPostalAddress form that is used on forms where an address is modified/added. When trying to add an address (e.g. to an existing Customer) I get the error.
You are not authorized to access table ‘Shipping carrier’ (ShipCarrierAddress). Contact your system administrator.
I have scoured the user permissions and cannot find a way to give permission to this table. I would think that adding an address is a basic function, so can not figure out why I can't.
Thanks,
Kevin
What role is your user assign to? Are you sure users in that role should be able to add addresses to the customer? If yes, here is how you can add permissions to the ShipCarrierAddress table:
With admin user, open development envionrment (Ctrl + Shift + W from
running Ax, or run "ax32.exe -development" from command prompt)
In the AOT, go to Security > Roles. Find the role your user is assigned to.
Exapand the Role > Permissions > Table, add new table and set table name to ShipCarrierAddress and EffectiveAccess (in your case
you want to insert, thus set to Create)
Save the role, and compile the role (not sure if compile is mandatory)
Start a new Ax instance with the user with limited permissions and verify you have access.
I turned out it was an issue with the installation of the lab.