I am working on a MultiTenant application in MeteorJs and using account-base package to create and manage user accounts.
I have got around the issue of unique userid by concatening the domain with the email. I am however getting an error when registering the same emailid for different domains.
What is the communities recommendation for account registration and all the functionality that the Accounts-UI, accounts-base package provides?
If I'm understanding you correctly, you're asking if you can have multiple apps connected to the same "users" collection and have different logins? If so, then you can't.
Within the same mongo "users" collection, you should only have unique email addresses. While it's not enforced with an index, it does mess up the password reset. I.e, when you do a password reset request and enter the email address, how does it know which account to do the password reset on?
Related
I'm currently building a POS/Store admin app, when a user gets into my app, the Owner of the store will then be asked to login only once for setup purpose (e.g. a new machine), the app will then display a list of staffsName that has already been added by this owner, and then everytime a staff wants to start a new transaction, he/she will only need to click on his/her name, then enter his/her 4-digit pincode to 'login' and process the transaction.
How do i go about achieving this?
I was thinking of using firebase auth for the 'login' of the staff, but then when i log in using the staff credential, I will lose access to the uid of the owner, which is needed to access the owner's store data such as his/her products.
i'm also thinking of using firestore to store the 4digit pincode, but then i'm also concerned about security
There are multiple ways you can approach this, one where you utilize the email login by simply appending a fake domain to the username to create a valid email domain. This user account could be the designated 'user' in question, or utilize credentials inside custom claims or hidden in a database that allows the client or server (depending on your preference) to then log in as the user.
Moreover if you want the manager to login once you can add Authentication State Persistence to specify whether a signed in user should be indefinitely persisted until explicit sing out, page reload etc.
Another approach requires the user also to have a valid auth that is not an email password and you link your pin auth to that main account with Firebase Auth Linking per the documentation: https://firebase.google.com/docs/auth/web/account-linking.
This does however require that the user be registered from an auth provider such as Google, Twitter, Apple, etc. then the user will have to activate this link by logging in for authentication purposes. This can in theory be automatically generated and processed without the user knowing.
It is a long way around it since this is essentially a custom solution but it does create the flow you are looking for without having to use a custom auth provider.
I'm making an app that has Firebase as its database. The app shouldn't need the user to create an account to use it, but I want the user to be able to read/write their data onto the database (so maybe they have to create an account?).
Do I have to make the users create an account in order to use Firebase?
My problem is that my security rules are read/write are allowed for everyone (which I know is wrong, but how do I change them and not need users to create an account?) Maybe that's the issue.
It is best to ask them to create an account
Although:
it can be a non-real email address and
there is anonymous auth also available
It sounds like you need the app to remember that user's particular data, so that when they return to the app, it is still their data (and not someone else's) that is being accessed.
To achieve that, we need each person's data to be stored in a different place in Firebase. Traditionally, this is by having them log in to some kind of system, most conveniently Firebase itself, and then the data stored in a branch of the database defined by their user Id.
Without logging in, you could simply ask the user for an identifier, such as "Bob" or "Carol", and then store their data under their identifier. The Firebase database would therefore have the following structure.
users/Bob/highScore: 3000
users/Bob/level: 7
users/Carol/highScore: 5050
users/Carol/level: 9
However this is not secure because there is nothing stopping Carol coming to the app and saying she is "Bob". Any such client-side activity you carry out to attempt to identify the user is not really authentication (in the opinion of Firebase) because all client-side activities can be faked relatively easily.
Firebase Authentication
The standard solution is to use Firebase to authenticate each user (see the Firebase authentication docs for this), and give your app a user Id (such as "8769dsg6f8g7698769876sdgs9") which is unique and known (by Firebase) to be correct.
Firebase security rules
You can then lock down the database using Firebase Security Rules so that only user 8769dsg6f8g7698769876sdgs9 can write to any of the users/8769dsg6f8g7698769876sdgs9/.... part of the database.
If you don't use Firebase to authenticate the user, Firebase will treat the user as unauthenticated and you will have no way to restrict each user to their own section of the database. Either you leave it wide open (to hackers etc!) or users will not be able to access their own personal data on it.
They can use a FAKE email address and password
If your concern is that they won't want to give out their real email address, you can ask them to make up any email address, e.g. mickeyMouse49857430679304#hotmail.com, and set a password. There is no obligation on your app to contact them on that email address or verify that the email address is correct.
Whenever they come back to the app, or access it on another device, they need to remember the fake email address and password.
Of course, if they lose their password, there is no way to reset it.
Anonymous Authentication, but at risk of losing access
The legendary Frank von Puffelen of Firebase, himself, has added a remark about Anonymous Authentication, in the comments below. From what I understand, this avoids them having to make up a fake email address.
I think the weakness of this is that if they lose their local web storage (e.g. if they manually wipe it, or move to another device), there is no way for them to re-access the same account, unless they have planned ahead by adding an email/pw to the anonymous account.
The only real way to have security per-user data storage is to use Firebase Auth to sign in the user, and write security rules to protect the database so that each user can only access their own data. There are no secure alternatives to this for Realtime Database.
I used AWS Cognito to authenticate users in my iOS application. The users of the app will have to enter the email, phone number and their name in order to register and Amazon will be sending a SMS to authenticate the phone number.
All of these are working fine. I have few questions and they are :
1.) I want to know where these data are getting saved ? It's not there in the Dynamo DB (However, I found the list of users in AWS Cognito --> Federated Identities --> Users , but not in a Table inDynamoDB)
2.) Now, once the users are authenticated, I am allowing the users to interact with the application. The first task will be that the users will have to complete their profile. I want to know if in case if an user is NOT authenticated will he be able to complete his profile ? Ideally, he should not be allowed. But is this happening automatically ?
EDIT
1) You are correct, data is not stored inside dynamo for user profiles. Cognito has an internal data store in which user data is persisted. This can be viewed and edited (as an admin) through the 'Users' tab of your user pool.
2) They should not be able to, and it is not happening automatically. The only way to update attributes stored against a user is as an admin (which the user shouldn't be able to do) or with the token that they get from signing in, so what you're aiming for is very do-able.
I'm developing an MVC4/Razor site for which the client requested the ability for users to be able to sign in with Facebook/Google accounts. Fortunately, this is fairly straightforward using Forms authentication.
However, I'm faced with the issue of: what if the user's email address which is returned by the provider matches an existing username?
For example, tim#rocketeerconsulting.com previously exists as a native account. For whatever reason, the user wants to use Facebook to login. Facebook returns that tim#rocketeerconsulting is the user's email address. If the user attempts to create an account using that information, MVC4 will state that the account already exists.
There are a few concerns:
Should users be allowed to merge accounts if an email address provided by an OAuth provider matches an existing account?
This presents a potential security risk. Can I rely on the OAuth provider to confirm that the address is valid? If not, a malicious user can create a Facebook account and then gain access to another user's account.
How should such a thing be implemented, if at all?
I recognize there is a similar question here, but my question pertains specifically to the context of Forms auth in MVC4.
You are right: it's easy to impersonate this way
Indeed, to add more to the problem, not all the OAuth providers give you the user email address (LinedId).
Every OAuth provider use an email address for initial validation, however, the user can have more than one, indeed some encurages you have them as backup.
So the email is not a good 'key' to identify the user.
Probably your solution will be to have a table with your own internal id and the relate this to the OAuth provider unique user identification: some use the email address, others screen name or similar.
This will allow the user to have more than one OAuth validator on your site.
I implemented this with: Linkedin, Twitter, Amazon, Google+, Microsoft and Facebook. Additionaly, our users can use their domain account to login, but this is another story...
I am trying to find a way to handle two types of users for an intranet system. There are users who login and there are those who do not. I need to store both types of users in the membership db. Does anyone have a common solution to this problem?
This is for an event booking system. The users who are in AD will see the app. We need to store the O/S Name along with a few other attributes from AD in our membership db. The O/S Name gets captured using the Request.ServerVariables(). We need to store those "requester" details along with other details about the event that is being booked.. In addition to those users, there are users that actually log into the system. I was hoping to store both types of users in the membership db, so that when an event is retrieved, the user details will get retrieved from the membership db as wel
If you can use 'Integrated Windows Authentication' you have access to some information about the user connecting to your system.
Therefore you could use this information for the general case, without the login.
If a user then want's more access, he can logon to the site with a special username/pwd.
A membership DB would typically restrict access to a set of users for a particular application on an Intranet site. Only those who are in Active Directory as network users would even see the Intranet in the first place. And only a subset of those network users who have been granted privileges for your application in its membership system would see the link and/or be able to gain access in one role or another. Can you be a little more specific with respect to what you are trying to achieve? :-)