I'm not sure if this was answered somewhere in the documentation, but looking at the pricing tells me that Firebase has to work with client connected to the Internet at all times.
I am currently developing an application with Java-backed server and with client side done in GWT (Javascript). The application is meant to be deployed for "corporate" clients - that means in intranets.
Will Firebase be operational in these circumstances?
Well, I guess I should have read into FAQ more thoroughly:
Can I run Firebase on my own servers?
Firebase is a hosted cloud service, so the general answer is “no.” Some customers have very specific needs for where their sensitive data is physically stored and managed, so we may make exceptions. Contact us for more info.
Related
BACKGROUND INFO
I have developed an application in R through the shiny package, and deployed it online through the shinyapps.io service.
Among its different functions, the shiny app can send emails (through my personal Google Account) to users if the fill a form. The emails are sent through the functionalities of the gmailr package, and to make it work I had to follow the procedure on the Google Cloud Platform to create a JSON token, configure the OAuth consent screen, and store the credentials I obtain in a folder of my R project. All the steps to this process are reported at the end of this GitHub issue I opened a while ago.
THE PROBLEM
The JSON token I generated on the Google Cloud Platform expires after some days.
After googling around, I noticed that this can happen if my "Application", on Google Cloud, is still in the Testing phase. First question about this statement:
What does it mean when Google refers, on the OAuth screen, as an Application in Testing phase? My application is already online on shinyapps.io, it's already functioning, and when I create a new token it can also send emails correctly (for a while).
In addition, on the Google's OAuth consent screen, I now have the possibility to "publish" such application. If I do that, the status changes as In production, and this message is displayed. Other questions:
What does it mean that the application will be available to everyone with a Google account? My application deployed on shinyapps.io doesn't require any login or any other data from the users, then what is this app they're talking about?
What will happen to users that try to connect to my application?
Are my credentials, as for example the JSON file, safe?
I know that there might be a lot of confusion in this post, but I am relly not an expert in this field, and so I am worried to make some mistakes.
Thanks a lot for your help!
The GMail API, OAuth and all, is typically meant to allow your app to send email on behalf of any user. It seems your use-case is a little different - you only ever need to connect one user: your own.
What does it mean when Google refers, on the OAuth screen, as an **Application in Testing phase? My application is already online on shinyapps.io, it's already functioning, and when I create a new token it can also send emails correctly (for a while).
I think you mostly answered this yourself in your further questions. Google thinks you're building an app that any GMail user can connect to, and so for security reasons, they want to differentiate between a test app and a production app. They don't necessarily know whether or not your app is published on shinyapps.io.
What does it mean that the application will be available to everyone with a Google account? My application deployed on shinyapps.io doesn't require any login or any other data from the users, then what is this app they're talking about?
I alluded to this earlier, but the GMail API is intended for apps that allow any GMail user to connect and manipulate their own email. Imagine a third-party email client, or similar. Again - Google's wording sounds a bit odd wrt your app since it doesn't fit that bill.
What will happen to users that try to connect to my application?
If you don't explicitly host your own server that implements OAuth with Google, then nobody can even try to connect. As long as you don't leak the shared secret from your Google Cloud Platform entry, you're safe.
Are my credentials, as for example the JSON file, safe?
Probably anyone with the JSON file can send email on your behalf. Marking your app as 'in production' will not change the security implications of your JSON file.
Unfortunately, Google has pretty tight security around their APIs nowadays. If you want to mark your app as "in production" you might open up a can of worms regarding "restricted scopes" (sending email counts as restricted). However, since you're using the JSON file instead full OAuth, I'm not sure if this applies to you. To my knowledge, you should be safe to try marking your app as "in production". Worst-case scenario, you might be able to weasel around the strict verification requirements by saying your app is "internal":
Internal Use: The app is used only by people in your Google Workspace or Cloud Identity organization. Note that your app will not be subject to the unverified app screen or the 100-user cap if it's marked as Internal.
I have a Node.js API (built with Express.js) hosted on Firebase Cloud Functions and an accompanying web application hosted on Firebase Hosting which is supposed to interact with the aforementioned API.
I would like to restrict calls to the API so that only the web application would be able to call the cloud functions. How can I achieve that?
What I have tried:
using the App Check or more precisely Google's reCAPTCHA v3 for web apps. I have whitelisted the domain of the web application and have activated App Check token validation server side as well. The problem with App Check, however, is that I am able to obtain the reCAPTCHA attestation token from the browser (after authenticating through the web app) and use that with requests made from anywhere. This enables bombarding the API from outside the web application and defeats the purpose of using App Check in the first place.
Something to note here, the documentation for activating App Check in Cloud Functions instructs the usage of functions.https.onCall(). However, since my API is built using Express.js, I had to use a workaround to be able to use functions.https.onRequest() as instructed here.
restricting the Cloud Function from Google Cloud console to allow only clients of the same project to call the function as instructed here. Unfortunately, my web application hosted on Firebase Hosting does not seem to belong under the same Google Cloud project. Apps hosted on Firebase Hosting do not appear in Google Cloud console. Furthermore, after adjusting the Ingress settings of the functions to "allow internal traffic only", I am receiving CORS errors when attempting to access the API through the web application. I am unable to access the API from anywhere else though, which is partly the desired outcome.
Before anyone proposes limiting the domains in CORS options from within the API, while this might serve the purpose of restricting access to the API endpoints, it still would allow calling the function rapidly and thus, potentially, racking up the bill.
I am grateful for any suggestions!
Firebaser here.
This is a great question! Doug has already made some great points above, and I'll just add to that by saying that the TTL on App Check tokens reduce the replay window that you observed in your first bullet point, and this TTL is configurable.
The default TTL for reCAPTCHA v3 is 1 day to protect against running out of quota, but you can set a shorter TTL to increase the cost for an attacker trying to set up a replay attack. But please do be mindful of the associated trade-offs as described in the documentation. You can read about the associated quotas and limits here.
Unfortunately, web applications redirected from Firebase Hosting can't hook up to the GCP internal network. App Check is actually exactly what you are looking for in this situation.
Finally, because we are continuously working on improving the App Check platform, the comments you leave here are valuable for us as we decide on what anti-abuse features we want to work on next.
I have a backend system built in AWS and I'm utilizing CloudWatch in all of the services for logging and monitoring. I really like the ability to send structured JSON logs into CloudWatch that are consistent and provide a lot of context around the log message. Querying the logs and getting to the root of an issue is simple or just exploring the health of the environment - makes CloudWatch a must have for my backend.
Now I'm working on the frontend side of things, mobile applications using Xamarin.Forms. I know AWS has Amplify but I really wanted to stick with Xamarin.Forms as that's a skill set I've already got and I'm comfortable with. Since Amplify didn't support Xamarin.Forms I've been stuck looking at other options for logging - one of them being Microsoft's AppCenter.
If I go the AppCenter route I'll end up having to build out a mapping of the AppCenter installation identifier and my users between the AWS environment and the AppCenter environment. Before I start down that path I wanted to ask a couple questions around best practice and security of an alternative approach.
I'm considering using the AWS SDK for .Net, creating an IAM Role with a Policy that allows for X-Ray and CloudWatch PUT operations on a specific log group and then assigning it to an IAM User. I can issue access keys for the user and embed them in my apps config files. This would let me send log data right into CloudWatch from the mobile apps using something like NLog.
I noticed with AppCenter I have to provide a client secret to the app, which wouldn't be any different than providing an IAM User access key to my app for pushing into CloudWatch. I'm typically a little shy about issuing access keys from AWS but as long as the Policy is tight I can't think of any negative side-effects... other than someone flooding me with log data should they pull the key out of the app data.
An alternative route I'm exploring is instead of embedding the access keys in my config files - I could request them from my API services and hold it in-memory. Only downside to that is when the user doesn't have internet connectivity logging might be a pain (will need to look at how NLog handles sinks that aren't currently available - queueing and flushing)
Is there anything else I'm not considering or is this approach a feasible solution with minimal risk?
I am looking to make an app that would have its Backend on another service like AWS or some other. This app would be having many features and functionalities.
But for chat feature, I am exploring options and wondering that would I be able to integrate Firebase in my app.
I have read about Firebase Functions to add more functionality at the backend and also the installation of Firebase Admin to servers.
But still I am not convinced about their capabilities and exactly what all I can do with them.
It would be great if someone who has experience with Firebase help me out figuring if going with it is the best case for me or is there something else I should look into.
So first you can't use Firebase in combination with AWS or Azure etc. Firebase is based on Google Cloud and is the interface between the mobile client (the running app on the client's smartphone) and the backend (your Firebase project).
What I use is, for example, Firebase Cloud Messaging, to simply notify one or multiple users by trigger an HTTP Request from my own web server.
I also made some apps to store the data in FireStore or in the Realtime-Database, so that I don't have to set up a whole new infrastructure. And this is basically the goal of Firebase that you can simply start with your app, without carrying about that.
So what I've heard about Firebase is that you currently cannot install Firebase on a server of your choice and you have to use Google Cloud.
Hopefully, you can do something with my answer. If you have further questions feel free to ask them.
I am considering to migrate an application to Cloud Foundry since I'm tired of managing my server on my own. In my current application I use Spring Security and sessions to handle my user logins. I am however clueless on how to change my code so Cloud Foundry's multiple instances support my user logged in in a somehow stateless way (but using a token). I have looked into UAA, but it seems that this is for cloud foundry users, not users of my application.
Something OAUTH2-like seems to be a solution, but it seems I would have to rely on third parties if I want to do it in a developer-friendly way. The Cloud Foundry (or Pivotal Web Services in this case) documentation is also quite unclear on the matter.
When looking at the Spring Cloud documentation, I do find information on how to use OAUTH2 providers like Github to do things like Authentication, but it doesn't show how to actually use the Principal or how to handle stuff like Authorization (role-based).
I assume there are ways to run my own OAUTH2 service, and that would be the recommended solution, but again, there's quite a lack of documentation.
Can anyone give me some pointers?
A couple of key questions here are where is your user store currently? And what do you want to do with it moving forwards?
If you manage your own users and wish to continue doing so then, after migrating your users to the appropriate backing service and updating your app to be able to bind to that service using CFs VCAP_SERVICES env variable (also see spring cloud), our session affinity should allow you to push your app pretty much as-is. Otherwise a little further discussion is required.
Does this help:
https://docs.cloudfoundry.org/devguide/deploy-apps/prepare-to-deploy.html#sessions
Cloud Foundry supports session affinity or sticky sessions for incoming HTTP requests to applications if a jsessionid cookie is used. If multiple instances of an application are running on Cloud Foundry, all requests from a given client will be routed to the same application instance. This allows application containers and frameworks to store session data specific to each user session.