Choosing the collection when creating a user - meteor

Is there anyway that I can chose what collection the Accounts.createUser function inserts to? I am not wanting a user to be created into the user collection as I am already using that collection for users using my app and am wanting to distinguish the two users.

Related

Firebase: Get users for linked to a specific tenant

We're using our auth backend for multiple customers. The idea would be to create a tenant for every customer account. For user management purposes, I need to display a list of all available users in the front end.
As I can't just display all available users, I'm looking for a way on how to retrieve a specific group of users.
getUsers() (https://firebase.google.com/docs/auth/admin/manage-users#bulk_retrieve_user_data) doesn't help, as there is no UserIdentifier for custom claims (which would be a way to differentiate between accounts).
Another idea (as mentioned) would be to create a tenant for every account, and map the users that belong to this account. But it seems like there's no method to get all users for a tenant as well.
Of course I could just store user data in firestore as well, but I'm curious if there's a different way.
Thanks in advance for your help!
The documentation for Google Cloud Identity Platform seems to indicate that it is possible to get a list of the users for a specific tenant by calling listUsers on an auth instance that is initialized for that specific tenant with:
const tenantAuth = admin admin.auth().tenantManager().authForTenant('TENANT-ID');
tenantAuth.listUsers(1000, nextPageToken)
.then((listUsersResult) => {
...
})

Could a malicious user be able to modify Firestore form front end functions?

I have this security concern with Firestore. The issue is could a malicious user for example inject data in to his document? Or even Worst having access to different collections? I know rules play a major part in here, but since I am creating docs/updating docs/deleting docs from front end could an abuse for crud happen in the context of the single user?
Also there is another part; I want to create a userSub collection (from front end) it will have a subscription info.
UserSub/uid
Premium: true
Enddate: 2 days form now
Could a malicious user get the uid from authContext and make crud ops to modify the mention doc in the collection to let’s say 10 days from now extending his sub? Since he knows what doc I am creating for those values (from source code in chrome)?
You must not allow users to update their subscription information from client. This should be done from backend only for example, if you use Stripe for payment, you should use their webhooks which would send subscription information to your backend/Cloud function that would update users subscription in your database or Firebase Auth custom claims.
You must ensure that this data is read only from users side using security rules if using database.

What should be approach to store publicly writable data?

I have a user-profile collection. Currently it is writable by only the user whose profile it is.
Now I want to record the count 'no of times the profile visited' let say profileVisitedCount. And, it also counts if a non-signedIn user visit the profile.
If I store the count in the documents of user-profile collection itself from firebase js client library, I will have to make it publicly writable.
Other option I am thinking is to have a cloud function. It will only increment the profileVisitedCount without need of making the the document publicly writable. But not sure if it is a correct approach, as the cloud function endpoint seems still vulnerable and can be called by bot.
Also, yes 'the profile visit count' kind of data should be recorded in analytics like GA but I need this count to use in one of the business logic like displaying top visited profiles.
So, any guidance on how the data should be structured? Thanks!
You could have another collection called, for example, profileVisitsCounters in which you store one document per user with a document Id corresponding to the user Id. In this user document, you maintain a dedicated profileVisitedCount field that you update with increment() each time a user reads the corresponding profile.
You assign full read and write access to this collection with allow read, write: if true;.
In your question, while mentioning the Cloud Function solution, you write that "the cloud function endpoint seems still vulnerable and can be called by bot". Be aware that in the case of an extra collection with full write access, as detailed above, it will also be the case: for example, someone who knows the collection name and user uid(s) could call the update() method of the JavaScript SDK or, even easier, an endpoint of the Cloud Firestore API.
If you want to avoid this risk you could use a callable Cloud Function to read the User Profiles, as you have mentioned. This Cloud Function will:
Fetch the User Profile data;
Increment the profileVisitedCount field (in the User Profile document);
Send back the User Profile data to the client.
You need to deny read access right to the user-profile collection, in order to force the users to "read" it through the Cloud Function.
This way you are sure that the profileVisitedCount fields are only incremented when there is a "real" User Profile read.
Note also that you could still keep the profileVisitsCounters collection if having two different collections brings some extra advantages for your business case. In this case, the Cloud Function would increment the counter in this collection, instead of incrementing it in the User Profile itself. You would restrict the access right of the profileVisitsCounters collection to read only since the Cloud Function bypasses the security rules. (allow read: if true; allow write: if false;).
Finally, note that it might be interesting to read this article, which, among others, details the pros and cons of querying Firebase databases with Cloud Functions.

Firebase Auth - list of users by Custom Claims

We're using Custom Claims in Firebase Auth to manage access in Firebase and allow custom UI experience.
We're now working on the User Admin part and we can't find a way to retrieve users by the custom claims.
For example, a user belongs to an organisation and have different access level - admin or user.
We need to allow the organisation's admin to see all their organisation's users.
We'd like to avoid using a separate database to manage organisation users to not double up the data.
Is it possible?
Can we retrieve all Auth users while filtering them by specific Custom Claim?
Thanks!
There is no built-in API to get a list of all users that have a specific claim.
There is an API to get a list of all users in the Admin SDK. So you could use that and then filter the users that have the claim you're looking for.
But performance of this will not be spectacular. So if listing all users with a specific claim is a common use-case for your app, you'll want to reconsider your concern about using an additional place to store the data. Duplicating data to achieve (well performing) use-cases is quite common in NoSQL.

ASP.NET Membership on .NET 4.0 Multi-Tenant app. Default or Custom?

This is my first attempt, trying to integrate Membership on an existing shop already in production.
I'm not quite sure, based on my scenario, if I should use the build-in aspnet-providers or custom implementations of them in order to integrate membership.
Here's a few details:
I have a multi-tenant, single database, single schema web app based on subdomain.
The app is already in production and I will later want to link newly registered users with existing anonymous orders by email.
The development will continue after the membership integration, new features will be added, meaning new columns and linked tables for the users table.
This answer got my thinking of using the membership deafult Profile in order to extend the users table created by the aspnet providers, since I don't have users yet. Though its not clear to me how I would link Users with Orders and other tables/entities that might later be added when the app is going to be extended.
Maybe I could define my entities related to users as user-defined profile properties but they would not have associations on my database.
Another overhead I'm thinking of is how would I associate the users with the different tenants of the app. I would want users to be able to regiter in different tenants/subdomains with the same email.
How would you implement membership in this scenario?
This question is an aggregate of a few questions. I will try to answer them to he best of my knowledge
In case of managing users, i would like to suggest that you consider the following approach
Pre-define a list of basic user profile metadata that you will need in the application
Create an extensible approach like having custom fields for the user profile so that it can accommodate any data that may be required to capture in future
You should also be planning for a self-registration system in the application that will allow your user's to register themselves like the anonymuous ones that use the system with an email
Regarding associating the business entities, you will require to associate the entities with the tenant and not with the user. the level of application will be from the tenant and then it will flow down to the users.
Additionally, you should not have the user accessible business entities, when they are maintained in a form of package or so, it will be very easy to manage and use.
Share your thoughts on these approaches.
- Create a tenant identifier column [property] for each profile that identifies the base tenant to which the user belongs to
- create a table that manages the list of other tenant's that the user may be gaining access to at a later part

Resources