The W3C categorizes WAI-ARIA roles into four groups:
Abstract Roles
Widget Roles
Document Structure Roles
Landmark Roles
Can someone explain the Abstract Roles category?
It does say in the spec:
Abstract roles are the foundation upon which all other WAI-ARIA roles
are built. Content authors MUST NOT use abstract roles because they
are not implemented in the API
Essentially, they are a behind-the-scenes thing, and the useful roles (widget, document, landmark) inherit properties from the abstract roles.
If you look at the taxonomy diagram, the abstract roles are at the top of the tree, and other roles inherit from those.
Related
In my application the users are split in 2 macro categories: Customer and Backoffice, every category has a subset of role, for example MANAGER and USER for Customer type and different ones for the Backoffice type.
So a user could be a Customer with a MANAGER role or a Backoffice with, for example, a SALES role.
Every Spring + Cognito guide on web uses cognito:groups to map the Spring ROLE, but for my case I would need to nest groups which is not possible on Cognito.
I've been thinking to use 2 custom attributes ( writable only by the admin) to set the category and role of the user respectively.
My question is, is there any disadvantage to using attributes instead of the groups?
One major concern is, those custom attributes won't be available as claims in the access token. But groups are available. So If you plan to use acces_token you may have to consider that.
There are some other minor considerations that I can think of, which may or may not be related your implementation:
Maximum number of custom attributes per user pool is 50.
Once created, you can not edit the name, min/max length and mutable property of the custom attribute. Also we can not delete that.
Even though nested groups are not supported in Cognito, is it not an option to create groups like: category_role? example: Customer_ MANAGER?
Here are some user profiles like: DoctorModel, UserModel, ClinicModel.
Each has own set of fields in database.
How to add concrete model in global scope when user is authorized to be able get model fields across all application.
For exmaple if user authorized as clinic I want to get from this model field nameClinic everywhere.
Now by defaul I got UserModel form Auth::user()
IMO this is somewhat a wrong approach. You can maintain a UserModel for all types of Users and the details that might change can be held on other Models.
For example, the ClinicModel belongsTo relationship on UserModel and holds the details specific to the clinic over there.
Detail
I am developing web application in asp.net core with Identity. now in my application I have two kind of user. Customer and Partner both have different profile information and login scenario.customer can login from simple signup from web page but partner can signup from different view with different mandatory fields.
Problem
How can I design Schema.
what are the good practices in this case.
What are the drawback.
Code
This is what I have done so far
public class ApplicationUser : IdentityUser
{
public CustomerProfile CustomerProfile { get; set; }
}
Use inheritance:
public class ApplicationUser : IdentityUser {}
public class Customer : ApplicationUser
{
// Customer-specific properties
}
public class Partner : ApplicationUser
{
// Partner-specific properties
}
By default, this will be implemented via STI (single-table inheritance). That means you'll have just your standard AspNetUsers table containing columns for the properties on ApplicationUser and all derived types. A discriminator column will be added to indicate which type was actually saved, which will then be used to instantiate the right type when queried.
For the most part, this works just fine. The one downside is that properties on derived classes must be nullable. The reason is simple: it would be impossible to provide values for Customer columns while saving a Partner and vice versa. However, the properties only need be nullable at the database-level. You can still require that they be set in forms and such via a view model.
The alternative is to use TPT (table-per-type). With this approach, you'll get AspNetUsers, but also Customers and Partners tables as well. However, the tables for the derived types will have columns corresponding only to the properties specific to that type and a foreign key back to AspNetUsers. All common properties are stored there. With this, you can now enforce columns have values at the database-level, but querying users will require a join. To use TPT, you simply add the Table attribute to your class, i.e. [Table("Customers")] and [Table("Partners")], respectively.
The one important thing to keep in mind with using inheritance, though, is that you need to work with the type you actually want to be persisted. If you save an ApplicationUser instance, it will be an ApplicationUser, not a Customer or Partner. In this regard, you need to be careful with using the correct types with things like UserManager which generically reference the user type. Even if you create an instance of Customer, if you save it via an instance of UserManager<ApplicationUser>, it will upcast to ApplicationUser and that is what will be persisted. To create a new Customer, you'll need an instance of UserManager<Customer>. Likewise, for partners.
However, this also works to your benefit, as if you attempt to look up a user from an instance of UserManager<Customer> for example, you will only find them if they are in fact a Customer. In this way, it makes it trivially simple to have separate portals where only one or the other can log in, as you've indicated that you want.
My User entity implements UserInterface and therefore provides the getRoles() method. In my system a User can belong to multiple Groups. A group can have multiple roles. Thus a user's roles can be determined by collecting all groups and merging the lists of those groups' roles. The same thing is possible with FOSUserBundle.
The easiest algorithm would be:
public function getRoles()
{
$roles = $this->roles;
foreach ($this->getGroups() as $group) {
$roles = array_merge($roles, $group->getRoles());
}
return array_unique($roles);
}
I think this solution is problematic because it will scale badly. For each group a new query has to be executed, so the amount of queries depends on the amount of groups.
Usually I'd solve this by defining a single query which collects all groups of the user and joins the groups' roles. That would require calling the UserRepository (or directly building a Doctrine query) from the User entity and I believe that is a bad practice.
So how could I avoid this bad practice while maintaining the performance advantages of a single join query?
(This time it was very hard for me to find a question title that fits. I'm not sure whether there are other simililar situations but I don't think so, because usually I would provide such method in the repository itself. In this case the UserInterface requires it to be in the entity)
The easiest way to do this is to create a custom UserProvider.
see http://symfony.com/doc/current/security/custom_provider.html#create-a-user-provider for the documentations.
Inside this user provider you have to make your query to select the user from an username and add a join to the group entity, so you only have one query
This question is really made of two parts.
Using Parse, I'd like to have the following [simplified] scheme, where I have Users who are part of secret groups, and there are discussion that can appear across a few groups at one. That is Users who are part of Group A also are added to the GroupA role, and have access to discussions in Group A.
My trouble is, when I create a new discussion and tell it the groups it should appear in, how do I query for the roles and add them to the Discussion as well? I'm really fuzzy on this roles/ACLs business, even after reading extensively.
User(firstname, lastname)
Group(members, secrets)
Discussion (groups, note, comments)
Create a Role when you create a Group. Assign a pointer from the Group to the Role. Set the ACL for the Group to the Role (for write, it can be public read or whatever you want). When you add users to the Group, add them to the Role so they have access through the ACL.
For your Discussion you need to add all of the appropriate Roles from all of the Groups to the ACL list so that all of the users in all of those Roles have access.