When I try to add a swagger endpoint from my logic app it fails even though it successfully fetches the content.
Failed to fetch swagger with error message: Invalid response: {"openapi":"3.0.1","info":{"title":"My Swagger API"
...
...
...} Ensure you have CORS enabled on the endpoint and are calling a valid HTTPS endpoint.
I tried trouble-shooting CORS in every possible way, but in the end what got it working was forcing version 2.0 of swagger:
app.UseSwagger(o => o.SerializeAsV2 = true);
Has anyone gotten swagger 3.x to work with Logic Apps?
Okay, I have replicated the issue on my end and I have observed the same issue with the my open API.
The key word to notice here is "OpenAPI" specification. This is not a swagger specification. I found the official document which clearly says Swagger(not OpenAPI). Please refer Call REST endpoints by using Azure Logic Apps
You can try work around for this by creating custom connector
Related
I'm having difficulties on retrieving data from my server. I activated CORS and set up my call properly(already tested it with postman). I'm sending the post request to my server, method is being hit but when returning and trying to read the response on the client side, the SDK fails.
This is the error I'm getting on the console.
Am I missing something here? do I have to use another plugin for the htttp calls in web environment?
Error information is incomplete, in which line do you get error?
I assume your uri and some other thing are ok.
change filtereDto to:
Map<String,dynamic> filterDto={
'date':'2020-02-07....',
'countryId':'1' // string number
}
And you dont need to :
json.encode(filterDto)
in post call, only filterDto is enough
... body: filterDto ...
I have found the issue. Cors was being enabled on my server side incorrectly. Order activating Cors is critical for configurations to be applied properly in a .Net core app.
This is how is done. First activate Cors and then MVC.
Hope it helps anyone who is struggling with the same thing.
I have a swagger (Swashbuckle) enabled on one of my API controllers.
Server sits on http://192.168.7.119:1001 and Swagger UI is accessed through http://192.168.7.119:1001/swagger.
When connecting locally, everything is fine and I can access Swagger UI on port 1001 as expected.
But when trying connect throug proxy on port 1000 (which redirects 1000 to 1001), I get a well known error:
"Can't read from server. It may not have the appropriate access-control-origin settings".
I have read this:
Unable to access swagger despite cors enabled Asp.NET WebAPI
and tried to set the RootUrl manually in Startup file, within Swagger like this:
.EnableSwagger(c =>
{
c.RootUrl(req => #"http://192.168.7.119:1001";
...
});
CORS settings are set as:
appBuilder.UseCors(Microsoft.Owin.Cors.CorsOptions.AllowAll);
Any hints what am I doing wrong here?
Putting together this two pages from github repos of Swashbuckle the easy way to do what you're asking is:
From Github Make sure that your proxy is sending the X-Forwarded-* headers (Apache does it out of the box while Nginx doesn't seems so. You have to do some changes on the nginx conf.
From Github. Create this HttpRequestMessageExtensions static class with the ComputeHostAsSeenByOriginalClient method and then
.EnableSwagger(c =>
{
c.RootUrl(req => req.ComputeHostAsSeenByOriginalClient());
...
});
This C# code, with a proper access token (for scope drive.readonly) in the Authorization header, will work fine and return the file metadata in json format
_httpClient.GetAsync($"https://content.googleapis.com/drive/v3/files/{someDriveFileId}")
However this code (still with the same access token) will return a 403 :
_httpClient.GetAsync($"https://content.googleapis.com/drive/v3/files/{someDriveFileId}?alt=media")
And the following response html (exactly as returned) :
<html><title>Error 403 (Forbidden)!!1</title><a
href=//www.google.com/><span id=logo
aria-label=Google></span></a><p><b>403 Forbidden</b><p>Your client
does not have permission.\n
I've been using this code in production for years and it worked fine, so i suppose it's related to the recent changes at Google regarding the OAuth screens ?
I'm not sure what i should change here, or what i'm doing (now) wrong. Also the message seems a little sketchy for something made at Google, makes me think there is maybe an issue on their side ?
UPDATE:
Thanks to #Iamblichus for fixing the layout of my original answer. I'm newer to stackoverflow posting.
Even though the change in the original answer appears to be at the root of the problem, I found it difficult to use the troubleshooting steps to come to a working solution. I also was already passing the Authorization Bearer token solution, and that was not fixing my problem. After some trial and error the change I had to make was:
Broken GET URL:
https://content.googleapis.com/drive/v2/files/MY_FILE_ID?key=MY_KEY&alt=media&source=downloadUrl
Working GET URL:
https://www.googleapis.com/drive/v2/files/MY_FILE_ID?alt=media&source=downloadUrl
NOTE:
I am using v2 of the API, so you would need to update to url to v3 if using that.
In the file object I get from the google filepicker v2 API, I don't get back a single URL that supports the change made in authentication. I had to concat the file.selfLink string to make the new URL work
var url = file.selfLink + "?alt=media&source=downloadUrl";
ORIGINAL ANSWER:
Is it possible that https://cloud.google.com/blog/products/application-development/upcoming-changes-to-the-google-drive-api-and-google-picker-api is your problem?:
download calls to files.get, revisions.get and files.export endpoints which authenticate using the access token in the query parameter will no longer be supported.
Only requests that download media content (alt=media) are affected by this change.
The access token should be provided in the HTTP header, like Authorization: Bearer oauth2-token or, if that's not possible, follow the workarounds provided in the referenced documentation:
For file downloads, redirect to the webContentLink which will instruct the browser to download the content. If the application wants to display the file to the user, they can simply redirect to the alternateLink in v2 or webViewLink in v3.
For file exports, redirect to the export link in exportLinks with the desired mime type which will instruct the browser to download the content.
Reference:
Changes in authorization to Google Drive API
Authorization via HTTP header
v2 files get documentation
v3 files get documentation
This question already has an answer here:
Legacy People API has not been used in project
(1 answer)
Closed 1 year ago.
Google API is active but give error ;
Legacy People API has not been used in project before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/legacypeople.googleapis.com/overview?project= then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.
You don't need to install any other APIs like Google Drive API, Google Sheets API or other except Google+ API,
The error is coming because of "passport-google-oauth": "^1.0.0"
Just change the version "passport-google-oauth": "^1.0.0" to "passport-google-oauth": "^2.0.0" and remove node_modules and package.lock.json file and run "npm i"
That's it
Before the Google+ API Shutdown on March 7, 2019, the people.get and people.getOpenIdConnect methods were available for requesting a person’s profile.
To avoid breaking existing integrations with these methods supporting sign-in, a new minimal implementation only returns basic fields necessary for that functionality, such as name and email address, if authorized by the user. The Legacy People API is where these methods will remain available for existing callers at the existing HTTP endpoints.
The Legacy People API serves a limited new implementation of the legacy Google+ API people.get and people.getOpenIdConnect methods necessary for maintaining sign-in functionality. It is available to existing callers of the original methods that haven't migrated to recommended replacements such as Google Sign-in or Google People API at the time of the Google+ API shutdown.
enter link description here
Thanks
In this case, I'm facing the same issue. This is what I've done to fix it.
Situation:
NodeJS ver 8
"passport-google-oauth": "^1.0.0"
Using Google+ API as Google Sign-in
When I run the apps and click Sign in with Google, what happened then?
Server error
Error log: Legacy People API has not been used in project "xxxx" before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/legacypeople.googleapis.com/overview?project=xxxx then retry.
How I solve it?
Go to Google Console
Click on Google+ API under Social APIs, then click Enable API
Click on Google Drive API under G Suite, then click Enable API
Click on Google Sheets API under G Suite, then click Enable API
Update "passport-google-oauth": "^1.0.0" to "passport-google-oauth": "^2.0.0"
in package.json
remove package-lock.json and node_modules folder (to ensure everything is clear)
run this command : npm install
It works now!
Note: my previous code still using profile._json.image.url to get profile image. Actually, this response was not there anymore. So I delete this code.
Goodbye Google+
Thank you Google People API.
Enabling the Google Contacts API and the Google+ API fixed this issue for me.
Hi I recently stumbeled on the same issue. As explained by Ilan Laloum, Google+ API as been decommissionned completely for new projects.
I found that Google People API works in a similar way. The following example is based on the Bookshelf tutorial in GCP. Source code can be seen here: https://github.com/GoogleCloudPlatform/golang-samples/tree/appengine/go111/cloudsql/getting-started/bookshelf (branch appengine/go111/cloudsql)
import people "google.golang.org/api/people/v1"
...
// retrieves the profile of the user associated with the provided OAuth token
func fetchProfile(ctx context.Context, tok *oauth2.Token) (*people.Person, error) {
peopleService, err := people.NewService(ctx, option.WithTokenSource(bookshelf.OAuthConfig.TokenSource(ctx, tok)))
if err != nil {
return nil, err
}
return peopleService.People.Get("people/me").
PersonFields("names,coverPhotos,emailAddresses").
Do()
}
This method needs a context and a OAuth token, just like Google+ API used to. The peopleService is initialized in a similar fashion.
The peopleService.People.Get("people/me") prepares a query that fetches the profile of the connected user. Then PersonFields("names,coverPhotos,emailAddresses") is a filter on profile fields. This part of the request is mandatory. Eventually Do() will execute the request.
This issue can be fixed using the passport-google-token
npm install passport-google-token
const GoogleStrategy = require('passport-google-token').Strategy;
// Google OAuth Strategy
passport.use('googleToken', new GoogleStrategy({
clientID: CLIENT_ID,
clientSecret: CLIENT_SECRET
}, async (accessToken, refreshToken, profile, done) => {
try {
console.log('creating a new user')
const newUser = new User({
google: {
id: profile.id,
email: profile.emails[0].value
}
});
await newUser.save();
done(null, newUser);
} catch (error) {
done(error, false, error.message);
}
}));
I was also having the same issue but with my Rails app. So I resolved it by upgrading the omniauth gems by running bundle update devise omniauth omniauth-google-oauth2 in terminal.
I also faced the same issue. This issue may occur for using the old library, enable the google people Api for your project, and download the library as per your php version from this link and integrate it.
I am trying to wade my way through learning IdentityServer so that I can implement single sign-on at my workplace. I have a POC service running locally and when I request the configuration, this is the configuration that displays:
{"issuer":"https://localhost:44345/core","jwks_uri":"https://localhost:44345/core/.well-known/jwks","authorization_endpoint":"https://localhost:44345/core/connect/authorize","token_endpoint":"https://localhost:44345/core/connect/token","userinfo_endpoint":"https://localhost:44345/core/connect/userinfo","end_session_endpoint":"https://localhost:44345/core/connect/endsession","check_session_iframe":"https://localhost:44345/core/connect/checksession","revocation_endpoint":"https://localhost:44345/core/connect/revocation","introspection_endpoint":"https://localhost:44345/core/connect/introspect","frontchannel_logout_supported":true,"frontchannel_logout_session_supported":true,"scopes_supported":["openid","profile","email","roles","offline_access"],"claims_supported":["sub","name","family_name","given_name","middle_name","nickname","preferred_username","profile","picture","website","gender","birthdate","zoneinfo","locale","updated_at","email","email_verified","role"],"response_types_supported":["code","token","id_token","id_token token","code id_token","code token","code id_token token"],"response_modes_supported":["form_post","query","fragment"],"grant_types_supported":["authorization_code","client_credentials","password","refresh_token","implicit"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256"],"code_challenge_methods_supported":["plain","S256"],"token_endpoint_auth_methods_supported":["client_secret_post","client_secret_basic"]}
As part of this, you can see:
"response_types_supported":["code","token","id_token","id_token token","code id_token","code token","code id_token token"]
However, when I send a request to the service, with responseType=id_token in the url, I get the error message:
The authorization server does not support the requested response type.
I have tried other responseType values but still get this error message.
I am basically a beginner at web security and IdentityServer, so I am sure I am missing something very basic.
This is pretty stupid. All of the examples online I have looked at for IdentityServer show the parameter as responseTypes (camel case). I think these examples must have all been done against an older version of the platform.
The correct parameter name to send is response_types.
The list of possible parameters that you can send to the authorization endpoint are listed on the following websites :
OpenId RFC : http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
Identity server doc : https://identityserver.github.io/Documentation/docsv2/endpoints/authorization.html
The correct parameter is "response_type" and not "response_types" :)