Is there any way to get the user (not the role) that created a view?
I tried desc, show, grants on view but couldn't get the specific user
The INFORMATION_SCHEMA.QUERY_HISTORY* table-functions have a USER_NAME column, and you can filter on the QUERY_TEXT to find the view's CREATE-statement.
This should work unless the views were created with a variable. For example: CREATE OR REPLACE VIEW IDENTIIER($MY_VAR)... where MY_VAR is a variable containing the name of the view.
UPDATE
INFORMATION_SCHEMA.QUERY_HISTORY table-functions return results for the past 7 days. Also see the ACCOUNT_USAGE.QUERY_HISTORY table functions, which return results for the past 365 days, with a 45 minute lag.
UPDATE 2
You can also use conventions such as:
Give each user their own schema, composed from their name or initials
Ask users to put their name or initials in the view COMMENT
Or ask users to prefix or suffix their views with their initials
If the views are created with a script or a stored procedure, then you can automate the above.
Lastly, while it's not a best practice, you can in fact create a separate role for each user. This however creates a lot of administrative overhead, especially as you scale, and is not recommended.
Related
I'm discovering the Repository Pattern for my Laravel project but I have to say that I'm a bit lost once a model has several dependencies and the examples on the web are always basic and don't answer the question for more complex use cases.
Let's imagine a user on my app. He can have badges, he has different things on the app that will be slightly modified when he first performs the action (when he first sees the comments, I tell him once the different things he can do, etc), he has several "counters" to record the number of comments he made, the number of friends he invited, without having to count each entry each time.
My database looks like this:
users table:
id
pseudo
name
password
...
badges table:
user_id
badge1_xxxxxx
badge2_xxxxxx
...
I have a very limited number of badges so I decided to create a column for each of them and as soon as a user wins a badge, I get his entry (in OneToOne relationship) and I indicate that the badge in question has been won.
onboarding table:
user_id
seen_comments (boolean)
seen_results (boolean)
...
As you can see, I store each action I'd like the user to do in different columns and as soon as he has done one and I've been able to modify my app accordingly (by showing him an arrow, etc), I put the column in question to true.
user_counters table:
user_id
count_comments
count_invited_friends
...
I don't consider a user to be a user if he doesn't have an entry in each of the tables (I could have done everything in one table but the users table seemed to me to become huge). The only relationship used is OneToOne between the user and the table in question.
Should I do this ?
class UserRepository {
public function register($data) {
// Create the user
$user = User::create($data);
// Create all its dependencies which are required if I want to consider the user as fully registered in my DB
$user->badges()->create();
$user->onboarding()->create();
$user->counter()->create();
// Return the user
return $user;
}
}
Or should I create a Repository for each of these elements and create the entire user in a UserService ?
How far should I separate things and when does it become overkill?
Is there something that I don't understand in concept of Repository ? If so, could you give me some links that you found useful because I feel like I ran out of ideas for search keywords.
Thanks
What is the correct way to relate users in parse to one another as friends?
I also want users to be able to query other users but not see all fields, like emails. Is there a way I can create a view on the users table with cloud code, and only return this to the client code?
I was thinking I can create a friends table that will have two columns with 2 pointers, 1 for each user.
thanks for any advice.
I was thinking I can create a friends table that will have two columns with 2 pointers, 1 for each user.
I'll do that too, with a status column to handle pending, blocked...etc
I also want users to be able to query other users but not see all fields, like emails.
You have to add a privateData column on user with ACL restricted to owner only, which would contain private infos such as emails...etc
The scenario : an Oracle 11g database containing some sensitive user data that could result legal liabilities if disclosed to the wrong party.
The desired effect : only a certain user, connecting from a certain IP, can see the column that contains this sensitive user data
I am not sure that hidden columns or virtual columns are the right ways to do this. It seems that Fine-Grained Access Control could help. I am not sure of what is the best solution. The restriction by IP is probably done at the listener level?
The question :
How can we restrict the visibility of a column so it is only available only to a specific user? All the other users would never see the column, not even when doing a "DESC TABLE_WITH_SENSITIVE_DATA"
Thanks for any tips.
Simplest way to do this is to create a view on the table that does not contain all of the columns. Don't grant select on the table, but only on the view.
The "proper" way to do this is with Fine-Grained Access Control (Virtual Private Database), which can replace the contents of columns with a NULL if certain conditions are not met.
See the example here: http://docs.oracle.com/cd/B28359_01/network.111/b28531/vpd.htm#autoId17
You can probably build this sort of functionality yourself if you're feeling both impoverished and skilled.
Do you the ability to modify roles and create views? Perhaps you could create two separate views and grant access to two different roles for that table. All users that are restricted from seeing the sensitive data would belong to a "restricted" role and the others would have access to the "unrestricted" role. You would need to grant privileges on each view to the appropriate role.
It is important to note that there are restrictions on updating the underlying data associated with a view. As explained here, views that contain set operators, aggregates and GROUP BY DISTINCT and joins and not modifiable.
I am using a SP2010 custom list as a weekly time sheet for an organization of about 50 employees and 8 managers to use. To create an item, an employee enters client, project, activity type, week ending, and hours in the default view. Now I want to create another view that is restricted to managers. Ideally, I want SP2010 to know who the manager is, and restrict the items they can see to be only those items created by their employees.
I tried the following with no luck.
There is a user information list created by IT that includes all the members of my organization. I added the Manager's Name to every item.
I re-purposed the Modified By column appeared in my custom list when I created that list.
Specifically, I renamed the Modified By column which is a Person or Group type to Manager's Name and changed the value of Show Field: to Manager's Name. I would have rather not done it this way, but I couldn't figure out how I add a list column that is a Person or Group type, and allows you to pick a column to populate with the value I needed.
I saved the view settings and I could see the Manager's Names in the first column for their specific employees. So far so good!
Then I re-edited the view and created a filter that shows items when Manager's Name is equal to [ME].
I saved the view setting and this time I could not see any employee list items which made sense since I am not a people manager.
I had a colleague who is a people manager try it out and he saw no items for his employees, yet I know there are a dozen or so, and they showed up in #4.
I changed the filter to look for his name specifically, and he still could not see his employees, although I could.
So I figured it must be a permission level issue since his permission level was Contribute and mine is Full Control.
I bumped him up to Design level, and he could see his employees as long as I hard-coded his name in the filter for the view.
Do someone knows how to do this easily?
From what I have learnt, there are differences in creating lists and libraries.
A library does not seem to have the functionality displaying group fields in the correct format, whereas a list does. So if you want to create a view for managers / employees then you need to do it in a list, with the manager and employee both as columns in the view.
Just ensure that the employees and managers do not have access to edit their views.
Like the title says, I've been asked to come up with an estimate for retrofitting an existing asp application.
The current security mechanism controls access to different parts of the application (page-level restrictions), but has no mechanism for flagging individual records as restricted. Assigning rights to a user (using the existing, custom access management code) is no problem, but enforcing the rights is a different matter - each asp page has embedded sql - there's no use of stored procs, objects, etc.
Is the only solution to modify each table and query, or is there a better way? Any pointers, suggestions or prayers would be welcome.
This is classic asp, running on IIS6, against an oracle database.
Update: Here's a user scenario.
We have users, managers, directors, and VPs. The managers can see data created by users who report to them, but not users who report to other managers. Users can't see data created by any managers. Same thing with directors - they can see down, but their reports can't see up.
This sounds like an ideal time to implement row-level security. Oracle has a package DBMS_RLS that allows you to define arbitrary access policies that can be applied to one or more tables that limit what rows a particular user is allowed to see. Conceptually, when a user issues a query with no filters on a protected table, i.e.
SELECT *
FROM my_table
Oracle automatically and transparently inserts a WHERE clause defined by your security policy that limits the result set. You shouldn't need to make any changes to the SQL your application is executing.
Assuming you need maximum granularity, the ability to "grant" each and any row to any of very many users, then you have a many-to-many relation, yes?
So apply the following pattern:
Add a tables of users.
Then, for each restricted table, so the following:
Rename it tablename + "_base".
create a many-to-many table that
associates that table's id with a
user id, called tablename +
"allowed_user".
create a view with the name table
name that joins tablename_base to
table_name_allowed_user, with a
select* from tablename_base and
user_id from tablename_allowed_user.
This view should meet Oracle's
requirements rto be "inherently
updatable."
Now comes the hard part. You need to add "and user_id = $user_id" to every query. Find the various functions you're using to make queries. Wrap those function(s) in ones that gets the user id from the session and add that predicate.
One passable way to do this is to read select string, find the all "where"s (for subqueries there may be more that one), and replace it with "where (user = $user) and ". For queries that don't have a where, you'll need to insert this before any "group by" or "order by". This is fragile, so obviously you'll test that this works for all pages (you have an automated test for all pages, right?), and add hacks to cover special cases.
"update" statements won't have to change; "inserts" will presumably insert both to the view and then do a separate insert to the table's "allow_user" table with the id of the inserting user, to automatically grant teh inserting user acces to what he inserted.
If your number of users is more limited, or you're restricting types of users, you can go with a strategy of multiple views named for the user or type; then you'd replace tables names in the queries with the appropriate views.