thanks in advance for any help. I've seen variations of this question, but mine offers a little twist.
I am working on an 'invite only' site (the twist), where administrators create the accounts for the users. I have a form that has the necessary sign in information as well as other user data. Here's where I'm getting tripped up: Some user data goes to Cognito and some goes into DynamoDB but I can't seem to figure out how to associate the two.
To make my example easy (I hope), pretend that the admin form has First Name, Last Name, Email, and User Type. Now first name, last name, and email belong in Cognito, but the UserType belongs on a User table in DynamoDB. I can call Auth.sign_up and it creates the account in Cognito and sends the email to the new user and I can then separately write the user type to a user table in Dynamo DB but something needs to happen to let me know that the user in DynamoDB is the user in Cognito and I don't have all the necessary ids yet.
I've seen using triggers for this, and that could work if I didn't have other custom fields. I could just set up a Post Sign Up trigger and use Lambda to write the new user from Cognito into DynamoDB with the basic name/email. What about the other custom fields such as UserType. It all needs to go through and be associated to the Cognito id in my DynamoDB table. That way when the user logs in, I can pull this data entered in by the admin from DynamoDB.
FWIW, UserType is much more functional to the application and can be changed which is why I feel it belongs in DynamoDB. It's not just "admin" or "normal user" -- it's more specific to the workflows I'm generating.
I may be overthinking this, but I can't work out what the workflow would be to make this work.
Thanks
Related
Im triying to use firebase in my app but I have a doubt about registration process, I declared an User collection, but when I sign up with google or facebook, the data is stored in Authentication, I want create an user but besides the fiels email and password, also with a fields like address, role, city and use the createUserWithEmailAndPassword method , to create the user with all those fields, is there a way to do that?
Auth only creates it's own entry to its own table. so you should first get these details from the user and send them to user collection manually.
You can create a new user object adding all these details into it and call this:
this.fireStore.collection("users")
.doc(user.id)
.set(user);
Due to security reasons, I wouldn't recommend storing the password in the db though.
I am developing an app for my college and there are different types of users called students ,teachers , hod's
etc. When they login, how do I know a teacher logged in, or a student logged in? Is there any function in firestore for role based signups and signins?
I was thinking that when a teacher signs up, I will add a tag end of her uid.username that if username is 'DANIEL' while signup, I will add a tea for teachers and stu for students at the end of the name what they provided.
So when they login i will get the uid and do the string manupulations and get the last three letters so that i can know who logged in so that i can show different UI to Different types of users
Is there any best way to do like this ?
while singning up user enters his username example:"daniel"
i will update that username in uid.username like this "daniel-stu"(if student signed up),"daniel-tea" if techer signsup.
Storing this information in the user's display name can work. You can read it back from there next time, and take action in your application's client-side code. But note that this means that any user can change their role, since they can also call the same code to update their profile. If that is not a concern for your app, then this approach sounds like it would work.
If malicious users should not be able to change their role, then you shouldn't set that role from the client-side application code. In that case, you can set the role from a server (or your development machine, or Cloud Functions) using the Admin SDK. Since the Admin SDK runs in a trusted environment, it has expanded privileges and can update the profile of any user. So the Admin SDK could update the display name of the user in the same way you have in mind.
But this still isn't secure, since you're still setting a property that anyone can modify for their own profile. Again... if that is no problem for your app that is fine, but if the use-case requires that you can rely on the property to be correct, we have to keep looking elsewhere.
The Admin SDK can set additional so-called claims on a user profile that client-side code can't modify. Such claims are for things that affect the permissions of the user, such if the user is an admin, or what role/group your users belong to. This sounds quite close to what you are describing, so can also be used. And this time, only your code that runs in a trusted environment will be able to do so.
Finally, you could store the additional information about a user in the database. It's quite common to have a collection (Users or Profiles) in the database, where you store a document for each user (with the document name being User.uid). You create the document when the user first signs in, and update whenever you need to. You can do this from the client-side code (if there is no need to control what gets written), or from code that runs in a trusted environment (such as your development machine, a server you control, or Cloud Functions) if you do need to keep control. A big advantage of this approach is that all users can potentially see the information in this collection, where the client-side Authentication SDK only allows a user to read their own user profile.
For more on this, see:
Adding new data to firebase users (in which I essentially list the same options with fewer words)
Add extra User Information with firebase (store the information in the realtime database)
Associate Firebase Users to Database Records (also using the realtime database for the additional information)
Cloud Firestore saving additional user data
this video explaining custom claims
and many more previous questions on this topic
Is it safe to share a user's ID that Firebase creates when a new user is created? I'd like to use it as an easy way to find other people on my platform.
I don't see why it should not be safe, so if it is. Please enlighten me :)
I am not too familiar with your system or how Nintendo does this (not really a gamer) but you can build something like this:
You can display the list of users (using uid, displayName and photoURL which can be obtained using the Admin SDK or by a list you maintain in the Firebase Database, Firestore, etc) to an authenticated user.
Let's say that user wants to add a connection or friend, you can get that user's ID token, the friend's uid and then add that user's uid to that authenticated user's pending connection list after you verify their ID token.
On the other end, you want the other user to accept the connection request (assuming this how your people finder feature works in your app). You would show the list of pending requests. When the user accepts the request, they would send their ID token and once that's verified, you can consider the connection completed.
To summarize, you still need an ID token to confirm the user sending the request and the one confirming it. Otherwise, if you just solely rely on uids, any user can get the uid of other users and try to add them to each other's friends list, etc.
Hopefully this points you in the right direction.
I'm trying to arrange being able to login with a social network (initially LinkedIn, but it could be any other, or self-generated from FosUserBundle), and then adding new connections to the same user, via Twitter, FB, Github, etc.
The difficulty is connecting the multiple account connections within FosUser and the HWIOauthBundles. In order to collect as much data as I can, and be able to easily add additional connections to services, I'd really like to have each new connection as a one-to-many record. IE: The initial login with LinkedIn creates a FosUser record, and a new row in a 'socialLogin' table, the next (say login with Twitter) adds a new row to the 'socialLogin' table, that refers back to the fosUser.id.
How can I use the currently logged in (Fos)user as part of the new record that HWIOauth would generate? The end result would be, being able to login with any known user to get into the same account.
The solution is actually easy. First check out Symfony2: How to login using OAuth (HWIOAuthBundle) + custom roles (by default and loaded from DB) which is a great how-to for HwiOAuthBundle, and then scroll down and carefully look at public function loadUserByOAuthUserResponse(){ ... } section.
From there, your workflow will be checking the provider name from the response object. And then based on the provider name, you can update your user (use email for searching). However, with twitter you may have problem because twitter doesn't supply user email. So you need to ask your user for that email address and after you get that, you may need to merge current user account (for twitter based reg, consider it as a temporary a/c) with previous user account with this email.
Otherwise, if your user is already logged in using form/other-social-login (before connecting with twitter) you can add his twitter details once he connects with it. But you need to store user's currently logged in details in session (so that you can fetch it after user comes back with twitter token)
Hope it helps
First step would be to create the relation between the user entity and the social_data table and the rest is all about overriding the custom user provider FOSUBUserProvider.php, which I believe you already have started doing as you have FOSUserBundle and HWIOAuthBundle working together.
I will make some edits with actual code later, but I had to answer this to get you on the track until then.
I am creating a website where you can create an account with your name and email. When this is done, you get a 30 day trial. From this point, you can 'upgrade' your account by supplying more information.
When you do not update your information after 30 days, your account is suspended.
Can anyone give me some tips how to do this ?
So:
- Create profile with email and name (easy), indicator is stored in db that you are trial user.
- When you log in, you can extend your profile with extra information. indicator that you are full user.
You can always write your own module to do it, but my recommendation is using the Rules module, and using several user roles.
Any new user gets a "trial" role he registers.
Create the needed fields in the user profile
Create a rule which will change the user's role in case the field is filled (rule triggeres whenever user profile is updated).
Create a rule with cron that executes once a day, to suspend user account, and probably to send him a notification before doing so.