In drupal-8, I have logged users. Those users are grouped by different interests (right now it is not implemented, just at analysis level). For example:
User1: java, php, .net
User2: infrastructure, java
User3: java, php, bpm
I want to achieve (is it possible?) that if the content manager publishes an article referring to the "php" interest, the only users logged that should see that article published on the first page after they logged, should be User1 and User3 as they have interest in "php".
I've found that I can create drupal roles which I assume those should be "interests" in my case.
Is there an easy way to do it?
There is a module for that and it is group
Related
I need some advice on how best to implement a security mechanism in a ASP.net core application. The application users are authenticated using AD authentication. Is there a best practice for this type of implementation?
I have a list of project records. Users should only be able to retrieve a list of projects that they have permission to access. I have three user types that have different levels of access as detailed below.
Approvers – assigned to individual projects.
State approvers – Can view state-wide projects.
Global approvers – Can access all projects.
Does anyone have any suggestions on what model and logic to implement to achieve what is required?
Well, I secure pages with information "limited" to logged on users. So if they have membership in a particale role, then only those users can jump/see such pages.
However, in your case, and often?
Well, it not so much the web page the user can use, or be restricted from.
However, when a web page can be restriced based on IIS security and not your code, then that option should be used.
However, often in code, for example, we have indivdul users from a given company, and ONLY some can and are allowed to see all projects. (so some only can see their own projects, but from that company, some have rights to see + use all projects.
So, we often have code say like this:
Dim cmdSQL As New SqlCommand("dbo.GetProjects", GetCon)
cmdSQL.CommandType = CommandType.StoredProcedure
cmdSQL.Parameters.Add("#LogonID", SqlDbType.Int).Value = Membership.GetUser.ProviderUserKey
cmdSQL.Parameters.Add("Email", SqlDbType.NVarChar).Value = Membership.GetUser.Email
cmdSQL.Parameters.Add("#PortalMaster", SqlDbType.Bit).Value = IIf(Roles.IsUserInRole("PortalMaster"), 1, 0)
so, if the user is a PortalMaster, then they can get and see all projects belonging to that company. (each company that logs into teh site can have 1 or 20 employees that belong to the given company).
So, in above, the query going to pull projects by EmployeeID (their logon), and thus they can only ever see their own projects.
If you are a member of the PortalMaster group, then we pull projects based on ComapnyID.
So, while you might not be using the older secuirty provider like above? Your queries that pull projects simple have to restrict rows returned based on above.
Once those projects are returned (in a nice grid - searching options included), then they can select (click on) a project. that next page does not really care anymore, since you can't get to the project details page until you selected a project.
So, obvious you must have for a given Project who created it. And thus your ability to display their current projects will be restriced based on their logon ID or whtever you using now.
But, for state level users? Then your critera is by their logon id and their state they belong to based on that logon.
And then there is the "admin" role or group - they can search and pull on all projects.
So, while we do restrict web pages by "role" security (based on IIS), that just means that all users can, or cannot hit some web pages based on their role memember ship (and such security does not require code on my part - the IIS secuirty assinged to those web pages can do all that dirty work for you.
However, if you are a legal logon, then you can only ever work on projects that belong to your company. But then it is a question if that user also has the role of "PortalMaster", and if they do, then we pull all projects for display to select from for that given user.
And of course we never use say URL "query parameters", and such internal database company ID, or ContactID (user id) are never exposed, nor possible allow display of information or data that don't belong to the given user.
So, you need to build some sql or some store procedures, and having a few "parameters" for those stored procedures that returns rows of data based on their role membership is quite much how you would approach this. So in above, if the user is a portal master, then the stored procedure simple queries the data based on company they belong to as opposed to their contact id.
Now, this of course asseumes the database schema is setup, and for example, we hvae a company table, a employee table (that has their logon information), and then of course each project created has both a created by, and the company the project belongs to. So, that simple information is enough to provide the 2 levels of security.
We actually don't have a "super user" that can look at and see all projects in the system, but it actually not all that bad of a idea, since for testing, or checking a project that has some problem is a "pain" right now, since we in theory have to create a logon for that company, or get a password.
So, all logons we create belong to a given company. And thus when a user creates a new project, it can only be created under that one company, and of course a project also requires the user that created the project.
So, you simple have to restrict records returned in the page in which they can select a project to work on. IIS security, or in fact SQL server security as a general rule can't do this type of security for you - you the developer have to.
I'm looking to move my json file to an database service. I've been looking at Firebase-- Firestore in particular.
What the website is, is a collection of recipes.
Users can search for recipes by category. Or they can search by typing in ingredient.
I dont need to have users signing up and logging in.
Its not overly clear to me:
If this service can be used as a 'read only' database to populate the website with what the user selects.
If the database can be secure yet not have users sign up and log in.
Can anyone direct me to documentation/tutorial on the "how to" to have the data itself secured, but available for read only and without needing users to create log-ins.
Thank you,
Lee
Yes
Yes
You need to look into security rules to make sure your public read-only data is actually read only: Just allow read: if true for each collection that you want to give access.
This is my first attempt, trying to integrate Membership on an existing shop already in production.
I'm not quite sure, based on my scenario, if I should use the build-in aspnet-providers or custom implementations of them in order to integrate membership.
Here's a few details:
I have a multi-tenant, single database, single schema web app based on subdomain.
The app is already in production and I will later want to link newly registered users with existing anonymous orders by email.
The development will continue after the membership integration, new features will be added, meaning new columns and linked tables for the users table.
This answer got my thinking of using the membership deafult Profile in order to extend the users table created by the aspnet providers, since I don't have users yet. Though its not clear to me how I would link Users with Orders and other tables/entities that might later be added when the app is going to be extended.
Maybe I could define my entities related to users as user-defined profile properties but they would not have associations on my database.
Another overhead I'm thinking of is how would I associate the users with the different tenants of the app. I would want users to be able to regiter in different tenants/subdomains with the same email.
How would you implement membership in this scenario?
This question is an aggregate of a few questions. I will try to answer them to he best of my knowledge
In case of managing users, i would like to suggest that you consider the following approach
Pre-define a list of basic user profile metadata that you will need in the application
Create an extensible approach like having custom fields for the user profile so that it can accommodate any data that may be required to capture in future
You should also be planning for a self-registration system in the application that will allow your user's to register themselves like the anonymuous ones that use the system with an email
Regarding associating the business entities, you will require to associate the entities with the tenant and not with the user. the level of application will be from the tenant and then it will flow down to the users.
Additionally, you should not have the user accessible business entities, when they are maintained in a form of package or so, it will be very easy to manage and use.
Share your thoughts on these approaches.
- Create a tenant identifier column [property] for each profile that identifies the base tenant to which the user belongs to
- create a table that manages the list of other tenant's that the user may be gaining access to at a later part
I got a requirement from client that he wants to know distinct users information from sites and it sub sites those have access to site. There are separate groups for each subsite (contribute, approval and full access). From these all groups find distinct user information.
How can we do that using Object model? Please help me out.
Thanks in advance.
SharePoint 2010 - I use this PowerShell script quite often when someone asks who has permissions to a site. This wont include users given permissions directly, or site collection admins, but it's still helpful.
You must be on the SP2010 server to run this.
#Get a list of groups in a site, then a list of people in each group
Add-PSSnapIn Microsoft.SharePoint.PowerShell
$spWeb = "http://sharepoint/site/"
foreach($group in ((Get-SPWeb $spWeb).Groups)){
foreach($user in $Group.Users)
{$group.Name + " - " + $user.Name
}
}
This is one of those very general requirements that gets very difficult very quickly. It sounds like they are trying to create some sort of security audit.
If you assume each site only has SharePoint groups filled with SharePoint users and everything is inheriting permissions, then it is a little easier. You could recursively iterate over each SPWeb (and the sub-SPWeb's in each SPWeb) to find all the SPGroups. Then, using a Dictionary, you would keep track of the users you find and their permission level. Their permission level is determined by their membership in the group and you'd probably use web.RoleAssignments.GetAssignmentByPrincipal(group) (GetAssignmentByPrincipal) to get the list of assignments (Ex: Read, Contribute, etc).
However, the scenario is probably NOT what your client has. Things to think about (some easier to overcome than others):
What happens when a user exists in multiple groups in the same site?
Users with individual permissions to a site?
Broken permission inheritance at a SPWeb level? What about list permissions? Item permissions? What happens when you see Limited Access?
Are AD groups used anywhere? Do you have to list all the users in each AD group? What about special groups like "ALL AUTHENTICATED USERS"?
Realistically, it is very difficult to write an accurate security audit. The best solution for this is probably to find someone who is familiar with how security should be set up going through each site to fix them.
A project I'm working on supposed to authenticate users agains AD. I've never worked with AD before, neither did I work in organizations that use AD, so here's my stupid question: in case if AD involved, who manages roles, groups and users for application? Is it my responsibility to provide an UI for site admin to assign AD users to my app roles or AD admins should take care of creating appropriate groups expected by my app and assign existing AD users there?
What are the best practices in this department?
Once thing to note -- this is not an in-house app, so it is supposed to work with an existing AD. The question is if my expects roles like "Teachers" and "Students" (just to illustrate the point), may I expect that IT people will create appropriate groups in AD and assign users to them?
I don't think you should supply a Gui for active directory. Most organization that use active directory manage it with the standard active directory tools.
If you want to handle the case of small shops. Then make the groups internal to the application DB. You will still be able to use the active directory users. But the group management and membership will be internal to your application. This will avoid most problem of dealing with the complex rules of active directory, and still benefit from single sign on.
One more thing to note. The group names should be customizable. Most places have naming convention for group names.
If you're writing this app for another company, I think you could assume they'll be in charge of managing the AD users and groups. You'll just need to coordinate with the clients on what roles/groups your app will use.
This really depends on who owns the AD, and who is going to be responsible for managing user accounts. If this AD is isolated from your coporate domain, and you want your support or sales, or other business person to manage the accounts then by all means create them an admin tool.
If your trying to tie into your existing AD, then you should work closely with your IT department, they will probally want to create the accounts their own way (especially if your using your existing credentials).
Essentially this boils down to how your IT operates, and what exactly the relationship btw the AD your using and the AD which runs the coporate site.
Edited
Based on your additional info, I think you need to offer an admin concsole. Especially if you want to target the smaller shops out there. Your solution should make it optional so if they want to use the admin UI they can but if the IT department wants to use Powershell for example they can do that as well.