You can do this with a HTTP request. There are no specific components for that yet.
Thanks! Would you happen to have a sample or something to get me started?
I do not as of now. If I have something in a couple of days I’ll surely post it here.
Were you able to get a sample/example, or figure this out on your own?
Here’s what I did.
Created a new data source.
Enabled POST only. Entered the information below.
Created a data variable for new records:
To my register button, added a create record flow function. Created two page variables for email and password fields and bind them to the create record flow function.
Additionally, I wanted to store user information on firestore database so once the record is created, the second create record flow records the user information. Once it is all over I redirect them to the login page.
I could also redirect them to home page without additional login but people tend to forget the passwords so I wanted to make sure they at least log in once.
I’m not sure if this is the best practice but for me it works. Of course I’m open to suggestions.
Thank you for supplying the screenshots and your steps. They worked for me and I am very grateful that you took the time to make your response. I am sure it will help a lot of others also.
I do have a follow-up question though, what is a good way to link the newly created user to details they entered into the form during registration in to the firestore database, like First Name, Last Name, Phone Number, etc.?
Hi @Atakan_Tokgoz ,
thanks a lot for sharing these steps.
Just one detail to the first screenshot:
what do I need to enter for the query parameter here?
and what purpose has the key in the HTTP header?
figured out the answer for question 1 myself:
according to the Firebase Docs it require the API_KEY to the project.
‘Firebase Auth REST API’
The API_KEY is found in the project settings (look for Web API key):
For question 2 I just entered the text exaclty like in Atakan’s screenshots. Don’t know what it is for, but works
@Robert_Doodles, once I receive the response from the register request, I initiate the second post request as shown in my previous flow screenshot. For the other form values, I created page variables for all of them and set them to the values, but I think creating one data variable is a better choice (which I will fix on my part). I also use the flow output value for authorization uid into my user identity database.
I use firestore database and created the firestore data source in AppGyver. I don’t have anything fancy:
What I really would like to do is mapping the UID from auth and the document ID. It should be possible for rest API data source but I don’t think it is currently possible for firestore data sources. Perhaps @Mari could provide an answer there.
Glad that you’ve solved the question yourself! Yes, the key value is your web API key from your project.
For your other question;
Content-Type means how my HTTP request body should be structured on the receiving end.
Content-Type: application/json means that my HTTP request will be JSON. This was a requirement from the Firebase Auth REST API documentation as well.
I also am working on trying to figure this out, If I do I will let you know.
I am also trying to solve this problem.
For some reason, the second create record (for other user-related info like name, etc.) keeps failing. I think it may be due to the rules in Firebase which are: allow read, write: if request.auth != null;
Do you have this rule? Or do you allow writes without auth?
After changing my security rules I also started receiving authorization errors. I added the email authentication flow between the two requests. So once registration is successful, I use the same email&password parameters to authenticate the user, then start the second record creation.
This worked great! Thank you.
Could you explain this last photo? I’m not able to find some of the flow functions.
You need to download additional flows from marketplace. Open Flows, click search and write “fire” in the marketplace. You should see all the firebase related flows.
Hi there, regarding mapping Doc ID and User there is a workaround where you can create a specific Doc ID (ie UserUid) and therefore have a ref like this. That way you are just fine with calling Get record (as that require doc id) instead of collection.
Hope that makes any sense. You can check my previous posts, where I already tried to explain that.
I must state the pleasant surprise reading “Aramıza Hoş Geldiniz” in your screen-grab (Confessing that I had not read your name fore-hand)…
Çok sağol Atakan! Harikasın!
For reasons I could not understand: after I change privacy settings: I always got an error on some phones while none in others. Oddly… this solved much: THANK you.
What exactly do you refer to as you mention “creating one data variable”?
Do you mean that it is to be set up WHILST signing up?
If so: HOW?
Are you able to customize firebase user data?
What happens then? Do you also provide “user based” authorities fireBase based (Tongue-Twister )? Or would you personally advise to keep it locally with simple if functions?
To better explain my point (More-what my plans):
An administrative user capable of adding/removing authority sort of checking your “HasClub” on/off… That is cool… And what I want… But would be VERY cool is that the administratively authorized user actually fills in users on his own… from the app (Just like he can add users from fireBase itself). And to date I thought it to be impossible/not permitted. But your mentioning “one data variable” got my hopes up and I couldn’t help but burden you with more replies through which you have to date been so helpful with.
Would you please be kind enough to link us to it? Had you meant THIS one?
As I understand: you are actually answering the question I am asking… But I failed to take it home as of yet.
Rica ederim, ne demek
This is actually related to AppGyver variables. I have created page variables but having data variables makes it easier to map the values on the “Create Record” flow. Though it is not a critical error, just a way of working.
I’m not that much familiar with Firebase but to my knowledge, it is not possible to customize the firebase authentication. I would achieve that by using firestore database and appgyver’s front end capabilities:
- Create an access table (collection) in firestore
As fields, I’d have Role, Screen Name, Screen Access (0 - No Access, 1 - Read-Only Access, 2 - Write Access)
- Add Role field in User your Users Collection (which is a collection that you create to store user info)
- Create page variable called AccessRight. On the screen, set visibility/read-only formulas based on the value of that page variable.
- When the page launches, call the access table and check if this user has access or not.
Of course, this is only useful if you’re going to have multiple roles that you’ll regularly update. You can also have a true/false value called IsAdmin and do the same checks.
Then for restricting reading the data there are Firestore security rules but I haven’t got into that yet honestly.
I love the amount of time you tend to put into your explanations… It makes a massive difference. Thank you.
Upon writing to you I have done a fair bit of reading and the only “work around” does seem to include a variety of log in protocols which complicates it more for some than it does for others so thus granting Google verified users to have a specific authority while telephone verified users to have another and so forth.
Not that they can have additional variables in their registration but just that you can set it as a differentiating factor between users as their unique ID is dependent.
NONE the LESS: this is pretty much useless in our so mentioned scenario since the verification method is what determines the accessibility rights. Not the administrator.
So it brings us back to what you saw to it as a way out as well (I initially seem to have misinterpreted your statements with subjectivity of rather high hopes it seems. As now I read it: it is more clear ad ever more clearer with your added explanations)
This as well as “Disabled:true/false” is pretty much what I had chosen to go for.
Why it was so great for my part to be able to add users from the app itself was basically client-oriented. As the people to use it are not “technically inclined” to say the least.
So it would be great to have them be able to modify accounts from the app itself instead of logging into fireBase and manually adding names.
The way I see as a workaround is for them to be sent a list of new users and for them to be able to modify their authorities from the app later on. Pretty much exactly how you say you would go…
- Client verifies identity via valid email. Those that s/he needs to give direct access are going to have to have SOME email set-up in order to register (Sadly; even in a country where almost EVERY one has a Facebook account… There are specific businesses where technology just does not correctly visit).
- User with administrative authority receives a list of the users and grants them authorities according to how s/he sees fit through uploading "tag"s per user (pretty much like your proposed method).
- This newly granted authority determines their “accessibility” to specific visibility and/or functions.
This is much manual work whilst preparing its interface on my part as I see it… But it solves a lot of things…
Thank you once again for your generously donated time for explaining everything in a surprisingly clear way yet once again!