How to delete some specific identities from identity warehouse? Let's assume it's contain "username" Rest of the attributes are null
We can use the command like -> delete identity xyz
But it will only delete xyz. But i want to delete some specific identities(not all)
Many thanks in advance for your helpful info
Related
Here is a description of my tables
event {
id
organization__id
}
user {
id
}
organization {
id
}
organization_user {
user__id
organization__id
}
How can I restrict a user in order to allow him to insert/update event with only organization__id he belongs (through table organization_user)?
You definitely do not need to add any token session variable values other than an X-Hasura-User-Id which I assume you have already implemented.
Using Hasura correctly is all about making the proper relationships between your different tables.
It is important to remember, Hasura can use both object and array relationships for row level permissions lookups.
I am going to assume that the following relationships exist (if they do not, you can create them easily).
event => organization
organization => orgUsers (organization_user array relation)
organization_user => user
Event then has a direct lookup path to user.id and you can check that it equals the X-Hasura-User-Id. Although this is an _eq check, remember: the orgUsers array lookup in that path makes sure that if any orgUser.user.id matches, they will have row level access.
Comment if you need clarification of any of these points.
It's hard to say without knowing you permissions and authentication scheme, but you can accomplish this by using session variables in your row-permissions settings (docs).
First, you'll need your users to have a value in their session token that maps to the organization__id column in your database. For example, suppose your session tokens have a property called X-Hasura-Organization-Id.
Next, disable insert and update permissions on the organization__id column in the event table.
For insert permissions, configure a column preset which sets the organization__id value based on the user's session token value for X-Hasura-Organization-Id.
And, finally, to prevent users from updating records outside of their organization, you can configure a row-level permission rule which checks that the X-Hasura-Organization-Id in the user's session token matches the organization__id of the row they wish to update.
Assuming a simple data structure:
-root
-uid
name:string
-uid2
name:string
Is there a way on firebase side(server) to restrict the unique name?
I've seen some solutions like to store names on another node. The problem would be the store action is actually carried out on client side. It is still easy for a registered user to bypass the checking.
Thanks!
Someone know any way to prevent the possibility of adding new record from lookup field?
I want that the users be able to choose only created records. but they couldn't create new from the lookUp.
thanks!
You need to create a security role for your users defining the permissions you want them to have. You will need to have CREATE permission turned off on the lookup entity you don't want them to create.
One source with further information about Security Roles is here:
http://crmbook.powerobjects.com/system-administration/business-administration/security-roles/
I've tried searching this for days and can't seem to find an adequate answer so I'll ask here.
I'm building an asp.net Membership website.
What I want to do is:
Allow a user to create an account - say UserA
I then want to allow UserA to create "sub accounts" tied into his account, but with different roles as well as different login names (I'll be using email address as the login name)
UserA would be the account admin of sorts.
UserA's sub accounts would be less "adminish" than UserA, but any data that they write to my DB (Entity Framework) would still be tied to the main UserA account which will be referenced to my tables via Membership.GetUser() API calls.
So 2 questions:
1) How would I reference the Membership tables in my EntityDataModel using DB First (I already ran the aspnet_regsql.exe)
2) How would I need to go about allowing UserA to create his own sub users?
Here's an image of my custom tables:
[MasterAccountUser]
MasterAccountId = aspnet_Membership.UserId
AccountNumber = autoincrement number
[UserAccount] - subaccount of [MasterUserAccount]
AccountId = aspnet_Membership.UserId (if I have to have each user create their own)
MasterAccountId = aspnet_Membership.UserId (but the same one as the [MasterAccountUser]
If this is too vague, let me know and I can expand.
I was able to get this to work.
Basically, you just do the standard aspnetdb.mdf with all the in-place security features.
Then you simply add a table with the same fields, and then you reference the
MembershipUser.GetUser(Page.User.Identity.Name);
So you own table will have a "masteruser" with this User.ProviderKey. Every "sub-user" then has the SAME masteruser guid on their record so that they all fall under the same account.
If anyone want more details on how i got this to work, i can happily provide them.
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.