I'm using ASP.NET Membership and noticed there isn't a method in the Roles class to modify a role (its name for instance), only to create and delete them.
Is it possible or it's not supported?
EDIT: #CheGueVerra: Yes, nice workaround.
Do you know (for extra credit :) ) why it's not possible?
There is no direct way to change a role name in the Membership provider.
I would get the list of users that are in the role you want to rename, then remove them from the list, delete the role, create the role with the new name and then Add the users found earlier to the role with the new name.
public void RenameRoleAndUsers(string OldRoleName, string NewRoleName)
{
string[] users = Roles.GetUsersInRole(OldRoleName);
Roles.CreateRole(NewRoleName);
Roles.AddUsersToRole(users, NewRoleName);
Roles.RemoveUsersFromRole(users, OldRoleName);
Roles.DeleteRole(OldRoleName);
}
That will change the name of the role for all users in the role.
Follow-up: Roles, are used to ensure a user plays only his part in the system, thus User.IsInRole(ROLE_NAME), will help you enforce the BR securities that apply, for a user and the roles he is in. If you can change the role names on the fly, how are you going to validate that the user is really in that role. Well that's what I understood, when I asked about it.
rtpHarry edit: Converted pseudocode sample to compilable c# method
Renaming a Role in the ASP.NET Membership model programatically would be a Bad Thing™, because the Role names are used in the configuration file to define permissions. If there were a programmatic way to change the Role name (which persisted the change to the database), you would immediately break any Role-based security configurations in web.config for any web apps using the database, and there'd be no way to guarantee that a single web app could alter the configuration of every web app using that Membership DB.
Related
We have an issue with App registration custom role functionality within Active directory in Azure. When user is added to a custom role we need a way to somehow specify additional information that we need to send from azure to client application. Precisely in our case we have entity “restaurants" within our client application. We need to somehow inform client app from Azure that certain role can access only certain restaurant or multiple restaurants. So in a way we need to add additional information to the role-user relationship (which is many to many) and specify for which restaurant is the role added to the user.
Currently the only way for me to do this is to add a pattern in custom app role value field and to specify restaurant ID (or IDs) for each role but that means we need to add custom role for each role and restaurants. If we have 50 restaurants and 3 roles that would result us in having to make 150 custom app roles inside azure. Please let us know if this is somehow possible to be setup this relationship more elegantly.
Please let me know if further clarification is needed.
Thank you.
I have an organization role in Liferay and in this organization role are users. I want to get this users now. Furthermore I want to specify the organization name of the role.
So is there something like
xxxServiceUtil.getUsersByOrganizationRoleName(String myOrganizationRoleName);
Thank you in advance.
One principle throughout Liferay's API is: If you look for a User, then you go through UserLocalService. That's your first hint on where to look.
Since Liferay 7.0, you should not use the *Util classes any more, but just obtain a #Reference to the service directly.
Looking at the service, you'll notice that it has a getRoleUsers method. However, I can't tell you if this also takes Organization-scoped roles or only portal/instance scoped ones. In case it doesn't reveal what you like, you might need to go through getOrganizationUsers and filter on from there, or start with a DynamicQuery, which you can also find within the same service (following the principle that opened this answer)
Is there a way to combine access rights for a Sitecore item?
For example, I have a page that I would like to lock down to users who are a member of two different roles rather than just just one, and a user who has just one of the roles should be denied access.
I know you can have roles within roles but wondering if there was a simpler way to achieve this?
I'm using Sitecore 7.2.
If you are trying to check this in code, you can easily do so using
var user = AuthenticationManager.GetActiveUser();
return user.IsInRole("Role1") && user.IsInRole("Role2") ? "Granted":"Denied";
But if you are trying to achieve this in Sitecore Security on an item, then an AND of those 2 roles will be assigned. Ex: If I allow access to an item in Role1 but deny in Role2, the user with Roles 1 and 2 will have his/her access denied.
The simplest way to approach this is to define a new role with appropriate access rights and assign the relevant users to it, either manually or by script. That keeps your access rights transparent. You could code your way around the issue, but you could end up creating an admin nightmare, where it's near to impossible to see which roles and users have access to which items. E.g. what would you expect to see in the Access Viewer when looking at one of the roles, or at a user with one or both of the roles? There's a big difference between assigning access rights programmatically and evaluating them programmatically.
One way that you could achieve it via the Security Editor is by utilising Sitecore's Roles in Roles functionality.
Essentially you will want to create a New Role in the Role Manager that will contain the two roles, Role A and Role B. Select your New Role in the Role Manager and click Member Of button. In the modal click Add and select the two roles this New Role needs to contain.
In the Security Editor select the New Role and assign the read, write, create etc permissions to the required Items.
Now when users access those Items they must have Role A and Role B before given access - they will not need the New Role assigned to their account.
If you have a large number of roles to manage and combinations of those it will be very time consuming to manually create those combinations.
I would like to find out all of the user which are associated in some roles. I have seen the UserLocalService that provides the method to find the users in a particular role. But I want a method to which I can pass an array of roleIds and it shall return me the list of users in those roles.
One way is to write custom SQL, but I would like to get it done by using the API only.
Is that possible with Liferay API??
Call the API multiple times? Create a new service that does this for you so that you only have a single call to (your) API?
I know, this is probably not the answer that you expected. Note that roles in Liferay can be scoped globally (to the whole portal, called 'regular') or to an individual site or organization. Thus just giving a roleId would limit you to the global roles (as the others would require the site's or organization's groupId).
Stepping back and looking at what you want to achieve, my first guess is that you have some semantics in being associated with a specific role - kind of like... a usergroup? A role is designed to give permissions to users, while a usergroup is designed to group users. UserLocalService also has getUserGroupUsers - this also only takes a single usergroup id, but at least it's a single (global) scope by definition and not ambiguous like roles.
Is there a quick way to mark a custom entity as readable by all users via a Customizations.xml entry?
I have been successful in creating the custom entity I need, but cannot seem to make it readable by newly created users without creating a security role (with read permissions for the entity) and applying it to ALL users.
Is there a way I can ensure that everyone (even newly created users) have read access to a custom entity?
Sorry the question, but why do you need an Entity for each user that is readable by everyone?
I mean is not the same to create a record in one entity and filter it with custom views if you want to?
Users need at least one role to be able to log in, so I'd suggest to create one common role that is assigned to everyone. Then you can grant permission to read your entity in this common role.
This approach might help you also in future, when you'll have to allow access to other entities for everyone.