When i try to validate the following page in the post inspector: https://www.cicomcopier.nl/nieuws/cicom-copier-levert-bijdrage-aan-de-ontwikkeling-en-realisatie-van-bellenschermen-tegen-verzilting-a-dam-rijnkanaal-en-noordzeekanaal/
I get the error: We encountered a server error while trying to inspect the URL.
and on the URL redirect trail i get: 0 undefined
I have no idea where to start debug this, is this a error on our side or linkedin side?
when i debug the URL using the facebook graph debugger everything seems to be right.
The problem in the end was the server from where I did the request wasn't setup correctly. Because from my side the site had a ssl installed and needed to do a ssl handshake with the LinkedIn server.
LinkedIn is made in java, and java has a more strict policy in validating the handshake. Because from my server setting the hostname for the ssl was not communicated correctly to LinkedIn there server did not validate the ssl and therefore could not connect to our server and receive a response. This ending in a unknown error on LinkedIn end of the site.
Related
When trying to run a request through swagger UI, I receive the following response on Swagger
TypeError: Failed to fetch
After searching around, I found that a possible cause of this error is because of a CORS issue, where the origin is changed in the request (as you can see at this other post here). However, in my case, this is not running through some other proxy, it is hosted on a locally hosted server and that server is not changing any of the headers. I realized this when I tried to allow the API to just accept any CORS headers to test if this was the issue; sadly it was not and the issue persisted.
The API is running on IIS hosted on a server that is hosted locally. The API is running as an application on the default website and is accessed via the following url:
http://servername/application-name/swagger/index.html
Can anyone help with this issue?
After further investigation, I found that when I looked at the requests being sent to the server through the dev tools on the browser, that the URL was being changed from http to https on the request of the endpoint through swagger.
HTTPS, has not been set up on the server and returns a 404 (as seen in the dev tools).
It turns out, that even though the server has not been setup to serve content via HTTPS, the requests where still redirected to HTTPS and this was the reason
app.UseHttpsRedirection();
So, even though swagger was able to be loaded on HTTP, when the request was made to the API, the API responded with a 307 - for redirection and the request was redirected to HTTPS - which in turn returned 404. This 404 response was the cause the TypeError: Failed to fetch
The recommended fix for this is to turn off https redirection (ONLY FOR TESTING PURPOSES) and the other is to enable the server to serve the content correctly over HTTPS, so that when a call is made, it is not redirected, but rather sent straight to the correct API address on HTTPS - which should not return the data correctly, since the server can serve HTTPS content
I have a couple Azure VMs behind a Basic Load Balancer with an HTTP URL Health Probe for the Backend Pool. To mark a server down, that URL returns Status Code 503 (Service Unavailable), but when I call that page from those VMs, the Status Code returned is 403. That still has the desired effect, I suppose, of marking the server down - but I dont understand why the code I set has changed.
This is from an ASP.NET web forms application on the VMs. I look at developer tools in the browser, and from my local machine or from a Dev server on our local network, that page returns Status Code 503, but calling that page from the VMs in Azure, the Status Code is 403.
Here's where I set the Status Code in that page:
Response.Clear()
Response.StatusCode = 503
Response.Flush()
I suppose I should mention that my local is a Windows 10 box, and the server VM is Windows Server 2016. Both are running IIS 10. The application is compiled with .NET Framework 4.6.
Here's the dev tools from my localhost:
Here's the dev tools from the server in azure:
Why the change? Anything I can do to stop this behavior?
So today I tried enabling Failed Request Tracing, but either something wasnt set up correctly, or the error was being handled elsewhere, and didnt result in any failed requests being logged.
Since I wasnt getting any failed requests logged, I opened up Process Monitor and could see that immediately after the call to my Health Probe page, I was getting a call to my custom HTTP Error page. That page must have been what was giving the 403 (dont know why, b/c that page works correctly for other HTTP Errors with a friendly error message and logging of the error to my custom error tracking solution).
I was going to change the Status Code to see if there was something special with the 503 that I was setting that was handled differently in IIS, but that got me thinking about how I was setting the status code...
In my research today, I saw this page https://www.leansentry.com/HowTo/AspNet-Response-Flush-Poor-Performance which cautions against using Response.Flush(). The code that I had implemented was in the Page_PreRender method, so there's not really a need to Flush there anyway.
I removed the Response.Flush and of course, my troubles went away.
The Health Probe page no longer triggers an Error from the Azure VM, and therefore, the status code that I get in my client browser is the 503 that I set in code.
So I guess this case is closed. I will need to figure out why the HTTP Error page was throwing a 403 instead of returning the friendly error message, but that should be easy enough...
I have used better exposed filter module and set it as on click submit. it set an ajax request when click on the check box. It is causing problem in HTTPS. it is working fine in HTTP.
An AJAX HTTP error occurred.
HTTP Result Code: 403
Debugging information follows.Path: /views/ajax
StatusText: Forbidden
ResponseText: 403 Forbidden
ForbiddenYou don't have permission to access /views/ajaxon this server.
There are couple of things that you need to check:
It is likely you have not set $base_url in your settings.php file.
There is a mode_security file on Amazone EC2 server increase the size of post data when using https. Hope it will work Happy coding...
I have configured 2 providers and used the FOS-Oauth-Bridge. FB works just fine, but when I try connecting to LinkedIn, the browser shows the message
Content Encoding Error
The page you are trying to view cannot be shown because it uses an
invalid or unsupported form of compression.
Please contact the website owners to inform them of this problem.
I tried decoding the generated URL and that seems fine to:
https://www.linkedin.com/uas/oauth2/authorization?response_type=code&client_id=077-dd7c-4815-aea0-8c31e0ce7&scope=r_fullprofile&state=eecd50f81e6ad3e7e23cc11ec50d4768&redirect_uri=http%3A%2F%2Fsf2test.dv%2Fapp_dev.php%2Fsec_area%2Flogin%2Fcheck-linkedin
I tried changing the redirect URL to 127.0.0.1, changing the port to 8X but nothing works
I do not have SSL installed on my Windows / Apache
When I manually change the LinkedIn URL to HTTP (instead of HTTPS), I get this message
Request denied
**Request denied**
Sorry, we are unable to serve your request at this time due to unusual traffic from your network connection.
Reason codes:
3,2,19
Can someone help me figure out the problem?
We publish an asp.net API on:
http://API.domain.com/v3/service.svc
https://API.domain.com/v3/service.svc
Had a problem last week with a corrupt SSL certificate which meant connecting to the HTTPS ref fails with an internet explorer connection problem. HTTP ref was fine, was confirmed the SSL corruption was the issue.
A customer that should have been using HTTPS never noticed, logs confirmed they are actually using HTTP for authentication and data.
When testing with WCF STORM (test app I used to test method calls) I could recreate the issue i.e HTTP ok & HTTPS fails. Installing a backup certificate resolved the problem instantly, everything back to normal operation.
So I started looking at HTTP to HTTPS redirects. Got it up and running using http://www.iis-aid.com/articles/how_to_guides/redirect_http_to_https_iis_7 (i.e the change to web.config).
When browsing to my API HTTP and HTTPS url, everything worked as expected.
When using WCF STORM to I get the message:
System.InvalidOperationException: The document at the url http://API.domain.com/v3/service.svc was not recognized as a known document type.
The error message from each known type may help you fix the problem:
- Report from 'DISCO Document' is 'Discovery document at the URL http://API.domain.com/v3/service.svc?disco&disco could not be found.'.
- The document format is not recognized.
- Report from 'http://API.domain.com/v3/service.svc' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.
- Report from 'WSDL Document' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.
- Report from 'XML Schema' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.
at System.Web.Services.Discovery.DiscoveryClientProtocol.DiscoverAny(String url)
at WcfStorm.DynamicProxy.ServiceClientProxyFactory.(Option`1 )
at WcfStorm.DynamicProxy.ServiceClientProxyFactory.DiscoverEndpoint(Option`1 cfgOption)
at WcfStorm.Model.WcfServiceModel.(ServiceClientProxyFactory )
at WcfStorm.Lib.Common.BgWorker`2.OnDoWork(DoWorkEventArgs e)
Client proxy code is empty!
I remember one of the developers telling me that the AUTHENTICATION uses SSL but the SOAP messages are transmitted over HTTP. Therefore I suspect the HTTP to HTTPS redirection has caused this issue as its forcing the SOAP messages to use HTTPS and the API has not been configured to do this .... I'm guessing? Developer explained that its recommended that APIs using HTTP for transmitting the SOAP data after authentication using SSL to confirm credentials.
Questions:
How do we force the SOAP data to be transmitted over HTTPS if this is deemed the solution?
If this is not possible how do i deployed HTTP to HTTPS redirect within the environment above ?
Any other way to force HTTPS onto end users / disabled HTTP and / or redirect to HTTPS ?
Thank you for any help.