Google Cloud Platform SDK Authentication - How to deal with Environment Variables and a changing config file on your MX file system?
Hi All, For a project, we are currently implementing several Google Cloud Platform services. Because the authentication and use cases are quite complex, we decided to build connectors by using the Google SDKs. I will try to explain our challenge as brief as possible. In order to authenticate to the Google Cloud Plaform, Google asks you to download a credentials file (json) and place this somewhere on your file system. After that, you need to set a Environment Variable (GOOGLE_APPLICATION_CREDENTIALS) in which you set the path to this JSON. Because we want to change the credential file whenever we need to, we decided to use the temp folder. Working locally, this solution works when we set the path to the exact location of the file. We can use a fixed filename, but according to the documentation, the temp folder path may change. In Java, we can use the Mendix SDK to retrieve the current temp folder path. As of my knowledge, we kan not use parameters when setting the Environment Variable. DOCS: https://cloud.google.com/docs/authentication/production Questions: Is using the temp folder the really the only option if we need to write to the file during runtime? If so, is it safe to use this folder for storing credentials? Can we use variables when we set the GOOGLE_APPLICATION_CREDENTIALS Environment Variable? Is there another solution to pass the credentials in every scenario ad-hoc from a regular Mendix file document? As you can see; quite some questions! Hopefully someone at the forum has some experience with the implementation of Google services in to their app. Happy to hear your thoughts. Best, Jeroen
Jeroen Appel ⛺
Since the setup with the temp folder already works I would use the temp folder option. Use an after startup action to check if the file still exists in the current temp folder and otherwise create a new one. So do have a filedocument with the right JSON in case that the file is missing. I have never seen an environment where the temp location changed but with this method it is in my opinion pretty fail safe.