which is the right syntax for adding several users to same topic restriction?
for example:
user user1
topic topic1/#
user user2
topic topic1/#
or
user user1
user user2
topic topic1/#
?
The first option.
You need to list the topics for each user, if you have lots of users it may be easier to use a plugin to load the ACL from a database, or generate the ACL response based on a set of rules.
Related
I have done some digging but am unable to find out specific information about the Users table that is created in the ReportServer database?
Firstly I wanted to check what was the point of entry for users going into this table? In our table it looks like virtually ALL our domain logins exist in this table... Which leads me to the next question... Are these actually linked to the domain accounts at all (I presume not). I just want to make sure that if a domain account is disabled that any subscriptions 'Owned' by that user will not fail on the next run attempt.
Any help on this relatively dark area is greatly appreciated.
Regards
Chris
Before answering let me remind you that the SSRS database is not officially documented, so the following answers are only be based on my experience of the product so they can be wrong / incomplete.
what was the point of entry for users going into this table?
The GetUserIDBySid and GetUserIDByName stored procedures, called by the GetUserID stored procedure.
The GetPrincipalID stored procedure, called by the UpdatePolicyPrincipal stored procedure.
The name can be confusing, because in fact these SPs are not only getting the User ID.
If the user does not exist in the database, they insert it.
Now an additional question should come up:
When are these SPs executed?
The obvious answer is "when SSRS needs to get the User ID".
This can be, for example, when:
Creating a policy for that specific user
The user execute a report
The user schedules a subscription
If the user is part of a group that has access to a report and has never done any action needing to get his User ID, he should not be present in the Users table.
Are these actually linked to the domain accounts at all
No, if you delete the account from your AD it will stay in the Users table.
The information that you can use if you need to link them for whatever reason are:
The User Login: UserName
The Security ID: Sid
Bonus question/answer:
What information does the Users table contains?
UserID: A generated GUID (NEWID())
Sid: The Security ID, if you need to find the Security ID from the User Login, you can use the SUSER_SID function
UserType: The UserType
AuthType: The LoginType
UserName: The NT User / Group login
Here is an excerpt from an article:
Users: This table contains details about access details for users of the report server including those users running the reports and those users publishing the reports.
SSRS keeps its own table of users and groups associated with its security, so even if the user account has been deleted from your Active Directory system, it will be available for you to reference inside the ReportServer database
This query below will show you to which report each user has access to:
SELECT u.UserName, r.RoleName, c.Path, c.Name
FROM dbo.Users as u
INNER JOIN dbo.PolicyUserRole as pr ON u.UserID=pr.UserID
INNER JOIN dbo.Roles as r on pr.RoleID = r.RoleID
INNER JOIN dbo.Catalog as c on pr.PolicyID = c.PolicyID
ORDER BY u.UserName
I have seen a few implementation of Row-Level ACL using a Permission table having a structure such as
User_Id
Subject_Class
Subject_Id
Permission_Id
where Permission_Id is (Read, Write, Update, Delete, Approve, etc.)
I was wondering if there is any benefit to describe a relationship (Relationship_Id) with the data instead of describing a permission.
The idea we would to describe that a user is an "Owner", "Approver", "Reviewer", "Public Viewer", etc.
This relationship would then define a set of permissions. This could reduce the size of the Permission.
Any thoughts on this methodology?
Roles, as you note, are combinations of permissions. If you have a permission set of size n, you can have 2^n combinations of all of these permissions. This means that if you have 5 permissions, you'd need 32 roles. If you have 10 permissions, you'd have 1024 roles!
Using the permission route also appears to be easier for maintainability - say that you want to remove access permissions from a group of users. You'd just do a simple query to remove the rows that give access privileges to those users. But if you had roles, you'd first need to find all the roles that include access, remove those from the specific users, and then find all the roles that are like the previous role of each user minus the access permission, and assign those roles to the users. Seems like a lot of work.
I am creating site and there are 3 roles on it. Administrator, Teacher, Parent. User with any role has access to site, but 1 role has full access, teachers can only put marks for students, parents can only watch these marks.
I understand how to separate roles into scripts. Just save some parameter depending on what database would return when I check login and password.
So! Administrator has only login name and username. Also it is possible to store information about how to contact the user to make system more user-friendly. That's all.
Teacher has firstname, lastname, midname (father's name), address, phone etc. And it must have login and password fields...
Parent has Firstname, Lastname, Midname only. And sure somewhere I should to store data about login and password.
So should I just check this tables 1 by 1 and depending on table I will find $login and $password I inputted in I will return role? I don't think it is a nice idea. Suggest something else please.
What I think to do. I think that it would be not very bad idea if I will create 1 more table like users where I will store: id, username, login, role, user_id (need to think about it). The problem is user_id. How exactly this table will be connected to others? For example user_id` would be 1. 101% there would be 1 row with such id.
I want to ask about exprience of your self-build systems. May you suggest something please!
You're right. It doesn't make sense to have different tables for users. I would recommend you to store authorization and personal data in separate tables. And of course you'll need additional table for roles:
The idea behind this scheme is to keep thin users table for fast authorization. If authorization was successful, than you should check permissions from roles or get personal data from user_data tables.
Look at this sql-fiddle for DDL.
I have been working on a Social Network to further my knowledge with PHP, however I have come to the point where I will be pulling posts from he database depending on who the user is "friends" with.
My database structure for friends is as follows:
USER_A | USER_B | CREATED_AT | IS_BLOCKED
And then for the posts:
USER | UPDATE | STATUS
So, I want to show posts selected from my post table if the user logged in is friends with the user who posted it.
So, basically, wondering if anyone has any suggestions. It won't be anymore complicated than that, not interested in getting friends of friends or anything like that. So, just wondering if someone could point me in the right direction with this one.
I read it would require JOINs and such, however I have never really stepped into that side of SQL so therefore would have no idea what I would be doing with it, so links to relevant questions and articles on that, if required, would be appreciated.
Thanks
(I am essentially looking for help with the SQL statement, not with the PHP.)
Update #1:
I have got the newsfeed working, now I need to be able to join a statement to get the users names to be displayed. My current status is on this: http://sqlfiddle.com/#!2/b07793/1/0
Before anyone goes crazy about storing passwords in plaintext, this is not a public system, it is purely for me to test, and hashing passwords for a non-public script that will only ever be used by me with fake passwords is hardly a security risk, it just makes debugging a pain.
Something like this should work :
SELECT * FROM posts
JOIN friends ON posts.user = friends.user_b
WHERE user_a = 'someuser'
In this statement we are JOINING to tables : posts and friends, based on the value of two column, we are putting in relation the column user of the post table with the column user_b of the friends table, in this way we will obtain a result set with only the value of the two table where the two columns in relation are equal ...
If I understood correctly the db schema you described, this will bring you all posts that have been written by a user that is friends with the logged in user.
SELECT * FROM posts WHERE posts.user IN (SELECT user_b FROM friendships WHERE user_a=$logged_in_user)
The query is pretty simple. You get all the rows from table posts that the creator of that post has a line in your friendships table as user_b while user_a is set to be the logged in user.
I'm assuming a few things, if they're not correct you'll have to modify this stuff but if I'm right, these operations won't need any JOINs:
$userSession variable contains the user who's logged in's ID.
$userToView variable contains the user who he's trying to view's ID.
Your database structure will only have one entry for the two users who are friends, so we have to check both combinations.
To determine if the user is a friend:
SELECT user_a, user_b FROM friends
WHERE (user_a = $userSession AND user_b = $userToView)
OR (user_a = $userToView AND user_b = $userSession)
LIMIT 1;
Then you'd use an if statement in PHP (it's usually better to keep business logic in the application, rather than in the database), if it's true return the posts.
$results = $mysqli->query($query)->fetch_row();
if($results) {
... return posts ...
} else {
echo 'Not friends';
}
That would be a query something like this:
SELECT * FROM posts
WHERE user = $userToView;
You will need to read up about mysqli (do not use mysql plugin, it's deprecated) and about SQL injection attacks and how to prevent them. It may sound like a hassle, but it's far less daunting to understand this stuff than to deal with the fallout if you don't.
I am working on one portal where will be few user roles. I have been wondering what is the best way to handle them. I have created separated tables for users and clients, but clients will want the functionality as users and users can become clients easy too.
I also don't want to make many joints, so what I as thinking is this:
I will have 4 different user roles (at least for now) as follow:
user
client
reviewer
admin
I will assing "id" to each role. At the same time I will keep table in mysql with these roles. It will be something like:
1 - admin
2 - reviewer
3 - client
4 - user
This table will be used only upon creation of user, to get the code of user "permissions". So Let's say that there will be a guy who is a user and reviewer. His role would be 24.
login password email role created
----------------------------------------------------------
guy password guy#gmail.com 24 2012-12-08 23:12:30
I think this could work pretty well, but still want to ask if you guys think this is good and effective solution.
Thanks
The other way to do this would be to have a many to many USER_ROLE table where for your example guy would have the following entires.
login role
guy 2
guy 4
I generally prefer this method of tracking roles. A join against this table in a situation like this should be fast and painless, especially if you move to using a user_id instead of a login, and index appropriately.
What you're defining is a Role Based Access Control System (I would suggest looking up resources on this). An RBAC system will have a separate table for users and another table for roles. There will be a many to many relationship between users and roles. Also, you will connect a permissions table to roles in another many to many relationship. The image attached represents how to implement this system:RBAC SYSTEM IN MYSQL
A similar question was asked before: How to design a hierarchical role based access control system