so my situation is that I have a firebase real time database set up for my app backend. Generally speaking, the db stores request nodes, and each request has an 'Expiration' date/time.
I desire functionality when the expiration time for a request occurs, an event is triggered which invalidates that request entry in database and also makes it known to the app frontend where I can show a message to user when he opens the app.
Can you suggest how should I go about this?I'm kinda stuck on this as I'm fairly new to firebase (and app development) so any help in simpler terms would be much appreciated.
Thanks for your time.
You can achieve this in a very simple way using Cloud Functions for Firebase.
Cloud Functions for Firebase lets you automatically run backend code in response to events triggered by Firebase features and HTTPS requests. Your code is stored in Google's cloud and runs in a managed environment. There's no need to manage and scale your own servers.
Hoe it helps.
Apparently, this is not possible with GCF at this point.
I had a similar question: Google Cloud Functions: edit Firebase node at a specific time
Related
I wanted to know if when there's an firebase authentification, it's possible to get the source of this authentification?
To know if it's from my iphone app, android app or web app.
Why :
My web app isn't on the web, but on local server. I want to distribute this web app with server (It's for a personnal project but it could have 10 prototypes). So everybody can get my firebase config. And I don't want that someone can create account from the web firebase api because I accept google/apple and email/password auth. I can't disable email/password for my project purpose.
I hope this is clear.
To be more clear, if the email/password auth is created, is it possible to know if it's from android app or iphone app or webapp?
Thanks
The provided APIs for Firebase Auth don't give any indication which platform was used to create the account. Firebase intends for all accounts to work across all platforms using the provided SDKs and APIs accessible for each platform.
If you want to record your own per-user data in a database, you're free to do that. Note that this is not really "secure" in that each user could effectively manipulate your database or APIs to indicate whatever they want about their platform. If you do not have this sort of security in mind, then you can simply trust your own code to write, and late read, the user's platform in a database after they sign up.
To be more clear if the email/password auth is created, is it possible to know if it's from the Android app or iPhone app, or web app?
Yes, it's possible. Let's say we want to know if a user has signed in from Android. When the user creates an account from an Android device, most likely you are storing user data as objects in the database. The simplest solution I can think of is to add another property in your User class, called "platform" and set it to "Android". If the user signs up with an iPhone, then set the property to "iOS". Same thing for the web. Knowing that the user might change the device, every time the user opens the app check that value against the OS the user is using. If the OS is changed, also change the value accordingly. This way you'll always know the OS the user is using. If you allow the users to use multiple platforms, for Android, there is a function called getProviderData():
Returns a List of UserInfo objects that represents the linked identities of the user using different authentication providers that may be linked to their account.
Similar functions can be found for the other platforms as well.
We have implemented a Backend Server and a DataBase, with RESTFUL API. We have an Android App that can ask the server to send certain data back.
We want to implement an authentication system on the Android App.
The team suggests that I use Spring and OAuth, but I personally have no experience with those, and am not exactly convinced about the necessity of this approach.
Other friends suggest using FireBase to authenticate the users.
Could I avoid using OAuth/FireBase and simply store in the Server's Database the user's account name and its corresponding hash-salted password, along with the salt? Every request sent from the client would contain the account's name (which could probably be a unique ID generated by the server on the very first request, and saved as a SharedPreference in the phone) and the password in clear. The transmission of the request being done via HTTPS protocol (thus using TLS/SSL), the password in clear would not be revealed.
What are the possible flaws to the suggested approach in the last paragraph? And if it is a flawed approach, considering we already are using Spring for the Server (Backend), should I go for FireBase or OAuth ?
Additional context:
Bare in mind that this is the very first largish-scale project that I have been working on (it counts as a 3-credits University course). We are 3 on the project. I'm studying Computer Science but I do not necessarily have a great grasp on all the systems we are using or plan on using.
We are creating an app which allows users to view on a map alerts published by certain databases (we are currently focusing on meteorological alerts) in real-time. We want to be able to implement a login system so that people can receive notifications despite the application being closed (we are allowing users to "subscribe" to areas on the map, to specify the regions they want to receive notifications for).
OAuth, or better OpenId Connect, is a protocol, while FireBase is just one of its' commerce implementations. It's always better to follow a standard where possible than to implement your own. To see the full list of the certified OIdcC implementations look at the OIdC site, and I see at least MITREid Connect project related to Spring. I think your custom solution will work for your custom case, but only until you think about any extensibility such as Google auth or accessing some 3-rd party API.
I'm integrating Stripe Payment Gateway to an Android App and facing some questions and issues.
Following the Stripe Documentation it seems like having its own Server is required.
Digging for a few Hours, Firebase Cloud Functions can do the Server work...Great !!
But from what I can find, it can be done in at least two ways:
HTTP Trigger
A write to Firebase Database that would trigger a Cloud Function
So first, which one to use?
The good old Industry trusted http endpoint with good old Retrofit?
Or the much more simple Write to Firebase Database to trigger the function?
Also, as for the next step, I could not find any Android tutorial for the next steps. Only this Web app: https://github.com/firebase/functions-samples/tree/master/stripe.
From what I can see, it would need Node.js, npm etc etc...
Nothing more simple from Google?
Cheers guys
First of all, either way you're going to have to write backend code in JavaScript to handle payments.
So the process that works for us with Cloud Functions is -
1) Android provides card details to Stripe using native SDK
2) Stripe provides a token which Android sends it to your Firebase backend
you could store it in stripeTokens/userId/yourToken
3) Firebase cloud function then triggers a function and uses this token to create Stripe customer (See saving for later and Customer)
you could store it in stripe_customers/userId/stripeCustomerId
4) Remember to remove yourToken because it's only valid once
5) finally you can use this stripeCustomerId to make payments and update related nodes in the backend
Important concept here is to create a customer and store it in your backend for future payments.
So steps after 2) are all cloud functions, so yes most of the work is done in backend. Only thing Android is doing is entering card details, sending token, triggering and listening for future charges.
As far as HTTP is concerned, concept is similar but only thing different is you wait for the response and if there is any errors you get it there, whereas if you were to do with Cloud Functions, you would have to write those errors somewhere and read those from client.
Hope this helps.
Bit of context, I am trying to use Firebase for both authentication and data storage. Since my application deals with potentially sensitive data, the confidentiality features offered by Firebase (all Firebase communication is done via HTTPS according to their blog) seems like a great way to keep my data secured. In fact, the only problem I have with Firebase is that authentication last far longer than it should. As far as I can tell, it lasts through device resets, application rebuilds and loss of connection. Even worse, I have no idea how long it persists for. I've tried searching online but I can't find the information anywhere. As far as I can tell, it lasts around a day, but that's just a guess. I am using email and password as credentials for my sign in.
My question has two parts, does anyone know the default duration of Firebase authentication and does anyone know how to shorten it? Otherwise are there any other services that are similar to Firebase where you can set the authentication duration?
If I could shorten the duration to 4 hours Firebase would literally be perfect, other wise I might have to implement my own authentication, since authentication that last's for as long as Firebase is far too insecure.
Firebase Authentication (for 3.x or higher SDKs) uses two types of tokens:
A token that identifies the user. This token is created when the users signs in with the app and does not expire. To get rid of this token, sign out the user.
A token that allows the user to access the Firebase back-end. This token is based on the previous token, is valid for an hour, and is automatically created and refreshed by the Firebase SDKs.
I'm writing a game that use Google Play Game Service's quests and events system - https://developers.google.com/games/services/android/quests.
Game will use it on Android devices, but I want to submit certain events from server. I found web rest api for this https://developers.google.com/games/services/web/api/events/record, but it's not clear to me how to proceed with authorization.
Can i somehow send all needed authentication info from client to my server, to use GPGS' rest api in future?
What you want to do is informally called hybrid authorization, and the best way to do that is to send an Authorization Code from the Android app to your web server. The web server can then exchange the code (one time) for an Access Token and a Refresh Token. This is not specific to games and is something that many apps using Sign-In with Google do all the time.
The Google+ Haiku+ Sample shows and example of this flow. The specific pieces you may want to look at (in the Android app) are MainActivity.codeSignInRequired(), the private class in MainActivity called CheckOrRetrieveCodeTask, and HaikuSession.getCodeSynchronous() which calls the GoogleAuthUtil.getToken() method to get the one-time code.
Note that getting this code requires your user to see and accept the standard Google SignIn consent dialog. Additionally, once you use the code once it is invalid (for security reasons) so make sure that your server saves the tokens that it gets from exchanging the code.
The Haiku+ Java Server has a good example of how to exchange the authorization code for tokens.
Once you have the access token, you can call any Google APIs to which the user consented on the client. The Haiku+ Java Server shows an example of this when it fetches the users circles.
Yes, this is a complicated flow but it is the best and most secure way to do this. If you don't want to do all of this, I'd recommend submitting Events from the client. The Google Play Games SDK for Android makes this very easy and automatically handles all of the caching and retry logic.