Use case: the app I built on app.foo.com, and an instance of telescope on community.foo.com, on separate application servers. The only collection they'd share is users. I would give the same mongo url and oplog url to both apps, and make sure that other than users, collection names did not overlap between the two apps.
Should this work fine? Any performance concerns?
The problem with this is you have to share the collection names.
If you use your databases you're also insured against Telescope suddenly using a collection name that your other app uses on a future version too.
What you can do is only share the users collection if you want.
Server side code (not needed on client)
Accounts.connection = DDP.connect("https://<telescope app url>");
Meteor.users = new Mongo.Collection("users", {
_preventAutopublish: true,
connection: Accounts.connection
});
Or more directly (not preferable if you're allowing OAuth logins)
var database = new MongoInternals.RemoteCollectionDriver("<mongo url of telescope app>");
Meteor.users = new Mongo.Collection("users", { _driver: database });
So this app now uses the Telescope app's user's collection.
There would be no problem with this at all. For example it's a common use case to have a user-facing app and an admin app, both using the same db.
This shouldn't be done at the database level:
When any of the two apps evolve, they could break themselves or the other one.
That's the kind of feature that belong in an API layer, or a separate service.
This way you have one user identity service that handles authentication (even cross-domain) and basic user data, and leave each app-specific user information in it's own part of your ecosystem. No risk of meltdown.
I can recommend a few :
Firebase
Parse
Hull.io (disclaimer : I'm a founder)
Auth0
LoginRadius
Most of these have client-side libs that you use to handle authentication and just pass back the currently logged-in user's ID to your app.
Some also offer to have one app being the Master, and authenticating users, then telling the service who's logged in, so you can retrieve data from your other app (at hull we call this Bring your own Users)
Related
I am trying to create a REST API (via Firebase cloud functions) and release it to my clients to allow them creating their mobile apps. The mobile apps they will be creating are used by public users. However, users are not supposed to deal with our APIs and thus authentication. So I don't need end user authentication. It's up to our clients (app makers) to use a "client id" and an "api key".
Based on what I have researched, Firebase Admin SDK might not be a good solution for this end since we're concerned about client level authentication.
I am looking for a standard solution to generate api-keys for the 3rd party clients. This key generation is not a manual process but rather a service that clients will use to obtain a key. Something like google map api for 3rd party developers. We want to keep track of whitelisted clients without needing their app users to deal with authentication.
I'd appreciate suggestions and guidelines to find the best solution for our REST APIs.
The first solution that comes to my mind is thew new Firebas App Check. It would restrict any access beside the Apps and Web pages you have whitelisted for your project. I don't know if that is possible in your usecase (how the cooperation with the other apps look like) but I would deffinitely try this first.
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.
We are trying to create a new storage bucket where its name would be dynamically created. The firebase web interface provides this capability. It appears as the admin sdk (node.js) does not.
This screen capture shows the web interface behaviour. As you hit "add bucket", a new unique bucket name is dynamically generated.
This feature could be useful in creating buckets dynamically without having the need to reuse/develop a mechanic to generate a unique names and also prevent using uids (which is usually not recommended).
Can anyone confirm our understanding is right? Any insight whether this will be release (or at least in preview) in the upcoming releases of the admin sdk?
The sdk should at least have feature parity with the web interface.
If not, I am willing to open a feature request with the Firebase team.
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.
I have a saas platform I'm building and I'm currently struggling with how to model my auth flow. The system is going to be multiple multi-tenant applications but I would like to unify user authorization & authentication. Basically, each US State will have its own web app/resource server/database and every county in that state will be a separate tenant. I cannot combine all states into one application, so that is not an option.
I would like to throw all users and their information/password into one database connected to my auth service. But each county (tenant) admin within each state (web app) needs to be able to add & manager their users and their roles. So the auth service needs to be aware of all the different tenants across each application. I also need to be able to link items created in each database to the user that created it. If I create object "X" and another user in my county views that item, they can see "Kovaci" created this.
I also do NOT want SSO between states but if possible I would like users to be a part of multiple tenants within one app (not a requirement though). Native iOS/Mobile apps are another client I need to support with this flow.
I used this bitoftech article to base off of: http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/comment-page-1/#comments
And here is my paint quick mockup: multi saas design
My question is just generally how do I design this auth part? Can I store all users in one auth db like my goal? If so, how do tenant admins manage them and how do I link tables in my separate app db's to the users' current info in the auth db?