The correct error to return when a user provided invalid login/password is 401.
What is the correct error to return when the failure occurred in the authentication mechanism?
For example, the authentication mechanism is down or login requests time out.
Is returning 500 error okay in this case? I think 500 fits well from the application standpoint (server error occurred, so we could not authenticate you).
But I'm more interested on the security perspective. Does it make the system more vulnerable?
In my system I want to let the users know when they provided invalid credentials vs when the system cannot authenticate them due to server errors.
For server failure, generally any 5xx status is acceptable. You may want to specify with the error even further by using a 503 or 502 error is the server is down and using a 500 error when any other unexplained failure occurs.
Related
I am receiving more tan 10.000 bad request in Application Insights of Azure, I know some details of the transaction but I can not find a thread to pull, and understand why those head requests are getting a 404 error, how can I troubleshoot those requests?
The problem can be resolved by making a valid "/" path in you application that returns a 200 response. Alternatively look at #RithwikBojja-MT refs.
The reason for this is actually that Azure pings the root path of your applications if you have the "Always-On" feature enabled.
I have built a simple Python/Flask app for sending automatic messages in Slack and Telegram after receiving a post request in the form of:
response = requests.post(url='https://my-cool-endpoint.a.run.app/my-app/api/v1.0/',
json={'message': msg_body, 'urgency': urgency, 'app_name': app_name},
auth=(username, password))
, or even a similar curl request. It works well in localhost, as well as a containerized application. However, after deploying it to Cloud Run, the requests keep resulting in the following 503 Error:
POST 503 663 B 10.1 s python-requests/2.24.0 The request failed because either the HTTP response was malformed or connection to the instance had an error.
Does it have anything to do with a Flask timeout or something like that? I really don't understand what is happening, because the response doesn't take (and shouldn't) take more than a few seconds (usually less than 5s).
Thank you all.
--EDIT
Problem solved after thinking about AhmetB reply. I've found that I was setting the host as the public ip address of the SQL instance, and that is not the case when you post it to Cloud Run. For that to work out, you must replace host by unix_socket and then set its path.
Thanks you all! This question is closed.
We have a few APIs that are being long polled through Azure API Management. For some reason, we are receiving a response of 200 [not sent in full (see exception telemetries)] and then a System.Exception: A task was canceled. exception in App Insights.
Taking a look at the server app service telemetry, the requests were completed without any exception there.
Can anyone help me figure out what this status response means and why are we getting this exception?
These errors mean that APIM started to send response to client, sent status code and description, and some portion of headers and body. These traces must be accompanied by exception telemetry as response code suggests. Depending on what you see there it may be:
Client connectivity error - client terminated connection before response was sent in full
Backend connectivity error - backend terminated connection before providing full response
The reasons for both may vary a lot, but given small duration I'd suspect that it's client closing connection. One of the reasons for this, for example, is if this API is used from browser it is normal for browser to terminate connection and abort reading response if user navigates away from page that made the call.
Just wondering if this is a "known issue" that possibly has some sort of workaround.
I have a Node.js, MongoDB Atlas, Azure web application and server side code intentionally returns a 429 when it exceeds a rate-limit I have set up.
However, it seems to be coming back to the browser as a 524, which seems to be a Cloudflare error.
I'm wondering if Cloudflare is somehow 'converting' the response from a 429 to a 524?
And, if so, how to work around this so that I can handle the 429 error on the client side as desired.
User error.
I was returning a status code from Node.js with:
res.status("429");
Changed it to the following and it seems to have resolved the issue:
res.status("429").end();
I have been using EWS exchange version 2015 for my code and it was working until recently, on several occasions, one of the several error messages appear
"The request failed. The remote name could not be resolved: 'outlook.office365.com'"
"The request failed. The remote server returned an error: (401) Unauthorized."
"The request failed. Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host."
"The request failed. The operation has timed out"
when I am trying to bind to email messages.
Currently the code sometimes work and at other times it doesn't. Just wondering does someone have a solution to this? Or is this just a issue on the office365 server side and I can do nothing about it?
exchangeService = new ExchangeService(ExchangeVersion.Exchange2015);
EmailMessage emailMsg = EmailMessage.Bind(exchangeService, item.Id);
Side Note:
I am absolutely sure that my credentials are correct and the domain name I have entered is correct as its hard coded into my application and I haven't edited it in years. With the same credentials I can log in to outlook.com successfully
"The request failed. The remote name could not be resolved: 'outlook.office365.com'"
Nothing to do with the Service (outside of any well documented outages) this is network connectivity or DNS resolution issue
"The request failed. Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host."
Yep see this one a fair bit especially if your connection in more latent (I'm in Australia) it means for resilient code that every request for EWS you should wrap in Try Catch and retry at least once (you should also be doing this so you can process any throttling responses). Large attachment uploads can be a bit of pain if you have very low end network connections.
"The request failed. The operation has timed out"
That can be service or the network, usually you would see that on a Search using FindItems. The default timeout in EWS Managed API is 90 seconds so you can adjust that up I've never seen that error on a Bind though so sounds like really poor network connectivity.
"The request failed. The remote server returned an error: (401) Unauthorized."
I would make sure you set the X-AnchorMailbox header as discussed in
https://blogs.msdn.microsoft.com/webdav_101/2018/06/16/best-practices-important-and-critical-headers-for-ews/ . This affect the routing of the request (and its always used by all client such as OWA and Outlook)
A good way of testing would be spin up a VM on Azure somewhere (you can choose different regions to test from) and run your code for a while there and test that against what you see locally to see if the errors correlate.