Recently, 2-SSL verification was added to the server I'm working with.
Up until now I've used Advanced REST Client for server's REST API (mostly GET calls).
Since the SSL change, I'm getting 0 NO REPONSE ERROR:
How can I add SSL certificates to my GET calls? (I do have the .cnf & cacert + cakey files)
From the bug tracker, you can go to the page in your web browser and select 'Proceed Anyway'. After doing that my REST calls went through fine.
Advanced REST Client extension in recent upgrades has resolved this issue , with additional add on ARC Cookie exchange
Link https://chrome.google.com/webstore/detail/arc-cookie-exchange/apcedakaoficjlofohhcmkkljehnmebp
Related
I integrate Google's Auth API in my production website.
When I enter the login page, it throws an idpiframe_initialization_failed exceptions to the console.
I found out that I can fix it by enabling that API / Cookies in my chrome browser, but I want to find a comprehensive solution that will prevent those exceptions in my production environment.
So my two questions are:
What do you suggest me to do in order to achieve that?
In general, what is the meaning of those excpections?
Thanks :)
If you have a production url like http://godaddysite.com etc host your page there with a Webserver.
Opening a htnl page from your computer with javascript doesnot work as it is not hosted on webserver.
Please check your redirect url etc when you created Oauth client.
Go to the Credentials page.
Click Create credentials > OAuth client ID.
Select the Web application application type.
Name your OAuth 2.0 client and click Create
check origins
create new OAuth with correct origins.
We have recently migrated to a new hosting environment so have installed a fresh instance of Shibboleth. When we generate sp metadata files, the urls are non-secure (ie http) even though the url used to generate the metadata uses https.
When using the test connection from our own Azure AD system, we see the obvious error: "The reply URL specified in the request does not match the reply URLs configured for the application:"
I have limited knowledge of configuring the system beyond working on shibboleth2.xml and attribute-map.xml so would be very grateful if anyone can point me in the right direction to fix this.
I'm not sure if you managed to configure it but i'm currently working on this as well, and i think i can help.
So the ReplyURL you need to provide in the Azure Portal, is the reply URL that accepts the authentiaction reply message from the identity provider.
In the case of Shibboleth it is:
http[s]://yoursitename/Shibboleth.SSO/Auth/Saml
So if your webpage is for instance:
https://localhost/Foo
The replyURL should be:
https://localhost/Shibboleth.SSO/Auth/Saml
Notice that the page "Foo" is not in the replyURL.
After the authentication the browser should send the IDP reply to https://localhost/Shibboleth.SSO/Auth/Saml, after which Shibboleth should redirect you back to https://localhost/Foo
At least that's the default behaviour.
I have the following issue.
After upgrading an application to ASP.NET 2.0 I get a 400 (bad request) status response whenever trying to authenticate in production.
This error does not reproduce locally and doesn't reproduce when using the production container locally.
The only difference that exists between production and local is that there is a reverse proxy in production that implements SSL for all requests.
I've tried moving the authentication code from middleware (as it was initially implemented) into a controller and I've changed the path to the route that was used for authentication. I still get the error.
All other requests work fine (provided you have a jwt token attached to them).
I should also mention that the CORS headers aren't set on the 400 response.
Any ideas?
This issue was caused by an upstream reverse proxy that was stripping some headers from the requests. Requests with verbs Post & Put were affected.
Set the log level of your application to Information to see what Kestrel is actually complaining about.
In our case we had to switch hosting providers because of the issue.
I am getting a 401 and some cross domain issues when trying to access IBM Weather REST API from either client (browser) or server.
If I generate a URL and try and access it directly from a browser (eg paste it in it works fine and the JSON weather report is returned).
When I try and run the Javascript HTTP request from either the browser or server it seems like it's only allowed to run from an ibm.com domain.
Failed to load https://twcservice.au-syd.mybluemix.net/api/weather/v1/geocode/-33.00/151.00/forecast/daily/7day.json?units=m&language=en-US: The 'Access-Control-Allow-Origin' header contains multiple values 'https://*.ibm.com, https://*.ibmcloud.com', but only one is allowed. Origin 'http://localhost:3000' is therefore not allowed access.
I am using the free service on Bluemix. Is this restricted to only run via a Bluemix server? or are there some options I can pass when I create the service on Bluemix
Note, when I make the request I am using the credentials supplied via the Bluemix console. Again, this works via the browser URL bar, but not via code.
Update/More info: if I hit past the URL above into the browser (with creds) it works as above, then if hit it via the web app in the same session it works.
Hmmm. So the IBM server is sending the following response header:
Access-Control-Allow-Origin: https://*.ibm.com, https://*.ibmcloud.com
That's an invalid response from IBM. Unfortunately, I think your only option is to complain to IBM, and convince them to
Return a valid Access-Control-Allow-Origin response header (with only one value)
Allow people outside of IBM to access it
Without that, I fear you're out of luck.
I am connecting rest api call with wso2 api manager. I followed the steps from wso2 site
I am able to connect with rest api on my computer but following same procedure on another computer returns "Error: No Response from Server"
I had also configured the files as described here
Does anybody knows how to debug what is going wrong there ?
You can enable wirelogs and headers in API Manager to analyze the request response flow.
Open log4j.properties file in /repository/conf directory.
Uncomment the following loggers.
log4j.logger.org.apache.synapse.transport.http.headers=DEBUG
log4j.logger.org.apache.synapse.transport.http.wire=DEBUG
Save the changes and Restart the Server
Invoke the API.
Regarding your "Error: No Response from Server" response, other than the CORS issue, this can occur due to browser certificate issue as well.
Therefore, first check whether you can invoke the same API using a rest client like curl,
if yes
go to your browser, accept the certificate for the gateway URL and try out invoking the API again.