The educational organization that I'm working for have for some years been using a custom built Firebase site as a Learning Management System: custom email/password authentication, access of pedagogical recources with custom built frontend exercise modules/learning games, user administration etc.
Now, this organization is to an increasing extent using Google Workspace for user administration, resource sharing etc. However, Workspace itself can't be used as a replacement for the Firebase site due to the limits in design possibilites, lack of customization of pedagogical content etc.
So, does Google Workspace provide api's that would make it possible to use it as a "backend" for a Firebase frontend?
The most basic and inportant thing is authentication/authorizaion: Users should get access to the Firebase site and its resources via their Workspace account group and membership(s) in Workspace group(s).
When it comes to content, it would be great to - apart from the custom Firebase documents/pedagogical modules - also be able to present documents/resources from associated Workspace groups.
All in all: as much as possible of user auth, user adminstration, document resources should be kept on the Workspace side, with Firebase used as a facade communicating with workspace via api's, and also providing the customization possibilites when it comes to special content not possible in the Workspace context.
How much of this can be done with the combination of Firebase and Google Workspace today?
Preferrably using api calls, not by first copying/syncing database information back and forth?
Related
I have enabled the multi-tenancy feature for my firebase project in the GCP console following this guide but now there's no way to disable it back.
Will this affect any of project's behaviour?
As per the Public Documentation, currently there is nothing mentioned about how to disable multi-tenancy , however Google Support is aware of the issue and working on it. There will be some update in near future but currently it's not possible in UI or SDKs.
Will this affect any of the project's behaviour?
As per Firebase Documentation , multi-tenancy is not recommended for the Firebase Projects as mentioned with a reason :
Multi-tenancy can lead to serious configuration and data privacy
concerns, including unintended issues with analytics aggregation,
shared authentication, overly-complex database structures, and
difficulties with security rules.
Generally, if a set of apps don't
share the same data and configurations, strongly consider registering
each app with a different Firebase project.
For example, if you
develop a white-label application, each independently labeled app
should have its own Firebase project, and the iOS and Android versions
of that label should be in the same Firebase project. Each
independently labeled app shouldn't (for privacy reasons) share data
with the others.
To get more information related to the Firebase Authentication, you can refer to the doc.
If you want to continue in a multi tenant project below are some points which may help you perform certain activities on a multi tenant.
There are situations, however, where you want users to be manually or
programmatically created by an administrator, either using the Admin
SDK or Firebase console. In these cases, you can disable user actions
from the Firebase Authentication Settings page, which prevents account
creation and deletion by end-users. If you are using multi-tenancy,
you will need to make an HTTP request to disable these features on a
per-tenant basis.
You can also Manage Identity Platform tenants programmatically by User management,Identity verification,Import users,Access control with custom claims,User session management,Email action links,Tenant management by Create, list, get, update, delete tenants for a specific Identity Platform project , Manage OIDC and SAML providers on tenants.
There is a warning on the Firebase best practices documentation against using Firebase with multi-tenant applications: https://firebase.google.com/docs/projects/learn-more#multi-tenancy
This is what I am most concerned about: "Multi-tenancy can lead to serious configuration and data privacy concerns problems, including unintended issues with analytics aggregation, shared authentication, overly-complex database structures, and difficulties with security rules."
There is also plenty of official Google documentation supporting the use of Firebase for multi-tenancy, for instance: https://cloud.google.com/identity-platform/docs/multi-tenancy-authentication .
Do you know why they would have these conflicting recommendations and examples? Does use of Google Identity Platform fix the core security deficits mentioned in the warning?
I am re-posting this question, with additional clarification in the title, and a few edits/removals from the body, to specify that I am only looking for why this widely used product has this particular warning in its official documentation. I have removed most subjective content. I have no opinion on this that is relevant to the question - I am only looking to understand the warning. It seemed there was one good answer before the previous question was closed, so I will link that here for reference: Why is Google Firebase not recommended by Google in their own documentation for multi-tenant applications?
That does make sense if you manage 2 separate applications which have no relation with each other. Let's say you have an app that manages a school's information and other one is a restaurant management app. Now in this case I don't see any event that the school app might need access to restaurant data.
If you use the same project, then all the firebase services (auth, database, analytics, etc) will be shared among them. It'll be hard for you to separate analytics for each of the app. As the database is shared, you'll have to explicitly separate data of both apps by separating the path in db. (/apps/school for school, /apps/restaurant for restaurant).
That being said, any user registered on the school app can login on restaurant app without creating a new account there as you are sharing the same project among them.
Now if your client pays you a the Firebase costs every month, you cannot distinguish between how much should the school client pay. Now even if both the apps are your, the complexity will increase significantly if you go on using it.
https://firebase.google.com/docs/projects/learn-more#multi-tenancy <-- this explains how "Firebase Projects" works and https://cloud.google.com/identity-platform/docs/multi-tenancy-authentication explains about "Google Identity Kit" multi-tenant auth. So that's not a Firebase-only thing.
I'm trying to find a way to allow users to create and setup firebase project on their own google account from a client app, and get all their project information, urls and so on.
I took a look at the new project management api but can not figure out how to achieve this.
The management API currently does not support the creation of a new Google Cloud project. You are free to file a feature request for that, but it's worth pointing out that project creation is a complex issue and needs to be gated by abuse prevention measures.
You might also want to look into Google Cloud APIs for dealing with projects.
This is intentionally a very broad question. Sorry about that.
I'm experimenting with firebase for the first time. I would like to build a little e-commerce webapp using firebase, React and Next. I would like to split the App in two different apps: one admin app (used to create products and do other admin stuff) and the actual shop app. The Apps should be hosted on two different domains but they should talk to the same cloud firestore.
What would be a good setup to implement this architecture? Currently I am thinking about creating separate firebase projects for the admin and the shop app so I can host them on different domains. The cloud firestore would live in the admin project together with all admin related cloud functions etc. The shop app (or client app) would have its own project for hosting and would be connected to the firestore from the admin project.
Does that sound like a reasonable architecture or am I completely on the wrong path. Any suggestions are appreciated. And again sorry for the broadness of the question.
You don't need to do anything special. Each app (mobile, web,whatever) connects to a firebase instance/project. You can just set them all up to use the same firebase project (.plist file etc) and it will all work. The advantage of this design is that both admin and client access the same data, which presumably you need. (If you haven't found it, on the Firebase Console -> Settings -> Project Settings; add applications which will generate the appropriate credential files for each device type.)
Since you will have a shared/common authentication space, you may find that you want to add a flag/limitation to login so that only specified users can access the admin side. There's a few ways this can be accomplished.
>>>> BACKGROUND ON THE ISSUE <<<<
We were using Google Apps for Business when we started with the project. This allowed us to use the Google Developer Console (https://console.developers.google.com/) with our #company.co.za accounts and also to “login with Google” using our #company.co.za accounts. It turns out that the Google Developer Project (where the API keys are) was created using an ex-colleague's #company.co.za Google account.
When we moved from Google Apps for Business to Office 365, we lost the ability to login to the Google Developer Console with our #copany.co.za accounts. By then the colleague wasn’t working here anymore and I guess it all happened so quickly that we didn’t make sure to tie up all the loose ends.
Now we need to transfer development of the app and subsequently all related 3rd party projects and things, to the client for future development, but I cannot access the Google project.
This will require them to create a project on their side, generate new API keys for using the Google Maps API etc. And then update the apps (Android and iOS) with the new API keys.
>>>>> THIS IS MY QUESTION <<<<<
However, and this is where my question comes in, the apps are still working and happily accessing Google Maps. This makes me think that the project must still be somewhere.
I tried to access the Google Help pages, but because we're on a Bronze package, we can only find support information in their developer communities and online documentation listed here:
Join a Community
Service Disruption Notification
Best Practice Guides
But I thought to ask here too because SO is very reliable with answers :)
So, any idea if the project is still live somewhere? Or should we just create a new project with new API keys?
I don't think this is a stackoverflow question since it's not directly programming related. However, if you want to regain access to you project, this should be fairly simple and i hope this helps:
Create a new Google Apps for Business account with your domain (or maybe your old apps domain still exists?) and a single account. If you choose monthly payment the costs will be only a few bucks.
As the Google Apps domain administrator you should be able to access all appengine projects that belong to users of the same domain. If it doesn't you can contact Google support to reassign the projects. Alternatively: You may be able to recreate an account that owned the app. If you don't know the owner email, it is shown in the consent screent for oauth. With that email, try to access the project.
Create a Gmail account and transfer project ownership to this Gmail account
Delete the Google apps domain to avoid additional costs
All this is doable within an hour.
In case it doesn't work i would suggest you contact your Google sales representative or reseller and tell him, that you would like to purchase silver level support, but only if he can restore the permissions for you. This will cost you more, but if you have to access the project it may be the only way.
Last but not least:
You can contact Google support. You don't need silver level support for that. It will just take a lot longer to process your request. While in contact with the Google support you will have to prove that you are in fact the owner of the domain, which is usually done by adding a TXT record to your domain or uploading a file to your web server, so make sure you have access to your domain's DNS zone files / settings or web server document root.