I have tried searching the info regarding applications on GAE within same domain talking to each other but so far I don't have any luck. There was a post here but I don't know if that answer is correct.
You could also run the two different "apps" as different versions of the same appid. Then they share the datastore. Also, urlfetch.fetch() calls to paths of the same app are treated specially, they are faster and don't require authentication (they count as if they are logged in as admin).
I believe you will be best served by exposing a REST API for both your applications, so that they can read/write information as needed.
For e.g. If one of your apps is an Invoicing App and the other app needs only read access to Invoices, you can expose an API in the Invoice App for:
searching invoices by some filter
providing the Invoice detail, given an Invoice ID
Exposing an API will keep the applications loosely coupled with each other and will allow you to enhance the API as more requirements emerge. In the future, you can even have other clients like a mobile app access the API.
Related
I have spent 3 days researching this problem and cannot find a solution or similar use case that shows how to solve the problem, so any pointers would be greatly appreciated.
I am creating a web-app that uses Google Cloud Storage and Bigquery. A user registers on the web app and then can upload data to Cloud Storage and Big Query. Two users could be from the same company and therefore should be able to view the same data - i.e. Jack and Jill work for company A and if Jack uploads a massive dataset via this app, Jill should also be able to view it later.
Another scenario will be I have two completely separate clients with users using this web-app. If users from Company A upload data, users from Company B should not be able to view Company A's data, and vice versa. But users from the same company should be able to view the data within their company.
Currently, I have an app that works for a single company. This has a React front-end that uses Firebase for authentication. Once the user is logged in, they can use the app which sends off API calls to a Flask back-end that does some error checking and authentication checking and then fires off an API call to GCP. This uses a service account and the key is loaded as an environment variable in the environment in which the Flask app is running.
However, if Company B want to use the app now, both Company A and Company B will be able to see each other's data and visualize it through the app. In addition, they will be sharing a project (I would like to change this to allocate billing more easily to have each client have their own project).
I ultimately want to get this app onto Kubernetes and ensure that each company is independent of each other, however, do not want to have to have separate URL's for every company using the app. Also, I want to abstract GCP away from the client. I would prefer to authenticate a user based on their login credentials and then they will be given access to their GCP project (via my front-end) accordingly.
I thought about perhaps having separate service keys for each client and then storing the service key info in Firebase, while using the respective keys for API calls but not sure this is best practice. It is however the only strategy I can think of.
If anyone could provide some help or guidance it would be very much appreciated. This is my first GCP project and have not been able to find any answers on GCP, SO, Google Groups, Slack or Medium.
Thanks,
TJ
First if all, welcome on GCP! It's an awesome platform, very powerful and flexible. But not magic.
Indeed, the use case that you describe is specific to your business logic. GCP provides told for securing access for user and VM(through service account) but not for customer. Here you have to implement your own custom and authorisation logic, with a database (I don't recommend bigquery for website, the latency is too high) to list three users, the companies where they work, the blobs of each company...
Nothing is magic and your use case specific.
If you want to discuss more about which component to use and to start, no problem. Let a comment.
I am in process of designing a SaaS application over PaaS (Google App Engine).
My SaaS will have two user interfaces:
Web Based
Mobile App based
Web based would be feature-rich whereas Mobile app would have essential and/or frequently used features.
Mobile app would invoke RESTful services to perform business logic.
This SaaS would target mainly individuals using Mobile Apps; however, there could a use-case wherein these individuals could form a group and operate as a company.
So with that in mind, I am considering two entities: Account (Tenant) and User.
I am considering having many-to-many relationship between these two entities as one user could be part of multiple Accounts (unlikely but can’t be ruled out) and of course, one account can have multiple users.
I would like to know the best practices for authentication under such scenario:
Should I use Google's provided Authentication or should I implement my own authentication? (I am still exploring OAuth and Google's authentication offering.)
I think, for web-based interface, username/password over SSL would suffice. But, not sure, can this be applied to mobile app?
Can I avoid a situation wherein I have to store credentials in mobile app?
Thanks in advance for any help you can provide on this.
A
Having just completed my first project using Google App Engine, I can say that I ran into alot of the questions that you have. I'll try to explain my approach to each point and also approach it from your perspective as well.
Authentication - Generally using Google's auth would be the easiest route, but you would still have to implement a custom adaptation in order to work with the "company"/"group" concept. Implement in the datastore/whatever database you prefer to use an entity called "Groups" which have a list of google users... this way users can belong to many groups.. then you just search by property (user) to get all groups they belong to. I implemented my own authentication system for unrelated reasons.
Google App Engine comes with SSL/HTTPS support for its own domains. You can add in your own custom domain with SSL support as well. You can use SSL through native apps or mobile web apps additionally. I simply used the native support that came with it.
Yes and no. You will always have to store the credentials somewhere. Maybe it wont be in your apps code/directly connected to your app (Google auth would be an example). But somewhere, on your phone, the credentials WILL reside. They may be encrypted/obfuscated, but they will be there. So either have your user enter them in everytime, or save them/use the ones provided by the phone. For myself, .NET provided a nice way of storing credentials in a secure fashion (non-plain-text) for each user's machine.
I have been used the Google App Engine for multiple hobby projects and I have even published a few of them and setup associated domains with moderate success. Of the few, one of those apps even uses sub-domain mapping.
In spite of the multiple setup attempts, I have still had a bit of difficulty setting up my domains for new projects and I've had to cross-reference multiple help articles (many found on SO). Some times those solutions, however, are close to what I've needed because of setup mistakes or variations in my application.
Even with a bit of experience, it still feels like I'm hacking the domain implementation together because there is no good start-to-finish setup for a GAE application that involves creating the necessary Google Apps application, the App engine application, domain registration and DNS setup.
So, could someone please offer a very high-level walk-through of setting up a GAE application from start to finish with the following requirements.
Requirements
A domain should point to the GAE application
The application should allow for sub-domain integration, pointing to different application handlers.
Can dynamic sub-domains be easily handled in the application? If so, what must you do in the setup process to assure that all requests to your domain are forwarded to the GAE app?
Forward "Naked" domain requests are forwarded to the right place. (There are multiple response to this requirement. What is the best approach to solving this requirement.)
If you must create a Google Apps application, when should it be created? Include this in the instruction list at the appropriate place.
Again, many of the above requirements have been asked on many forums, including this one. Usually it comes from someone who is in the middle of a problem setting up there domain with their application. Some of these requirements can be easily fulfilled if certain "gotchas" are avoided in the early stages of setup or application requirements are slightly modified to work around (or with) the limitations of the GAE.
In a nutshell, what I'm looking for is a very simple, straight forward response that provides a list of steps should be followed in order to setup a domain with a GAE application.
Thanks gurus.
All of the steps are independent - setting up a Google Apps account is the same whether you're going to add an App Engine app to it or not - except mapping the domain, which is documented here. Domain registration and DNS setup depends on your registrar, so it's not possible to write a universal guide to those. Handling subdomains in your app, meanwhile, is something that's not App Engine specific - it's just standard WSGI (or Servlets, depending on language).
Is it possible to make invitations to share/view data similar to Google Docs?
Definitely: GAE is a platform, a canvas for what you want to build. Document access management is entirely up to you, but of course you'll have access to some APIs to facilitate your life (e.g. Google Accounts integration).
Of course it is. You can create virtually any kind of web application that you want with AppEngine. It doesn't come with anything built-in to do this other than an API for sending emails, but you can certainly code up this functionality.
Is that somehow possible to access one datastore? Or access one app from different domains.
App Engine recently add support for a feature called modules (Docs: go, python, java)
App Engine Modules (or just "Modules" hereafter) is a feature that lets developers factor large applications into logical components that can share stateful services and communicate in a secure fashion. An app that handles customer requests might include separate modules to handle other tasks:
API requests from mobile devices
Internal, admin-like requests
Backend processing such as billing pipelines and data analysis
When you create a new module, App Engine will create a url that corresponds to the module name. If you only have one module then the name will be default. e.g.
http://default.myapp.appspot.com
http://mobile‑frontend.myapp.appspot.com
http://my-module.myapp.appspot.com
Using Domain masking, you could then direct from:
www.myapp.com => http://default.myapp.appspot.com
www.myapp-mobile.com => http://mobile‑frontend.myapp.appspot.com
www.example.com => http://my-module.myapp.appspot.com
Every app has its own datastore and memcache (shared among all versions of that app).
It seems not possible to share datastores between applications right now (unless you provide some web service for that), but that would be a nice feature to have, so maybe you should file a feature request with Google vote for it.
As for domains, you can associate your app with domains managed by Google Apps. Multiple domains for the same application should be no problem (except for SSL certificates).
Every version of an app is backed by the same datastore. If you want to limit access for individual requests, you'll need to add a field to your model to enforce that restriction. There are low level hooks in the datastore API for this sort of thing, if you want to go that far.
And yes, you can add a single App Engine app to multiple domains - even in multiple Apps accounts.
Kyle's solution would work, but App Engine was never designed to be used in this way. So if you architect your app(s) to rely on this kind of setup and Google clamps down for whatever reason then you'd be screwed.
You can have multitenancy using the Namespace Java API