i have a problem with airflow.
Does Admin creates variables and controls access to each variable for each user?
Example: admin create Variable a, b and user userA, userB
Does admin can create role that allow userAread, edit variable a, can't edit b and userB read, edit B, can't edit a
Interesting question!
Part 1
As an admin you can create the following permissions .
So perhaps you can first ensure the users cannot delete Variables.
Part 2
If User A and only User A knows the Variable value. I would take advantage of a lesser-known Airflow feature to mask sensitive fields. I have provided 2 URLs for ways to approach this. So essentially the variable output will be masked, allowing User A to only know the answer. User B will see a variable exists however the value is masked. I believe you might also have to ensure you restrict CLI access.
source a
source b
Part 3
FYI - Airflow can automatically obfuscate any values when the variable name contains either secret or password. The check for this value is case-insensitive, so the value of a variable with a name containing SECRET will also be hidden.
Related
I'm working on a project where I have to handle unregistered user - users that have been added to the group but still they do not have registered in the app.
What I'm doing now is to create a new child in my 'user' db, putting all the info that i know about this unregistered user.
Of course, it also has an id.
This id will be used to represent that user and so it will be used in a lot of places of the db.
The problem comes when this user tries to register itself. Since when creating a new user it's not possible to force the 'id' that he already had, Firebase will create a new id for him.
Then, in the db I need to change all the references of the 'old id' with the new one.
Is there any better way to do it ?
1) You can use another "fake" table to remap the IDs, that is, instead of changing the old id and its references you can add new instance to your "fake" table when user registered. And when needed using simple service you can find the corresponding id.
2) Secondly, you can do authentication yourself, what I mean is that, you can develop your own registration service and define the id yourself in registration. If system is already big and hard to change. First option would be suitable but will have some cost in terms of time.
Is there any way I can find if users is present in both the groups here: user 1 so that notification/data can be sent to only that set of common users only?
As DB grows I think it will be inefficient to check if every user in one group is present in another or not.
Yes there is. You can create a list of users from GroupA, then create another list of users from GroupsB and then just simply use this line of code using Java8:
!Collections.disjoint(list1, list2);
In an MVC application I have a two pages process. On the first page we gather information that will allow us to identify which database record to update. On the second page we gather new values used to update this record. In order for this to work, we need a way to persists information between the two pages, including some record id.
I though of two way to do this and both have some problem.
Store the information in the Session object.
This works as long as the user does not open a second browser window or tab. If he does there is a risk that he'll apply the modifications to the wrong record. Suppose he opens tab 1 and complete the first step. Record id 1 is stored in the Session object. The user then open tab 2 and complete the first step. Record id 2 is then stored in the Session object overwriting record id 1. The user then come back to the first tab and complete the second step thinking he is editing record 1, but in fact he will be editing record 2.
Store the information in an hidden field on the page.
This would solve the problem solution 1 has, but it would be trivial for a ill-intentioned user to change the record id to overwrite any record.
While typing this question I just though of a third solution. That is an hybrid of theses two, but I'm not sure it's completely safe. We could store a random id in an hidden field on the page and use this to prefix the key we use to access data in the session object. I think this would work. Could this be exploited as solution 2 could?
Any other good way to securely store data "per tab" instead of "per session"?
Considering way 2 you may check security server side. If a user does not have modification rights on a specific record then server must not save it. Otherwise he/she is modifying a record that has modifications rights on it and does not matter if he/she is doing it by standard UI or hacking under it.
I think you are mixing up two things - authorization and passing data.
If user is authorized to do stuff with "another record", it's not important if he "tempers the hidden", because he is authorized to change another record as well. Nobody is going to do that intentionally. Means - you just need to check if user is authorized to do stuff in every post from the user i.e. in each controller method (and this is normal practice to always validate all user input server-side).
I would suggest you go with "hidden field".
If you want to separate info in different tabs you should use sessionStorage that differs for each open browser tab.
You can set it like this:
sessionStorage.setItem("perTabValue", "true");
Then you can get your value:
var x = sessionStorage.getItem("perTabValue");
if(x === "yourValue"){
//do anithing you want
}
I see lots of examples some even with great details on how to apply claim based authorization for resources.
Unfortunately, all are aimed to a specific resource so you do something like :
GetEntity(int id)
CheckAccess(id, user);
Then in few examples I see the permission/claim for the action
GetEntities()
where you have a true or false access to the result view. (which is ok)
What I don't seem to find or understand, is how on a GetEntities action, I can return a list of entites and get the permission of the data using claims.
Practical example:
I have a shared address book for some X users in some group.
So group 1 have contact A, B, C
user 10 have permission to list contacts of group 1
user 10 have permission to see full details of contact A and B
user 10 have permission to see basic details of contact C
So I will end up showing in the view something like :
Contact A: name, phone and address
Contact B: name, phone and address
Contact C: name only.
Another thing is not quite clear, is where in the database should I store and how claims so I can later filter the result set from the database.
Let's say user 9 don't have permission to list contacts of group 1 but 2.
How is this claim stored and used to filter results on query ?
I know this is a pretty basic question, but i just don't get it!
I am developing an early version of my site and before I create the production version, I'd like people's opinions on whether I'm going about things the right way. The main objective is to allow users to share playlists. I have the User table (ASP.NET Membership), Playlist table and a permission table. I'd like a user to create a playlist and grant/deny access to it for a given user. My approach to this is to have the permission table contain a "pStatus" column where 0/null = deny, 1 = read.
When a user requests permission to access a playlist, the creator chooses the pStatus enumeration. The column is then changed accordingly for the recipient. When accessing the recipient's profile page, a scan of the column is done to check all playlists the recipient has access to and the relevant playlists are displayed.
Is this an efficient and secure way of doing things? Or is relying on one column not enough?
(nb - playlists can be considered to be similar to Facebook groups)
Thanks for any advice
I would use some sort of bitmask in the n-m relation table I'm guessing is in between User and PlayList (i.e. a table named UserPlaylist, because 1 user can have access to more than 1 playlist and vice versa 1 playlist can be accessed by more than 1 user).
If you define the needed permission levels up front (i.e. 0 = no access, 1 = read, 2 = write, etc.), you can just add a column to the UserPlayList table, that represents the access level.
So the UserPlaylist table will have 2 foreign key columns of which the combination should be unique (i.e. define the primary key to be the 2 foreign key columns) and a column that holds the level of access in the form of a bit / integer.
So Permission has foreign keys to User and Playlist. Is there any reason for the third column specifying permission level? It sounds like it should be: If a row exists in Permission, the user is allowed to access the playlist.
Otherwise, that sounds good to me.