I need to create a development Google OAuth 2.0 Client ID for my app. I see that you cannot have an origin of http in the list of allowed origins. The error states...
Invalid Origin: This app has a publishing status of "In production".
URI must use https:// as the scheme.
So it seems I need to create a 'development app' so it can have its own OAuth key. However, I am finding it confusing on how to do this.
In my view I can see my org and what I think is a "Project". I can add another project, but I am thinking there should be a way to add an "App" to my existing project.
I think the hierarchy goes Org -> Projects -> Apps correct?
Where does one add a new App?
It is true that any app that has been set to production and has been verified can not have a redirect uri that is not https Redirect URI validation rules
You can create a new project on [https://console.cloud.google.com/apis/dashboard] for development.
Google says that for apps in production, redirect URIs must use the https scheme, not plain http. It seems however that localhost IP address URIs are exempt from this rule.
If you just need to create a new OAuth 2.0 Client ID, go to Projects -> /your app/ -> APIs & Services -> Credentials.
Over there, choose Create New Credential, then choose OAuth Client ID (depending on your use case).
Then you will be asked for the id/package-name of your app you want to create a Oauth client id for.
Otherwise you can always create a new project.
OAuthClient
The way you add an "app" really depends on how that application is implemented. You are correct that organizations have projects, but projects don't really have "apps," they have resources.
In this organizational hierarchy, the idea is that you either add a virtual machine, or a kubernetes cluster, or a cloud function, depending on whether you're using Google Compute Engine, Google Kubernetes Engine, or Cloud Functions, respectively (or anything else).
If you were using Google Compute Engine to implement your web application, for instance, you would add the virtual machine to your project (either via the web interface or the gcloud command-line interface), and then you'd configure a web server to handle incoming requests at whatever address you wanted for the OAuth webhook.
Again though, the main point is that you don't really add "apps", you add resources, so it really depends on how you're going to be implementing your web application. In short, however, you do not need to create another project. That would just bring you back to square one :)
Related
Assume that there is an application, SPA, that uses Google OAuth2.0 to access the Google Drive API.
Reading the docs, the application flow seems familiar enough on the client-side specially with Google's JavaScript library for authentication. However, I have stumbled upon a roadblock during application registration phase.
When creating the credentials for our client application, I am redirected to fill out the form at the OAuth Consent Screen first. There, among other things it demands us to declare whether the application is in Testing or In Production phase, so it can decide whether the app will be available to everyone or to Test Users only.
Assume I create a project for our application and set it on testing at first and then change it to production once I am ready to publish (with a new set of credentials as well).
My question is this. What if development continues on the application for new features while one instance of the app is in production? During development and testing I would need to restrict the application to my Test Users alone. Since the OAuth consent screen is project specific, not credential specific, will I require multiple projects on the console for every environment in which the application is running?
As in,
Project MyAppTesting will permanently remain in testing mode and will denote our development/testing branch.
Project MyAppProduction is always in production and denotes my production branch.
Similarly for the mobile client:
A MyMobileAppDev project having credentials configured with the debug keystore hash
A MyMobileAppProd project having credentials configured with the production keystore hash.
(both sets of credentials share the same package name).
Is this the idiomatic way? I failed to find any documentation on the matter. Please advise.
What #JohnHanley stated is the best way and the best practice when deploying application/s in GCP.
You can create multiple projects and create different Oauth for each of the projects. Check out this link on service accounts.
In addition to that, there are also some pros and cons when it comes to billing.
Pros:
Users consider having multiple billing accounts with respective projects assigned for each account to be able to see their billing details separately. In this way you can monitor the billing for each of the respective projects for each account.
Cons:
Attaching all the projects to one billing account, however, the billing reports will show all of the sum of the cost for all the projects, but you can still use the filter menu to be able to see the charges for each project.
I am running several gcloud services which have assigned urls automatically in following format:
https://SERVICE_NAME-XXXXXXX-ew.a.run.app/
This is not particularly easy to work with and to pass these URLs to clients. Alternative is to use the custom domain, but this needs hardcoding subdomains within DNS records (as far as I understand) and I would like to avoid that and use the default URLs.
What is the best practice to work with these URLs? I can imagine keeping some mapping of service->URL and passing it to clients, but I would like to avoid reinventing the wheels.
Edit: I've released an external tool called runsd that lets you do this. Check it out: https://github.com/ahmetb/runsd
Thanks for this question! The "Service discovery by name" for Cloud Run is very much an active area of work. Though, there are no active timelines we can share yet.
You can see a prototype of me running this on Cloud Run here: https://twitter.com/ahmetb/status/1233147619834118144
APIs like Google Cloud Service Directory linked are geared more towards custom/DIY service discovery you might want to build to your RPC stack such as gRPC. It's more of a managed domain name directory, that you can integrate with your RPC.
If you are interested in participating an alpha for this feature in the future, drop me an email at ahmetb at google.
You can use a beta service Service Directory.
At service deployment
Create your service with a name and the URL as metadata
In your code
Request the service metadata with its name, and get the URL
Use the url
You can't use the endpoint feature of the service because your don't have IP/Port.
However, for now, there is client library and you have to use API directly.
Essentially, I'm wanting to create an Oauth Client as an App so I can get data from Dynamics for multiple customers. Does anyone know if this is possible to do in AppSource or do you know of another way?
I have a service that will be served in a cloud different than Azure so there really isn't anything for me to submit as an App and I really don't want every customer to have to setup their own App that gives my service the privileges/access it needs, but it's looking like I may have to.
It sounds like you'll want to register an app with Azure AD (the OAuth2.0 service/identity provider for work and school accounts), and create a multi-tenant app. Then you can configure this app in the Azure Portal to get permissions to the APIs the app wants tokens to call (in your case Dynamics or the Microsoft Graph).
Once this app is written, you can code up your app using one of the Azure AD Auth Libraries. Here's some sample code for a .NET web API. You can find more code samples on Github and search active directory. Moreover, the Azure Active Directory Developer Landing Page is a great place to look for more resources on doing all of this.
I have recently inherited a Web API development that exposes key endpoints to a company that is hosting and running our website.
We use Octopus to deploy the API to our webserver.
I have duplicated the API and added the appropriate configuration variable to Octopus and deployed it to a secondary webserver (as a development API) for our 3rd party to use.
We are using identity server along with OpenID connect for authentication.
This has built and deployed however authentication is failing.
I know this is a vague description, but I am looking for pointers for an analysis path.
I have compared the logs of the current Api and the test Api and results are the same. (Stating authentication is successful)
Not really enough information to properly answer this question - but I would start by:
1) Checking all the log files you can find for a more detailed exception message. (application logs, IIS logs, event log)
2) Try to narrow down the issue. Does authentication fail for everyone/all the time? Or is this an issue intermittent? Does it work locally? For certain providers only?
3) Slowly start making the new website look like the old website. Comparing web.config files, copy/pasting the old website code onto the new server etc.
4) Check or restore old service accounts, firewall settings, database values, urls etc.
If all else fails - bring everything back to a working state and start changing one thing at a time until you have a little more experience with the application.
I am using Axis2 (1.5.3 currently) and Tomcat (6.0.26 currently) and am running a web service. I would like to also host HTML pages for configuring the web service.
What is the best way to go about this? I assume keeping the same context is key, but perhaps it is not.
My current distribution is located under a folder structure similar to this:
Tomcat/webapps/mycompany
With the actual service code here:
Tomcat/webapps/mycompany/WEB-INF/services/myService
In a browser, I can hit my web service by going to here:
/mycompany/services/myService
I note that I can drop actual HTML files in this path and Tomcat will, indeed serve them up.
For instance, if I put "index.html" under Tomcat/webapps/mycompany, I can navigate to /mycompany/index.html and see my html.
What I want to do is have this HTML be attached to JAR/class files that can interact with the already-existing service class files in the same context as the service. Therefore, I can have the browser configure the web service directly.
Is this possible, and is there a tutorial or something out there that will help me with this? Note that I have been working with Tomcat and Axis2 for a while now for this particular web service, but I have never actually deployed a web application/html using Tomcat before.
Thanks.
First of all what do you mean by a configuring a service. Normally in SOA world services are analogous to interfaces. IMHO you can just change a service, since their are other users that rely on the services you are exposing.
If i want to change a service i would rather introduce a new version of the service after deprecating the existing one.
Are you talking about applying QoS to existing serviecs. Then that makes sense.
Anyway, If you want to have a web-app alongside with axis2 service engine, it is possible. If you look inside the axis2 war file you'll find the web.xml entry to Axis2Servlet. It is this servlet that serves the web services requests.
So, what you need is the Axis2Servlet mapping in your web-app along with your usual servlet-mappings. Number of possible ways to configure your services using web-app files. One options is to use web-services call itself to (with authentication) to configure it.
By "configure a service", take this example:
The service has a set of datasets.
Each dataset exists in a separate database.
The service can manage 0..n datasets.
The service must be configured to know about each dataset.
This is what I'm configuring. I'm not trying to configure Axis itself or redefine the service.
I would like to host the HTML using the same instance of Tomcat that I'm hosting the web service with. It needs to manage sessions, have login capability, an whatnot, and has to be able to configure the web service live.
From what I'm reading, it's probably best to make an interface to the web service that the web application module can call into from a different context.
Is there a better way?