I'm trying to authenticate to Firebase Firestore on a C# WebAPi 2 hosted in Azure.
According to the docs, it's as easy as:
Otherwise, the simplest way of authenticating your API calls is to
download a service account JSON file then set the
GOOGLE_APPLICATION_CREDENTIALS environment variable to refer to it.
The credentials will automatically be used to authenticate. See the
Getting Started With Authentication guide for more details.
This works locally on my machine but I can't seem to find a way how to set this environment variable in a Azure WebApp?
As Junnas mentioned you can set the App settings, which will act as environment variables.
(source: windows.net)
In Asp.Net 5 there is a build in
Configuration = new Configuration()
.AddJsonFile("config.json")
.AddEnvironmentVariables();
Read this blog and this SO
You can find all the predefined environment variables at below link,
https://<yoursitename>.scm.azurewebsites.net/Env.cshtml
Related
I had my app previously deployed on Vercel, but since I'm using Azure AD and MongoDB on Azure, I'm moving the hosting of my app to Azure as well for decreased networking delays.
I set all my environment variables under Configuration -> Application Settings in the Production environment. The private variables (e.g. client secrets) are perfectly readable by my Next.js back-end, but my front-end cannot read the environment variables prefixed by NEXT_PUBLIC, even though this previously worked in my other projects on Vercel and Google Cloud Platform.
Printing the public environment variables (NEXT_PUBLIC_*) to the console returns undefined.
How do I make a distinction between full-stack and server-side environment variables? Because NEXT_PUBLIC does not seem to work.
I found a workaround. Under the build_and_deploy_job -> steps, add a field named env. Under this, you can place your environment variables like this:
env:
NEXT_PUBLIC_VARIABLE: "value1"
NEXT_PUBLIC_ANOTHER_VARIABLE: "value2"
You can find my full .yml file here.
I want to express the fact that this is a suboptimal solution and for the multi-billion dollar company that Microsoft is, you should be able to place public/client-side environment variables directly in your Static Web App via the Azure web portal.
I am trying to set up the development environment for a project that uses an API hosted in GCP. We are using the Google Auth Library: Node.js Client, and it tries to pull an ID token automatically, and fails. This is the error:
Error: Cannot fetch ID token in this environment, use GCE or set the GOOGLE_APPLICATION_CREDENTIALS environment variable to a service account credentials JSON file.
So, I've solved this by manually downloading a service account key and pointing the GOOGLE_APPLICATION_CREDENTIALS environment variable to it. However, when more developers start to work on this project, it would be great to have a somewhat more automatic or streamlined solution.
I've been reading around, and was hoping that setting the GOOGLE_APPLICATION_CREDENTIALS to the key file generated by gcloud auth application-default login would do the trick. But, it seems like the library doesn't work with user credentials? At least it doesn't work when I try it.
Having a way where the developer setting up the project in development would either simply authenticate with Google in the terminal, or point the GOOGLE_APPLICATION_CREDENTIALS to a file generated by a gcloud command would be great, instead of having the person go into GCP to download a service account key.
Is this possible somehow? It's been a little tricky to find out. Thanks!
Some other questions I've seen:
Local development without using google service account key
Could not load the default credentials? (Node.js Google Compute Engine tutorial)
I have a .Net Core 3.1 Web Api App which is being built with an Azure build pipeline using MSBuild and being deployed to its various environments using Azure Release Pipeline. I want the Git Commit ID to be available to the Web App so I can read it and attach it as a response header on outgoing responses.
I know there's a predefined build variable called Build.SourceVersion which gives the commit ID so that's not the issue. Also I'm not questioning how to attach it as a response header as I can find that information online with more research. What is puzzling me is that I don't know how to make this information available once the Web App is deployed so I can read it or how to read it. Should I add a powershell script in the build process to add the environment variable? Is that even the correct place? Should it be instead part of the release pipeline?
Also I know there is a predefined Release variable called Release.Artifacts.{alias}.SourceVersion . How would I have this available as a environment variable to be read in code once app is deployed? How would I read it in code?
Any help is appreciated. Also, I would be happy to provide more details!
I am trying to integrate KeyVault into my Azure App service. I have a KeyVault client library embedded in my application. In order for this client library to connect to KeyVault and access stored secrets, some configurations must be available for the client to connect. There are 4 types of credential objects that the client attempts to use, in a specific order, during initialization for authentication/authorization. The first credential object it tries to use is an environment based object. This object attempts to gather 4 environment variables from the hosting system to initialize the KeyVault client. One of these variables must contain the ClientSecret of the application trying to connect to KeyVault via the client lib. The problem I am running into is this. In my azure release pipeline I am trying to set the environment variables of the deployed host appropriately for the application to use. However, it appears that the release tasks all run on the same host, until you get to the actual deployment task of the app service. Apparently this task runs on a different host? When running the hostname command on previous tasks they all returned one hostname while the hostname command added to the deployment task returned a another. I am a little stuck and having trouble finding more clarity about setting environment variables for an app service through documentation. Does anyone have any ideas? Am I going about integrating KeyVault correctly or is there something I am missing? Please let me know if clarification is needed or more information is required to assist me. Thank you very much.
If you are using Azure App Services, this is way easier. You directly link application configuration from KeyVault using Managed Identities.
Sample config value will look like this:
#Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/ec96f02080254f109c51a1f14cdb1931)
This way you
don't have to change anything in your application code. The app reads
secrets from KeyVault just like any other configuration
do not need to manage any client-side credentials to access KeyVault.
You need to create the Variables in your Pipeline and retrieve them (from Key Vault), during the release process.
PS: Your app will receive/read them as Environment Variables.
Azure DevOps Variable Group not applying in Azure Function Configuration
I have an ASP.NET Core (RC1) app running on Azure App Service. The app takes its configuration from environment variables. I currently use the Azure Portal's 'Application Settings' page to set these environment variables. The app is deployed with Kudu (if this is relevant?)
I would like a way to programmatically set these environment variables so that I don't have to go through the Azure Portal every time I want to create a new environment variable or modify an existing environment variable. Ideally I would like to do this by calling a REST API. Is this possible, and if so, how?
Instead of setting environment variables in the Azure Portal, you could deploy an appsettings.json file along with your app with the desired settings. If you have a build server or deployment server, you could transform the config file with the correct settings for your environment.
If you i.e. are using Octopus Deploy for deployments, you could use the JSON Configuration variables feature to handle this.
http://docs.octopusdeploy.com/display/OD/JSON+Configuration+Variables+Feature