How to create different user groups in Firebase? - ios

I am making a point of sale app, using Xcode.
I want this app to keep track of stock items, allow users to search stock, scan stock, add or lookup stock using a barcode. Items of stock will be stored in a users 'store'.
I want to have three types of users:
A manager user, who creates a store and has full access to the store. He can manage all of the 'employee users', such as deleting their access and employee users must be invited by him to join his store using a unique code. He will have specific abilities that 'employee users' do not such as the ability to add and edit stock.
What a manager account would look like
A employee user, who has limitations. (e.g. cannot see edit users page and not option to edit stock that manager user has).
What a Employee account would look like
A shopper user who can only see a store and the items in a store.
What a shopper users account would look like
The attached UI design should show what I mean. As you can see, the manager user has a manage employee tab that I wish only he can have and the other users do not. The manager has also got the option for more details when looking at stock, while the employee user does not. The shopper account has only got access to two functions, looking up a store, and checking the stock in a store.
So my question is,
How do I code three different types of users in Firebase for my app?
& How do I show them only options that I want to show them while showing other options to other users?

This is an incredibly broad topic and lots of it depends on how you implement the various parts of your app. Below is one of the many possible answers, just in an effort to get you started with some links.
If your app stores its data in one of Firebase database offerings (Realtime Database, or Cloud Firestore), or if it stores files in Cloud Storage through Firebase, then you'll likely want to store the role of each user as a custom claim in the profile of that user.
The Firebase Authentication documentation shows how to set such custom claims, for example how to set the admin property of a user to true from a Node.js script:
admin.auth().getUserByEmail('user#admin.example.com').then((user) => {
// Confirm user is verified.
if (user.emailVerified) {
// Add custom claims for additional privileges.
// This will be picked up by the user on token refresh or next sign in on new device.
return admin.auth().setCustomUserClaims(user.uid, {
admin: true
});
}
}).catch((error) => {
console.log(error);
});
Similarly you could set your user roles in a role property. Then you can check in the server-side security rules of the Realtime Database, Cloud Firestore, or Cloud Storage if the user has a role that allows them access to the specific data they're trying to access.
In the client-side code you can then decode the user's token to get access to the same claims and optimize the UI for them

Frank's answer is the correct one but I wanted to add a very simple additional piece of information. If you store users information, (DOB, nickname etc) in a /users node (as many Firebase apps do) simply add the role within that node
users
uid_0
name: "Larry"
role: "manager"
uid_1
name: "Curley"
role: "employee"
uid_2
name: "Moe"
role: "shopper"
When a user logs in, read their node from the users node and the app will then know what kind of user they are and display the appropriate UI.
You can also leverage that within Firebase rules to control what each role can access.

Related

Sync multiple email accounts at the same time

We have an app that allows us to signup using one email id and can add/ link another email id. When we enter the home page after signup, it should show the teams/challenges created using the first email id on the top and the teams created using the second email id on the bottom. We are thinking of using firebase for backend. Is it possible to have two email ids active at the same time?
No. You must go outside BaaS, particularly Firebase, as you have mentioned. You can consider making your own backend server for that feature.
What Firebase can provide you is the ability to have a single email address connected to different sign-in methods.
ref: https://support.google.com/firebase/answer/9134820?hl=en&ref_topic=6386702
If you're using Firebase Authentication to sign in users, then no, it's not possible to have two accounts signed in to a single device at a time. If you sign in a second account, then the first one will be automatically signed out.
If you want to "link" two accounts in such a way that they can query each others' data, you're going to have to establish that relationship in your database or custom claims, and use that in security rules to allow shared access to data.

How to get a list of shared Calendars in Microsoft graph?

Is it possible to get a list of users (or user ids) who shared their calendars with the person logged in?
I want to have a list of calendars where I can call as I do with
https://graph.microsoft.com/v1.0/users('user shared the calendar')/calendars
There's a way you can take it one step closer to what you want using the beta endpoint: do a GET /calendars for the signed-in user, and for each calendar, check the isSharedWithMe property. If that property is true, the owner property would show the display name and SMTP address of the user who shared the calendar.
Other than the user ID, you can use the SMTP address to index into the users collection in a tenant as well.
You can see a description of the calendar properties in the Graph documentation.
Please be aware that isSharedWithMe, and in general, APIs in the beta endpoint, are subject to change without notice. For that reason, production apps should not take a dependency on such APIs.

Authenticate registering users against already existing User profiles on Server

