I want to make an app where parents can buy a subscription for their children (one subscription per child) but I wonder how the corresponding accounts in Firebase would look like (buying the subscriptions themselves is out of scope of this question).
Are there best practises I should follow here?
I'll have a parent account in Firebase I guess
how can I create the children's accounts and how do I communicate their (generated?) credentials to them?
Thanks in advance for your insights!
Firebase Authentication maintains a flat list of accounts per project. There is no built-in relations between any of the accounts, unless they are linked (which is not what you want here).
The best I can think of for the structure is to add a custom claim to the child accounts identifying their parent (and vice versa if needed). This needs to be done from a trusted environment (such as your development machine, a server you control, or Cloud Functions/Cloud Run). A local (Node.js, or other supported language) script or this extension that sets claims based on a Firestore document are probably the easiest way to get started with this.
If you choose to create the kid's accounts in a trusted environment with an Admin SDK too, you might as well add the custom claim there.
Related
Seeking some thoughts here. When someone launches my mobile game for the first time, I would prefer they get into the gameplay first before having to worry about "signing up".
I think this provides for a better user experience as you can instantly jump into gameplay. Firebase supports anonymous accounts and saving progress against anonymous accounts, which can later be converted to an actual account (e.g linking their google or facebook accounts to their anonymous account) while retaining their game progress.
Does anyone have any thoughts on this approach or is it better to force a user to decide at app-launch to make a choice between creating an anonymous account or registering using google / facebook / email / etc?
Cheers
Kevin
This is actually a very similar use case to what it often pitched to web developers using Firebase:
For a shopping app, you'll often let a developer go through the shopping flow and finish checkout. When checkout is complete, you then "promote" their account to a full account so you don't bounce a customer out during the critical flow.
For a game, not only do I love this anonymous account flow (play now, then "upgrade" for any social features you need), but I think you can get a really cool natural flow going on. For example, if you were making tic tac toe, you could use a dynamic link to invite your friends to play against you. This link will usually persist across app installation (iOS and Android, although it's a little flakier on iOS) so the player you invite can jump right into the game you're playing using Anonymous Auth to seamlessly create an account.
There are two considerations you need to make though:
You're still storing user data if you pair Realtime Database with an anonymous account. I am not a lawyer, but if your region has strict privacy regulation you will want to talk to one.
The merging an anonymous account into a "full" account process does have some non-trivial edge cases. What do you do if the player already has a full account (obviously, you have to merge the data. But you'll have to do it by hand as there's no game-agnostic way for Firebase to do it for you)? What do you do if a different user claims the same email address when you promote your account (you'll need to throw one out, and there are rules for resolving which has the stronger claim to the name)?
2 is a little complicated also by the current architecture of the Firebase auth SDK as well. All of the C# objects are pointers to C++ objects under the hood. The "current user" was bound in a way that it references a global singleton on the C++ side representing user data. This has the unfortunate side effect that you can't cache a user data on the C# side in the case of a user entering their credentials incorrectly when "upgrading" an account (usually manifesting itself in having to re-enter a username/password and maybe losing cached data). This bug is actively being tracked (I believe it's a side-effect of this one), but in the near term it just means that you probably want a good way to either re-upload local data (assuming you'll lose access to the DB node once you drop the anonymous account) or you'll want to avoid persisting any user-specific data before migrating a player to a "full" account (probably a consideration I'd have with current privacy regulations anyway).
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 am trying to integrate Accounts Functionality in my CordApp, and was going through the supply chain demo https://github.com/corda/accounts-demo-supplychain
Here is a list of my queries:
What is the purpose of the Account Broadcast flow?, not mentioned in the readme file https://github.com/corda/accounts-demo-supplychain/blob/master/workflows/src/main/kotlin/com/accounts_SupplyChain/flows/AccountBroadcast.kt
Is the purpose of Share Account Flow, only that the counter party node's know's the account identity, what if I don't want to use it?
Since account is a sub-vault of the node's vault, that data is visible to that node right?
To share account infos with other nodes on in the zone. You need to do this so that they know which node and account belongs to.
Same as above. You don't have to use it.
Yes.
I am currently building a multi-platform web application and I'm currently busy with the authentication of users. I'm using vue on the client-side and django and the backend with postgres as the db.
I thought I would try out using firebase's authentication as it would speed up the process as well as take care of various issues like security etc. I have now come across a bit of a problem:
I need to add extra fields the user (gender, address etc.)
I need to set user roles (admin, manager etc.)
I am aware about some kind of way to set user roles but not really sure. In terms of extending the user in my mind I have two ideas:
Either I use the UID from firebase as a identifier to an extended user class
in my backend db. But that kinda defeats the purpose of speed.
Use Firestore - not sure how I would go about doing this though.
plz help
I have written a blog and made a video on how you can use custom claims to assign roles to your users. Essentially, you apply custom claims on a secure backend like inside of Cloud Functions, and these can be used to control access to Firebase backend features like Cloud Firestore and the Realtime Database. You can also check out the Firebase guide for more information.
As for additional data about a user like gender and addresses, that should be stored in Cloud Firestore, the Realtime Database, or whatever database you choose to use. It is not information that you constantly need when accessing a User object.
A project I'm working on supposed to authenticate users agains AD. I've never worked with AD before, neither did I work in organizations that use AD, so here's my stupid question: in case if AD involved, who manages roles, groups and users for application? Is it my responsibility to provide an UI for site admin to assign AD users to my app roles or AD admins should take care of creating appropriate groups expected by my app and assign existing AD users there?
What are the best practices in this department?
Once thing to note -- this is not an in-house app, so it is supposed to work with an existing AD. The question is if my expects roles like "Teachers" and "Students" (just to illustrate the point), may I expect that IT people will create appropriate groups in AD and assign users to them?
I don't think you should supply a Gui for active directory. Most organization that use active directory manage it with the standard active directory tools.
If you want to handle the case of small shops. Then make the groups internal to the application DB. You will still be able to use the active directory users. But the group management and membership will be internal to your application. This will avoid most problem of dealing with the complex rules of active directory, and still benefit from single sign on.
One more thing to note. The group names should be customizable. Most places have naming convention for group names.
If you're writing this app for another company, I think you could assume they'll be in charge of managing the AD users and groups. You'll just need to coordinate with the clients on what roles/groups your app will use.
This really depends on who owns the AD, and who is going to be responsible for managing user accounts. If this AD is isolated from your coporate domain, and you want your support or sales, or other business person to manage the accounts then by all means create them an admin tool.
If your trying to tie into your existing AD, then you should work closely with your IT department, they will probally want to create the accounts their own way (especially if your using your existing credentials).
Essentially this boils down to how your IT operates, and what exactly the relationship btw the AD your using and the AD which runs the coporate site.
Edited
Based on your additional info, I think you need to offer an admin concsole. Especially if you want to target the smaller shops out there. Your solution should make it optional so if they want to use the admin UI they can but if the IT department wants to use Powershell for example they can do that as well.