I have an JAX-RS application running on IBM Websphere Liberty Profile.
Also I have included SWAGGER 1.5.3.
The application compiles fine and generates swagger files in webapp directory. But when I try to access it via URL, it says NO API FOUND and the spinner keep spinning.
There are no errors registered on browser console neither any errors in server console.
I do not know whats wrong with it, without any errors its hard to debug.
Where can I see the detailed errors/exceptions.
WebSphere Liberty has native support for Swagger v2 using the apiDiscovery-1.0 feature. If you enable that you should see your APIs in https://host:https_port/ibm/api/docs.
By the way, there's support for the newer OpenAPI v3 spec, via the Microprofile OpenAPI programming model. You can use Liberty's mpOpenAPI-1.0 feature for that.
I've just pulled down the latest Swagger from the Git repo (3.0.19) using: https://github.com/swagger-api/swagger-ui.git and updated my API to use the new version.
Ran git describe --tags to confirm and my version is currently: v3.0.19-6-gaab1403
The problem I'm having is one described here, whereby my response is a 403 (I can see this in the inspector on the browser) and although I have a reponse for error 403, I still get the TypeError: Failed to fetch message.
Here's a snippet from my definition regarding the 403 response:
"403": {
"description": "Forbidden",
"headers": {
"Access-Control-Allow-Origin": {
"type": "string"
}
}
},
I've also noticed it reported here however, I know it's not a CORS issue as I have tested the endpoints and the OPTIONS are returning correct, as are the endpoints if called with valid information (I force this 403).
Could anyone point me in the right direction please?
Update: I have since tested on a 401 response, with the same response.
And that a 400 is working as expected:
For anyone that runs into this problem;
After a day of troubleshooting and the Swagger support guys pointing me in the right direction, it turns out that this is currently caused by a bug within the AWS API Gateway custom authorizers.
We are currently using AWS API Gateway for managing our APIs, this includes managing all our authorization via a custom authorizer. The issue is that custom authorizers do not currently support passing through headers within the response and Swagger UI needs the Access-Control-Allow-Origin:* within the response header(s) to display the correct HTTP status code.
See this AWS thread regarding the issue (which is older than a year already):
https://forums.aws.amazon.com/thread.jspa?messageID=728839
Swagger UI discussion on same: https://github.com/swagger-api/swagger-ui/issues/3403
EDIT / UPDATE
This has since been resolved with the use of Gateway Responses. See this same forum (page 2):
https://forums.aws.amazon.com/thread.jspa?messageID=728839
I hit this error during local development (i.e., had nothing to do with AWS). The underlying cause (CORS violation) is identical. The following might help others who encounter this problem.
I setup connexion with an openapi spec that referred to http://localhost:9090/. When the development server starts, it says "Running on http://0.0.0.0:9090/". That page appears to work, but the swagger ui uses http://localhost:9090/ from the openapi spec for subsequent requests and shows TypeError: Failed to fetch in results. The browser console shows Access to fetch at 'http://localhost:9090/vr/variation' from origin 'http://0.0.0.0:9090'. The provided curl command worked fine; although initially confusing, the curl success is a clue that the problem is due to browser blocking rather than server-side failure.
(Connexion is based on Python flask and provides extended support for openapi integration.)
I had the same issue and there was a very simple fix. I accessed my site using HTTP but it required HTTPS. My site was redirecting to HTTPS when calling an endpoint.
This violated the "same-origin policy":
https://learn.microsoft.com/en-us/aspnet/core/security/cors?view=aspnetcore-2.2
Disclaimer:- This answer is for APIs developed using Asp.net Core
I have faced similar issue when trying to access the APIs from the Swagger UI Editor.
I was trying to access some APIs developed using Asp.net Core where as the Swagger UI Editor was hosted on Apache. I was facing CORS (Cross Orgin Request).
I have to modify my APIs code to allow CORS request using following code:-
Declare within Startup.cs File having class "StartupShutdownHandler"
private readonly string MyAllowSpecificOrigins = "_myAllowSpecificOrigins";
Added a section of code within ConfigureServices Method.
var str = ConfigurationHandler.GetSection<string>(StringConstants.AppSettingsKeys.CORSWhitelistedURL);
if (!string.IsNullOrEmpty(str))
{
services.AddCors(options =>
{
options.AddPolicy(MyAllowSpecificOrigins,
builder =>
{
builder.WithOrigins(str);
});
});
}
Added a line of code within Configure Method.
app.UseCors(MyAllowSpecificOrigins);
Reference Enable Cross-Origin Requests (CORS) in ASP.NET Core
Because the problem of cross-origin means your website is hosted on either locally or with port 8000 or different port, and your swagger's port number is different, so this problem is genuine. We can fix it by giving permission.
Here is the node code:
app.use( (request, response, next) => {
response.header("Access-Control-Allow-Origin", "*");
response.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
next();
});
We can solve by using CORS npm as well.
https://www.npmjs.com/package/cors
Please check the swaggerOptions provided to swagger jsdoc and check whether host and base name is correct. I have encountered the same issue before and got fixed the issue by correcting this. Hope this will also solve the problem.
Eg:
const options = {
swagger: "2.0",
swaggerDefinition: {
// options.swaggerDefinition could be also options.definition
info: {
title: "Customer API", // Title (required)
description: "Dummy Customer API for implementing swagger",
contact: {
name: "Stack Overflow"
},
version: "1.0.0" // Version (required)
},
host: "localhost:5000",
basePath: "/"
},
// Path to the API docs
apis: ["SwaggerImplementation/index.js"] // For complex api's pass something like apis: ["./routes/*.js"]
};
I have encountered the same error while trying to authenticate access OAuth2 secured Rest API set. API server deployed on VM and was connecting to it using IPSEC VPN. Actually username/password in HTTP header with basic authentication was sent using separate API other than /oauth/token, backend itself was calling http://localhost:8080/api/v0/oauth/token with client secret and returning back token to client. After changing localhost to server's actual local IP , problem disappeared.
This error is generic on swagger side and could be due to many possible reasons.
In my case, it was due to connection error. My swagger page was not responsive due to connection issue at my side. I had to refresh it once and worked for me.
If it's a .NET Core API, try commenting out the below method call in the StartUp.cs
Like below,
// app.UseHttpsRedirection();
It's because some times your IIS Binding's HTTPS SSL Certificate will automatically goes to Not Selected. So again you haveThere was a similar question raised and there are few good answers Please refer this link to manually selectget the SSL Certificates to1 IIS Express Development Certificate1. Below I have mention how to doanswer:
Open IIS Click Default web sites.
In the right side corner you will see a some setting click "Bindings", you will get a Site Binding window.
Then you will get http and https details.
In that Click "https" and click edit, then you will get another window Edit Site Bindings.
In that window check SSL Certificates.
If SSL Certificate = Not Selected select IIS Express Development Certificate.
Then stop and Start the IIS.
Issue will be solved.
Below article might help.
I was facing same issue when from Swagger ui calling API Gateway which further calls Lambda function using proxy integration (which passes response headers from lambda). In my case I missed to set response headers Access-Control-Allow-Origin in Spring boot app lambda handler response-event object APIGatewayProxyResponseEvent. After setting this header in handler class, Swagger UI was able to call api gateway. See
https://fanchenbao.medium.com/thanks-for-the-article-it-is-a-great-way-to-get-started-with-deploying-swagger-ui-on-s3-7990c7b48851
you can use modheader extension in order to fix it
For .NET Core 2.1 or above
In Startup or Program, register configuration to IApplicationBuilder to
app.UseCors("AllowAll");
Every solution will definitely be correct :)
But in my case I have that line in my webconfig file
<environmentVariable name="ASPNETCORE_HTTPS_PORT" value="5001" />
I just replace ASPNETCORE_HTTPS_PORT to ASPNETCORE_HTTP_PORT and the error has been gone :). So the final line is
<environmentVariable name="ASPNETCORE_HTTP_PORT" value="5001" />
replace 5001 with your port.
How can i set a path prefix for scdf UI. I already set the tomcat property (like server.contextPath=/api/) which works for the rest API but the UI is still giving errors.
Info: i have it running in Kubernetes using ingress.
We do not support GUI redirects with a overridden contextPath. The Dashboard is a SPA and this type of interaction requires special handling from the client-side.
Feel free to open an issue and consider also contributing to the project.
I have successfully implemented MVC bundling for my MVC application. There is one problem with the run time which runs under HTTPS.
I am sure there is a problem because when I switch the debug field to false the user gets the warning message "This page contains secure and nonsecure items. Do you wish to proceed?
I know that I can turn this prompt off using the security setting in IE. I would like to know if there is something I can do to the application so that bundled scripts and styles come through the secure pipe.
If you use the Scripts.Render helper to include the bundle it will use the same HTTP scheme as the one used to request the main page. So if the main request was done over HTTPS then this helper will generate a <script> element using HTTPS. You could use the Net tab of FireBug to see which resources are served through HTTP and HTTPS and be able to isolate the problem.
Thank you for this suggestion. I figured out that the problem was coming from modernizr-1.7.js
The strange thing was that this problem only occurs when modernizr is bundled. I removed modernizr because we don't really need it.
I have a plugin with domain, controller and view pages. (Using grails 1.3.6)
I run the plugin as standalone, the views work fine. URL: http://localhost:8080/sample-plugin/gp/list. I am able to view the list page.
I installed the plugin into a main application i.e. plugin-test. Start as run-app within STS and browse to http://localhost:8080/plugin-test/gp/list. I am able to view the list page.
I bundle the application as war i.e. plugin-test.war and deploy to tomcat. When I browse to http://localhost:8181/plugin-test/gp/list I get a 404 error! I am not sure what I am doing wrong.
I have been trying to resolve it for quite sometime now and still no luck. The same main application works fine in STS but not in tomcat.
HTTP Status 404 - /plugin-test/WEB-INF/grails-app/views/gp/list.jsp
type Status report
message /plugin-test/WEB-INF/grails-app/views/gp/list.jsp
description The requested resource (/plugin-test/WEB-INF/grails-app/views/gp/list.jsp) is not available.
Please help.
Thank you.
Jay Chandran.
This sounds worryingly familiar, as I spent a while figuring out this (or a very similar) issue. I ended up raising this Grails bug report:
Plugin layout not found in war when installed from BuildConfig.groovy
Have you installed the plugin as using the new BuidConfig dependency technique? The JIRA documents my workaround.
Sharing some of my lessons learned after experiencing the same exact issue (1.3.7):
Double check your HTML source to make sure that your template really isn't being included. Mine was being included, but my CSS/image URLs were wrong (only while running as a war)...so I wrongly assumed that my template wasn't there.
Don't use the ui performance tags for referencing your static content...doesn't appear to work, even if the plugin attribute is specified.
Don't name your layout main.gsp. You're guaranteed to have conflicts.
Don't use absolute=true on your g:resource tags. This doesn't appear to append the pluginContextPath to the absolute url, even if you specify dir="${pluginContextPath}"
Don't use pluginContextPath, as it's no longer required: http://grails.org/doc/latest/guide/single.html#6.3%20Tag%20Libraries (search "Plugin Paths")
In your g:resource tags in your plugin layout, make sure you specify the plugin attribute. Set it to the name of your plugin.
Move your static images/css from your plugin to a web server. If each application using your plugin has its own copy, your users aren't going to benefit from caching when bouncing between apps.
Note that all of the above applies to the layout gsp in your plugin project, not your consuming application.