When I connect to by database and try to read some data from a container, I get a 403 error that says my principal doesn't have Microsoft.DocumentDB/databaseAccounts/readMetadata permission.
I have gone through all the roles available in the Azure portal, but none of them do the trick.
For some absolutely wild reason, the roles available in the UI are not enough to start reading data from Cosmos. Instead, you need to assign a special, hidden role that exists in the system to read or write data.
See here:
https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-setup-rbac#metadata-requests
Specifically, it's the roles 00000000-0000-0000-0000-000000000001 for read and 00000000-0000-0000-0000-000000000002 for read+write. The same article has an explanation of how to add these from Azure Powershell:
https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-setup-rbac#using-azure-powershell-1
I nearly lost my mind trying to figure out why I couldn't read my own data, given I had given several role kinds to my user, none of which worked. I have no idea why the Azure team decided to hide the required roles from the UI. Hopefully they see this answer and shed some light.
Related
I'm new to react native. I am trying to develop an application that uses firebase user authentication. But there is something I can think of. For example, 2 users have registered to my application but I want to show extra information to the first user according to a condition.
How can I separate these two?
Where exactly should I manage this condition?
The question is not super clear as to what issue you are trying to tackle so I apologize if I am inferring incorrectly.
I use MongoDB personally with a Node/Express backend for user data and haven't used Firebase myself but I'm sure you can do the same things with it. I'll be speaking in Mongo terminology but again I'm sure you can do the same with Firebase and at the least this will give a good idea of the thought process.
I have a UserSchema that holds all the user information. When logged in the client app would get this information to be used on the frontend after authentication.
Assuming you are only displaying "extra" information that doesn't need additional privilege you can just pull in the users data stored in firebase and handle the display of this extra info with logic on your frontend client.
If its extra privilege you need to setup firebase to look at the user data that is authenticating and only serve back information if they have the proper privileges.
Also important to note, you should ensure that when you are updating user information from client -> firebase backend you should ensure that you can only update specific user fields via read/write authentication on firebase.
Hope this gives a little better idea on how this process might look. I'll let someone who has used firebase specifically add tech specifics.
I have been introduced to Firebase a few days ago. Since then I have been trying to discover more features and usage of Firebase, in particular, the usage of the Firestore/Realtime Database.
However, as I am reading into more details, I start to think of some questions. I hope someone that is familiar with Firebase can help me answer them
As for User authentication, I understand that I can use Firebase Authentication where I won't see their real password. However, technically, everything that user stores in my Firestore would be visible to me since I am the owner of the Firebase.
For example, if I were to develop a note/chat app, in which the user can access their notes/chat on the iOS app and also Android. That means all their notes data would be saved in my database. If it happens to contain some private data, then I would be able to read it?
Even if I set security rules, that would be only facing client-side, whereas, for me, the owner of the entire firebase data, I could see the whole thing. Surely, as a customer, you won't want to use an app knowing that I can see everything you write
I am not sure if what I said is true or not. If true, is there a possible solution?
Both of your statements are correct. This happens in most of the apps-websites, the admin or some core developers have full access to the data. That's why privacy policy and GDPR exist. You must specify what data you collect and for what reason. If you intend to use your user data for any other reason you must inform them. Be aware that if you disclose any user information without his permission you can be held liable.
Am a little new to using Realm, but learning fast. I've seen that when using the Realm object server the default setting is that a new Realm is created for each new user. I also see that with quite some effort a Global realm can be created and permissions given to it, so that many users can access that realm. As I'm working on an app where users create orders, then the first approach seems more secure; each user would have access only to the orders created in that users Realm.
My question is, in this situation how would I be able to report on total order information across users e.g. total order quantities/amounts for September for all orders taken?
I haven't been able to find any reporting system or information about this. Any advice or hints & tips that would help me solve this would be really appreciated.
So after making many checks and hearing back from the guys at Realm, it seems that it is not currently possible to get summary info across Realms.
One solution suggested would be to create a "summary" realm and write total info to is as Im creating the other realms, which doesn't sound like a good solution.
So the only solution currently, that will allow you to get summary information across e.g. orders for different people, is to store the information in one Global Realm and set the permissions so that all users can access it.
A final note, Realm have told me that they plan to bring out an enhancement, that will help solve this issue, by letting you set securities for users within Global Realms. Hopefully that comes out soon :-)
Is there a way to protect the database from deletion? I mean it's very easy to click on the "x" next to the root node. This would destroy the whole app and cause an enourmous mess to deal with.
How to deal with this fragility?
EDIT:
Let's assume I have two firebase accounts: one for testing and one for the launched app. I regularly log in and out to use the other one. On the test account I delete whole nodes on a regular basis. An activated password protection would avoid a very expensive confusion of the two accounts.
If you give a user edit access to the Firebase Console of your project, the user is assumed to be an administrator of the database. This means they can perform any write operation to the database they want and are not tied to your security rules.
As a developer you probably often use this fact to make changes to your data structure while developing the app. For application administrators, you should probably create a custom administrative dashboard, where they can only perform the actions that your code allows.
There is no way to remove specific permissions, such as limiting the amount of data they can remove. It could be a useful feature request, so I suggest posting it here. But at the moment: if you don't trust users to be careful enough with your data, you should not give them access to the console.
As Travis said: setting up backups may be a good way to counter some of this anxiety.
Our requirement is something like this.
We are building a multi-tenant website in ASP.NET MVC, and each customer should be able to create their own users as per predefined user roles.
We are thinking about to create a schema for few tables which would be common for customers. So customer can login to system according to their schema logins and we need not to alter any queries to serve all of them.
We are referring http://msdn.microsoft.com/en-us/library/aa479086.aspx Shared Database, Separate Schemas.
Can someone suggest on following
1. After creating schema how to authorize user against a particular schema
2. Is this possible that without any changes in queries db can serve multi-tenants
Thanks in advance
Anil
After much research, I can say that, although it takes more development up front and more checks along the way, shared database and shared schema is the way to go. It puts a little bit of limits on how easily you can cater to a client's specific needs, but from my point of view SAAS isn't about catering to a single client's weird needs. It's about catering to the majority of clients. Not that it's a SAAS but take iPhone as an example. It was built to cater to the masses. Rather than focusing on doing everything it's built to be one-size fits all just by its simplicity. This doesn't help your case when it comes to authoriztion but it'll save you dev hours in the long run.
If you are asking this in the context of SQL Server authentication/authorization mechanism, i can asnwer this question with saying that every user has a default schema which helps query engine to find out required object in the database.
SQL Query Engine will look at the user's default schema first to find the required object (table). If it founds the object in user's schema then use it, otherwise goes to system default schema (dbo) to find it.
Check this article's How to Refer to Objects section to find out how it works. The article also has some information about security concepts related to schemas.