I am busy with a Web Api 2 project in VS 2013. We have a number of established applications, and a couple hundred clients with in turn thousand's of users registered at each client.
I am assigned with creating a Mobile App (Cordova/Phonegap), but before I can do this I need to create an API that can handle http Requests from the app.
We have a large database with 173 tables including a user table. This database exists at each client (with their own users). I have imported the default AspNet... tables into our database, changed the connection string and have successfully managed to register users on our database.
My questions is this: Is it possible add additional registration requirements? e.g. in addition to Email, Password, (ConfirmPassword), I'd like to add:
1) Mobile Number
2) Identity number
so that they are also written to AspNetUsers, and then somehow create a foreign key link to my existing USERS table, let's say on ID number provided by the user?
The idea is to not let any user register with the mobile APP that is not already registered on the database.
So, how it should be able to work in my head is not necessarily correct, but here is a summary below:
1) User download app from app store.
2) App shows register/login screen, user register with Email, password, ConfirmPW, MobileNr, ID
3) App sends HTTPS Post request to API with above info.
4) API gets info, before binding to model and writing to db, first does a query to existing User table. If a user exists with ID and mobile Number, then AspNetUsers record is created (with FK reference to Users table). If not, user is not allowed to register, and message is returned, e.g. You need to be a Client of "CompanyName" to register.
5) After this, user logs in and uses Bearer token etc. (default log in way).
I know this is not necessarily how it will work in practice, but can something like this be done. I don't want to re-invent any wheel, only add what listed above. Thanks in advance.
Yes, you can customize the User information. You need to customize the IdentityUser class. Here is a great tutorial on how to do it. I even managed to change the normal Id in the AspNetUsers table (which is nvarchar by deault) to an int.

How to implement 'User' functionality in an app?

This is probably a repeat. However, the other answers haven't helped me out. So, here goes.
I'm working on an application and we with need to add 'users' to it. We'll be giving the option for people to sign in with Facebook, Twitter and LinkedIn. I've worked with these APIs before, however never combined them globally.
How can I maintain and manage these users that will use different services to log in. I'm confused as to how they would be stored in a database, would I need to have a different table for each different social service or is there a way to implement a table that will house all users in one place.
From what I understand, you're asking how to manage, store, verify users that will be logging in your application through different social services.
This is how we've implemented it through the various projects we've worked with. From the list of services you've provided we've worked only with twitter and facebook, so I can only speak about that.
Setup:
We have a web service that our iOS app communicates with such as when the iOS app needs to make a request call for user login the server would take the user details trying to login and gives back a response where the app would then do whats necessary.
We have a database stored on the server with a users table which is used to verify a user.
That being said, you need to understand whats common between most social services, or to at least know what the property is that is used by these social services to uniquely identify its users. In this case they all use email to identify users.
You'll find that when interfacing your app with these different APIs, they like to use a login session key used for unique logged in sessions.
So on your database you would store whatever details you want to save of the user, but know that you need to store atleast the username, password (encrypted), email (for identification, unique column), and login_session_key.
Just double check that linkedIn does have something like a session key that it creates when a user logs in with that method. Facebook and twitter do. Send at least the 4 main data properties needed (username, password, email, session) to the server You then follow this sort of approach:
New user
If the user that is new tries to login, the server first checks the email provided even exists in the database, if it does not then you sent a response back alerting the user that the user does not exist; your app would then take them to the register screen for example.
If the user is in the registry page, save all the details you want to store of theirs including username, password and email.
Members
If the user logs in the email will exist on the server side, its an existing user so just update the session key that was sent from the app on log in if the password matches, (in some apps these session keys are used through the life cycle of the application being used, with each request sending the same session key and if at any point the session key does not match during app interaction, it can be concluded that the user has logged elsewhere on another device perhaps.
if the password does not matches return the appropriate message.
That's about it really. We're able to store all facebook and twitter users in one table.

Should I use cookie to store information to track user in application

I need to increase speed of my application but I must also watch on security. First I will explain what app do:
When user register in application he choose school, in user profile in database I store ID of this school.
Every school has it's own page and if user is from that school he can do some things on that school page, write comment's add pictures etc.
User can also visit other school pages but he can't write comments and add pictures.
Currently I keep CurrentSchoolID in ViewBag's.
I wonder is it better to store CurrentSchoolID in cookie.
Is it possible that some evil user user this cookie to harm application?
For application user must have cookies enabled.
If users are not allowed to edit other schools but theirs, you can't count on the ID from the cookie to be true.
Theoretically, what you can do is to save the school ID in a cookie indeed, and upon every write/update/delete action, check (on the server of course) that the logged in user is eligible to alter data related to this school ID.
But in fact, the school ID is unnecessary. Better off - check on the server side which school this user is allowed to edit, and allow the edit operation only if the user edits one of this school's data.

Resources