I am trying to run Chrome lighthouse on my production server. It stops returning error saying Lighthouse was unable to reliably load the page you requested. Make sure you are testing the correct URL and that the server is properly responding to all requests. (Status code: 403).
It is working fine in my local and staging setup servers. Servers hosted on AWS and cloudflare as firewall
As stated on this page
A common cause of failures is Lighthouse being blocked by bot detection or DDOS protection software, resulting in a 403 error. This can be resolved by allowing web traffic with the "Chrome-Lighthouse" user-agent string.
This is kind of frequent problem developers faces during production on a server with higher loading time, to summarize:
It occurs because of the following issues:
Unresponsive server
Unstable/Slow internet connection.
Please try to rerun the test then it will work.
Related
When we run request to the website with Cloudflare ON from python request module on local machine it works fine and return status 200.
If however exactly the same code executed from Google Cloud Run instance it returns status 522.
What we've done so far:
We went through help article about error 522 in Cloudflare documentation with our webserver provider and they confirmed we are all good on their side.
We stopped the Proxy from Cloudflare for the domain/ip.
This worked fine and we were able to run requests from the Google Cloud Run. All the requests went through.
What is the best way to set up Cloudflare so that proxy is ON and our requests are going through to the webserver?
StackOverflow Community,
I have a problem that someone may have solved before, but I find it truly confounding.I'm running a flutter web server on a vm in Azure with
flutter run --release -d web-server --web-port 8081
After getting CORS error attempting to hit Maps or Places API, I elected to run another instance of NGROK with the --host-header=rewrite flag, as I have done for other APIs to avoid this CORS error. This works fine with all of the other APIs we are hitting.
However, when serving this app, I still get a very similar CORS error, identifying items hidden:
Access to XMLHttpRequest at 'https://hidden1.ngrok.io/maps/api/place/autocomplete/json?input=s&key=hidden&sessiontoken=hidden' from origin 'https://hidden2.ngrok.io' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.Hidden1 is my maps API redirect and Hidden2 is my app's dev redirect.
Am I still getting this error because I somehow need to serve place autocomplete, in this case, from the same subdomain as the app's subdomain?? I'm confused, because this is not a constraint of any other APIs I remember using in the past.
I still get a 200 response with this CORS error, but chrome refuses to do anything with it unless I use a CORS-enabling extension.
If I do need to redirect Places and the app's Web Server through the same URL, are there any recommendations for doing this?
Thanks in advance for your time and thoughts..
We have a REST based API project. The project is hosted in IIS on multiple servers on a load balancer.It works great except when a server goes down on the load balancer, we receive a 404 Bad Request error for few seconds and then it resolves itself. How do we resolve this? Are there any changes that need to be done in IIS or on the REST API project itself?
As far as I know, if you use IIS ARR's loadbalance there is no need to add the specail setting to check the server's status. The IIS ARR healthy test will auto send the request to check the server is work well or not. If the IIS ARR find the server is down or return error, it will not redirect the request to the server.
Besides, as far as I know, the 404 error means the page not found not the bad request. Normally, 400 is the bad request status code.
If you find a server is down in your server farms, I suggest you could try to access the server directly through the brwoser to know the details error message.
If the server return 404 error, that means your browser couldn't access the server, it is a network issue normally. You should check the DNS server setting or make sure the IIS web application is running.
If the server return 400 error, you should troublshooting according to the details 400 error message. Normall, it shows when the request contains the wrong header.
Im trying to run a website with socket.io Vue-Socket.io and want to enable DDOS protection from cloudflare. As I know cloudflare supports websocket-servers such as socket.io.
After I enabled cloudflare successfully and changed the ports of my socket-connection, the google dev console tells me:
Failed to load http://my-domain.com:2083/socket.io/?EIO=3&transport=polling&t=M9uD7PJ: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://my-domain.com.com' is therefore not allowed access. The response had HTTP status code 400.
Someone can tell me what I have to change?
PS: Im working with the vuejs-cli
This is a CORS issue.
In your socket.io server, add the configuration to enable CORS: server.origin().
In your case:
io.set('origins', 'http://my-domain.com:2083');
Again this is a server-side issue, it is just being reflected in Vue. But there's nothing Vue (or the client-side) can do about it.
I played around with some of the examples of #acdcjunior and found a solution finally.
On my server I implemented:
io.set('origins', 'http://my-domain.com:*');
For the clients I connect to the socket server:
export const SocketInstance = socketio('my-domain.com:2082');
don't ask me why, but I tried and tried around for about 7 Hours.. love programming :)
I've followed the guide:
Getting Started with Authentication with Mobile Services .NET for Windows Store
I'm able to run the service locally as long as I don't need to authenticate the user. I can also authenticate the user if I publish the service to Azure. But I want to be able to test and authenticate the user locally. How can this be done?
I'm using Live ID and I have the correct ClientID and ClientSecret set in the Web.config. When I attempt to call LoginAsync from the client the call fails with The request could not be completed. (Method Not Allowed)
** Update 2014-03-20 **
Based on the comments of Carlos and Henrik, I've updated my local service to look exactly like my server instance. I followed Scot Hanselmans excellent guide and now I have my service running locally on port 80 and port 443 with a completely valid SSL certificate. It's even running on the exact same https://xxxx.azure-mabile.net hostname.
With these changes, there is now no configuration difference whatsoever between running the app against my local machine or running it against Azure. I can go to https://xxxx.azure-mabile.net in the browser, get redirected to Live login, sign in, and get redirected back to the service successfully. In the browser it all works. However it still doesn't work in the app.
I attached the debugger, set CLR errors to "break when thrown" and I managed to trap the exception in the service. Here's what I see in the immediate window:
The Response property is not helpful. It does not provide any additional information about the problem.
The only thing that stands out to me is that the app is trying to do a POST to /login/microsoftaccount while the browser would normally be doing a GET at this address (then getting redirected).
** Update #2 2014-03-20 **
After following Henriks guide for remote debugging I was able to load symbols and get a tiny bit more information:
"An existing connection was forcibly closed by the remote host"
The error code is 10054 (WSAECONNRESET) Connection reset by peer.
It appears the Live Authentication server may be forcibly terminating the connection, but only when I'm authenticating with the app. Again, authentication within the browser is fine. This, combined with the fact that /login/microsoftaccount is a POST from the app seems to suggest there is a problem with the authentication token I'm getting back from LiveClient.LoginAsync. I'll do some more digging...
At the moment, it is set up so that you don't need authentication when running locally and access the service from localhost. In this case, anonymous access is let through (this is of course disabled while running in the cloud).
We don't really have a way for your to authenticate locally as redirect URIs won't work (they can't point to localhost as there is not way that Facebook, say, can resolve "localhost").
One option is that we somehow can mock the authentication locally and give you a token without connecting with the various identity providers. I am not sure exactly what that would look like but it is something we can consider.
Henrik
Did you perhaps set Mobile client app: Yes in your Live Connect project? I think that setting is meant to be used with the Live Connect SDK (client) flow, not the browser-based (server) flow. The client flow isn't supported yet with a .NET backend.
You also want to make sure you are using LoginAsync(MobileServiceAuthenticationProvider.MicrosoftAccount) on the client to trigger the server flow.