Is there a why to let two user login with their own email and password and see the same data?
(Maybe one user well login and be transferred to the other user that has all the data).
Thanks,
Zvi Karp
What you were trying to do is about Database Design, it's actually not about Firebase. (watch out: the link is about relational database design, but Firebase is not using relational database. The idea is the same though.)
There are many ways to achieve your goal. Since you didn't describe your question clearly, I'll just give a general solution:
add a key sahredData to your User entity, and the value of this key is the id of the data you want to share between users. Different users can use the same value in this field(which means they share the same data).
whenever a user needs to access the shared data, use the value of sharedData, which is the id of the shared data, to access the data.
Related
I am trying to create a basic app for my small educational business.
We supply English teachers to schools and I want a way for parents to access the progress reports and other data about their children.
I'm using Android Studio and Flutter as well as Firebase to store the data. I don't want parents to be able to access the data of every child, obviously, but they may have more than one child at the school.
So I need to limit their read privileges to just the records that relate to their children. I'd like to do that by giving them some sort of registration code that they could use the first time they access the app so that we can ensure that they are only being given access to the correct records. Subsequent logins would then be via email and password.
Is there a way to do this with Firebase?
Your use-case sounds feasible, but it is really broad which makes it impossible to answer it completely-yet-succinctly.
Specific on what to do with the registration code that associates a parent with their children, when you generate the registration code, you write that code and the associated children to a database. Then when the parent registers with that code, you associate their account (UID) with the code. You'll just have to ensure that the code is sufficiently long and random that it can't be reasonably guessed by another user.
I have a signup activity where users sign into firebase. But I want each user to have a different username of the format username#4-digit-code. How can I achieve this with Firestore as i found out with this post that we can't use queries in our transactions?
What would be the best approach for it to prevent two users from having the same userid?
What would be the best approach for it to prevent two users from having the same userid?
The best option that you have is to check if the username#4-digit-code already exists in Firestore. If it doesn't, add it with the corresponding data, otherwise, generate a new one. This operation should continue until you find an user name which is available.
If you want to make sure you aren't doing many checking operations, then you have to make sure you always generate unique user names, or you can use Firebase Authentication, and instead of that username#4-digit-code you can use the UID that comes from the authentication process.
i was wondering if its dangerous to show the user the id, which Firebase Cloud Firestore generates when creating an new document
Thanks for your answer
In general, no, it is not dangerous, unless you are using that document ID as a secret key somewhere else in your system. Since we don't know exactly how you're using this ID, it's not really possible to say for sure.
Primary Keys are usually shown to users. May it be your bank account number, your user id on platform X - it's not a problem in general, as long as the access in your application is limited properly.
I have a collection called Vouchers. A user can, if they know the unique number ID of a Voucher, "claim" that voucher, which will give it a user_id attribute, tying it to them.
I'm at a point where I need to check a user's ID query against the existing database, but I'm wondering if I can do so on the client instead of the server (the client would be much more convenient because I'm using utility functions to tie the query form to the database operation.... it's a long story). If I do so on the client, I'll have to publish the entire Vouchers collection with correct user_id fields, and although I won't be showing those ids through any templates, they would be available through the console.
Is there an inherent risk in publishing all of the IDs like this? Can they be used maliciously even if I don't leave any specific holes for them to be used in?
First, in general it sounds like a bad idea to publish all user_ids to the client. What would happen if you have 1 million users? That would be a lot of data.
Second, in specific, we cannot know if there is inherent risk in publishing your user_ids, because we do not know what could be done with it in your system. If you use a typical design of user_ids chosen by the user themselves (for instance email), then you MUST design your system to be safe even if an attacker has guessed the user_id.
Short Version: not so good idea.
I have a similar setup up: user can sign-up, if she knows the voucher code. You can only publish those vouchers where the user_id is identical to the logged in user. All other checks like "does the user input correspond to a valid voucher?" must be handled on the server.
Remember: client code is not trusted.
I just set up user profiles using asp.net 3.5 using wvd.
For each user I would like to store data that they will be updating every day.
For example, every time they go for a run they will update time and distance. I intend to allow them to also look up their history of distance and time from any past date.
My question is, what does the database schema usually look like for such a set up? Currently asp.net set up a db for me when I made user profiles. Do I just add an extra table for every user? Should there be one big table with all users data? How do I relate a user I'd to their specific data? Etc....
I have never done this before so any ideas on how this is usually done would be very helpful. Thank you.
One easy way is to just add a (one) table to aspnetdb database, this table will be used to track your running session data for all the user profiles. Name it RunnerSessions or something similar, add the following columns to the table:
UserID (use this field to store the profile id from ASP.NET)
SessionDate (use this field to store the run session date)
SessionDistance (use this field to record the distance from that particular run session)
It is a good idea to make UserID + SessionDate fields as your primary key for the RunnerSessions table or create another field called SessionID and set it as autonumber.
To relate each profile to a particular record in the RunnerSessions table, you can store the HttpContext.Current.User.Identity.Name in the UserID field mentioned above.
You are asking for a relational database design. As relational database design is an art in itself and heavily depends on a lot of case specific conditions I will not be able to provide you with a ready-to-go schema.
As I never read any online tutorial about this I will also not post a link here. But you should be able to get started by searching for a relational database design (tutorial) in your favourite search engine.
Maybe someone knows about a good tutorial and can post a link?