I'm stumped. I'm making a POST request to an API using fetch. It's a Vue3 app built with Vite. Everything works locally, also in Vite preview, but when I make a fetch request in production using any method other than GET, the request hangs. The request is logged in network, but absolutely nothing happens - no error, nothing. There's not even any connection information - like the connection doesn't happen at all.
The endpoint is a cloudflare worker. It works fine using GET, the API works fine using curl, however browsers simply won't even begin to connect.
There's no error at all, just an indefinite hang.
Weird one this. The cloudflare worker was cloning the request, passing it to another service, then didn't read the response which caused the cloned request to cancel. This seemed to cause execution to hang for the first request. Didn't happen with GET requests.
Related
I am working on Safari Web Extension on on iOS 15, everything seems smooth so far except one thing:
The fetch request from background.js will always fail since it is cross origin and hence throws CORS error.
If I add the "Access-Control-Allow-Origin: *" in server, the request is completed without any error. However, we are reluctant to allow all origins.
Solutions tried
Access-Control-Allow-Origin: safari-web-extension://<guid>
Access-Control-Allow-Headers:< some request header we sent >
This didn't work because the GUID changes every-time the app is installed.
Any advice to resolve this?
Thanks a lot
We're using Twilio. We have webhooks set up so that when Twilio receives a call, it forwards it to a URL on our site.
This appears to have been working fine. But now I made a change to the code, and suddenly Twilio is having problems calling the webhook. We don't receive the message, and if I look in the Twilio log, it says it got a 403 error. (I can't swear that this has never happened before. I've never noticed a message to be lost, but maybe I missed it while debugging other errors, attributed a lost message to something else.)
The truly strange part is, about 2/3 of the message that come in are received and processed fine, but about 1/3 get the 403 error. This is on a test server where we don't have any load balancing, so all requests are going to the same instance of our app. The tests I've been doing today are all from the same cell phone to the same Twilio number.
We do have authorization on the app, but the authorization is all on sub-directories, not the top level, and the sub-directory with our web hook has no authorization set up.
The first thing my our web hook now does when it gets called is send me an email with the content of the message from Twilio. (For debugging purposes.) I'm not getting that email, so I'm very confidant it's not getting called. And as I say, I can look at Twilio's log and it says that it received the text message and got a 403 error trying to forward it to my webhook.
The fact that it's only like 1/3 of the time is particularly puzzling. It's from the same number, to the same number, hitting exactly the same URL on the same site. Why would it work sometimes and not other times?
I tried to reproduce the problem on my desktop by calling the URL directly, not going through Twilio, and that does not give the same error. (It occurs to me as I type that the next logical test is to hit the page on the server without going through Twilio.)
Oh, the server is ASP.NET. The code is in VB but I doubt that matters as we're not getting as far as executing any of our code when it fails. When it doesn't get the 403, the code is working fine.
Check your firewall configuration as it might block the requests.
If it does then whitelist requests originating from Twilio.
We're using AWS WAF and ran into a similar situation: We saw the requests erroring out with a 403 in the Twilio Debugger but the requests never hit our endpoints. Once we adjusted the whitelist the problem was gone.
My rails application sends emails through a gmail account using mailer. Till recently everything was working fine. But now sometimes I get the error as
"Net::OpenTimeout: execution expired"
This happens sometimes and sometimes it works. I want to know the reason for this behavior. Is it because of the gmail server having load balancing issues or is it because of some configuration issues in the rails app?
I am using the Ionic framework to build an html5 app that is then deployed to an iOS device with PhoneGap. Everything was working great, then we switched some server addresses that were being used to get data to include a port number in the address and the HTTP method was switched from a GET to a POST. After the switch we tested locally in the browser and it was pulling data with no problems. When we deployed to the device we saw nothing in the logs when the request was executed, and the success or error handler was never reached. In the code below only "HERE1" is printed and everything stops.
console.log("HERE1");
$http.post("http://XX.XX.XX.XX:81/api/Authenticate", null ,{ headers: {'Authorization': 'Basic ' + encodedNamePw} })
.success(function (data, status, headers, config) {
console.log("HERE2");
})
.error(function (data) {
console.log("HERE3");
});
I then tried to perform a GET to the same address and I got a response, saying that I obviously had the incorrect method. I then tried a POST to the address without a port and I got response, which was again an error, but at least I got a response. So to summarize it works locally in browser, it works on the iOS device with a GET request and a PORT, but it does not make any request when I use the POST method. I did try to escape the colon but that did not help. I'm pretty baffled by this one so any thoughts are appreciated. Thanks!
After much pain an agony I found the issue and the options available. The issue was that we were getting a 401 response and a www-authenticate http header. When this is sent by the server apparently iOS tries to pop a login dialog, which is blocked by PhoneGap. Instead of hitting the error callback method it just eats it and you never get any feedback that the request has completed.
The best solution requires you to have access to the server you are calling. If you do, and you can update the response to not send a www-authenticate header for 401 responses then you are golden and it works as expected. If you can't then you have the option to set the async option to false on the request. This approach will block at the UI, which is not ideal, but may be acceptable if it is just a login request. Best of luck.
I have a phonegap app which connects to a web service and authenticates using http basic authentication. It is built using phonegap build and targets Android and iOS.
On a login view, an ajax request fires against the remote server to check if credentials are correct, then if so, logs the user in to the main application.
This completes successfully in ripple emulator on desktop pc and when also when deployed onto an Android device.
However, when the app is deployed onto an iOS device (ipod touch) the authentication request simply does not ever complete. Using phonegap remote debugger I can see that the ajax request starts but never completes. It is always in a pending state. I use jquery ajax success, error and complete handlers for the request, but none of them are ever hit so I don't get the chance to see any error messages returned from the server. The request never seems to complete.
I have tried making ajax requests to other remote web sites to test that my app can communicate and they succeed, so it doesn't seem as though I have white-listing issues.
Any ideas of what the issue could be?
Please read the update to this answer at bottom.
Original answer
I have found what the issue is and managed to get basic authentication working.
The issue was that the web server was expecting basic authentication details to be preemptively sent with the request.
To do this use the 'headers' property of jquery ajax as shown below:
$.ajax
({
type: "GET",
url: "https://webserver/authenticate",
headers: {
"Authorization": "Basic " + btoa(USERNAME + ":" + PASSWORD)
}
})
.done(function(){
alert('Authenticated!')
})
.fail(function(){
alert('Error!')
});
See related answer:
https://stackoverflow.com/a/11960692/1463497
Update
I found in the end that there is no reliable way of using basic authentication in a web view in iOS. I.e everything is fine if correct credentials are entered but when they are not and the 401 challenge response comes along, iOS web view can't seem to handle it.
In the end, the web service authentication was implemented by simply passing 'username' and 'password' parameters as part of the url:
url: "https://webserver/authenticate?username=abc&password=123"
This is the only consistent way I found of getting authentication to work across iOS and Android in a web view (by getting rid of basic authentication altogether). This of course meant updating the web service itself to accept authentication in this way.