I initially asked this question, which shows that I see MVC errors of missing POST values. I was unable to reproduce - I still can't reproduce it on demand, but I did get the error myself on IE11, and I got a clue...
I have an application in IIS7.5 running with Basic authentication only. I look in Fiddler, and normally all transactions have Authorization: Basic xxxxx as expected. The body contains POST values as expected, and Content-Length is correct.
When I experienced this problem, I found that every single request (GETs and POSTs, including static content) was now showing Authorization: Negotiate xxxxx in Fiddler, with an empty body and zero Content-Length, even when I submitted a POST object via jQuery AJAX, and IE's dev tools shows the real POST body (which of course means IE is lying - not the first time). It gets a 401 response, and then a new request occurs with Basic, but also with an empty POST body, which means ASP.NET throws an error about missing parameter values.
Other web applications on the same top-level domain do use Windows authentication instead of Basic, and my suspicion is that the user goes to one of these sites, and IE becomes confused and thinks that my application should use Windows authentication as well - but I can't reproduce that every time. I have reproduced it twice, but out of a dozen or so times of doing the same thing over and over, so I'm not finding a way to make it reproduce every time.
I don't know why the POST body would get emptied, even if it does switch over and try to do WinAuth instead of basic - but that's when the problem occurs, so I'm sure it's related.
Any ideas on how to prevent IE from getting confused and using Negotiate, or at least how to detect and gracefully handle this on the server? I've only seen it in IE, but I can't be sure it's IE-only.
Here's what a normal POST looks like:
Then after the problem starts occurring, the exact same POST looks like:
EDIT
Here's an interesting edit - I just saw a new symptom. This time, all GET requests are coming in with no Authorization header at all, and the response comes back with a 401 for basic, and the GET is re-done properly with basic. But the POSTs are going through normally, with basic on the first try. I don't know what started this happening, but it's a similar symptom of the same problem.
Related
At my work, we are finally upgrading our old Identity Server 3 to 4. We just got a very weird problem doing so. Everything works fine in all major browsers, but we also need to support some Electron clients. Here is where the weird part begins. All very old clients using Electron version 3 still work. All newer clients starting at Electron 9 also work. The only clients that don't work are the ones using Electron 6 (Chrome 76).
I already found this very helpful article written by Sebastian Gingter which helped to get the login working. But it only got me one step further. Now the client gets stuck at the connect/authorize/callback endpoint using the response_mode = form_post.
I already found some articles/stackoverflow questions pointing out to check the redirect URIs and to downgrade the CSP to version 1. The redirect URIs are configured correctly since the other clients work. The CSP does not help since I don't even get that far. It seems that the response body is never even loaded by Electron/Chrome.
Devtools Timing Screenshot
The request never finishes. On the server-side, it does though. I debugged through the IS 4 code and the dynamic HTML is written to the response like with all the other clients. I even called CompleteAsync() on the response manually and it still did not finish.
I researched and debugged for quite some time now and am out of ideas. Does anyone out there know this issue and more importantly also knows how to fix it?
I'm trying to reproduce an exception my rails site generates whenever a specific crawler hits a certain page:
ActionView::Template::Error:incompatible character encodings: ASCII-8BIT and UTF-8
The page takes GET parameters. When I visit the page with the same GET parameters with my browser, everything renders correctly.
The IP of the crawler is always EU-based (my site is US-based), and one of the user agents is:
Mozilla/5.0 (compatible; GrapeshotCrawler/2.0; +http://www.grapeshot.co.uk/crawler.php)
Looking at the HTTP headers sent, the only difference I see between my browser requests and the crawler's is it includes HTTP_ACCEPT_CHARSET, whereas mine does not:
-- HTTP_ACCEPT_CHARSET: utf-8,iso-8859-1;q=0.7,*;q=0.6
I tried setting this in my request but I couldn't reproduce. Are there HTTP header params that can change how rails renders? Are there any other settings I can try to reproduce this?
That's not a browser, more likely an automatic crawler. In fact, if you follow the link in the user agent you get the following explanation
The Grapeshot crawler is an automated robot that visits pages to examine and analyse the content, in this sense it is somewhat similar to the robots used by the major search engine companies.
Unless the crawler is submitting a POST request (which is really unlikely as crawlers tend to follow links via GET and not to issue POST requests), it means the crawler is somehow injecting some information in your page which causes your controller to crash.
The most common cause is a malformed query string. Check the query string associated with the request: it's likely it contains a not-UTF8 encoded character that is read by your controller and somehow it's crashing it.
It's also worth to inspect the stacktrace of the exception (either in the Rails logs or using a third party apps such as Bugsnag) to determine what component of your stack is causing the exception, reproduce, test and fix it.
I'm developer working on integration between our product and LinkedIn. It's been decided we use https://www.linkedin.com/uas/oauth2/authorization to authenticate user. I found out the following issue, that I'll explain in detail below.
Positive scenario, everything works as expected:
when using valid client_id, everything is fine. To make everything clear, please see this URL (API key replaced with fake one):
https://www.linkedin.com/uas/oauth2/authorization?response_type=code&client_id=VALID_API_KEY&state=b4ac5e2ab5404d6fad2f25521d83e825&redirect_uri=http%3A%2F%2Flocalhost%3A8085%2Fapply-app%2Fpages%2Fsocial-networks%2Flinkedin%2Fauthenticated%3FsiteIdentifier%3DPIUFK026203F3VBLZ6G79V7OU%26token%3Db4ac5e2ab5404d6fad2f25521d83e825
When I remove client_id, everything is also fine and message is displayed (Missing client_id. A valid client_id is required to proceed.)
But when I use invalid client_id in browser I receive Content Encoding Error and http status code 500. URL: https://www.linkedin.com/uas/oauth2/authorization?response_type=code&client_id=invalid_client_id&state=b4ac5e2ab5404d6fad2f25521d83e825&redirect_uri=http%3A%2F%2Flocalhost%3A8085%2Fapply-app%2Fpages%2Fsocial-networks%2Flinkedin%2Fauthenticated%3FsiteIdentifier%3DPIUFK026203F3VBLZ6G79V7OU%26token%3Db4ac5e2ab5404d6fad2f25521d83e825
And the most interesting part goes here: when I fetch same URL using either wget or even java HttpConnection.connect() there result is different: HTTP status code 200 and html response. But when I started to analyze given output, I noticed that is ends up unexpectedly after <ul class="permissions, so it must me error in your code, that requires fixing.
I reported that, because it's quite inconvenient to support such behavior. Could you please inform me if you have any plans to fix this? If you need any further details regarding steps to reproduce this issue, please do not hesitate to contact me.
Best regards,
Piotr
On pages that I have signalR included I get the following error in firebug:
http://localhost:53604/signalr/signalr/negotiate?_=1352797361490
no element found
everything still works fine but just wanted to see if this will become an issue. thanks
Since you're using Firebug that means you're using Firefox. What transport are you using (if using Fiddler remember to turn Streaming on)? It should be:
1. Long Polling
2. Server Sent Events
3. WebSockets
If the transport is Long Polling then we probably have an issue in the underlying code(Firefox should prioritize WebSockets/SSE before LP).
However, if not then we have a content based issue. So that being said, what type of data are you retrieving from the server? Usually a no element found error comes from invalid markup.
Try stripping out all pieces of your application and see if you still get this error. AKA just a $.connection.hub.start().
I have been told that a POST in some way does a double send to the server but GET does not. It sounds a bit crazy to me though.
Basically I'm working on a web project where each client calls a web service every 2 seconds from many countries and possible bad internet connections. So we want to make the calls and responses as tiny as possible between JavaScript and ASP.Net.
Security is not a problem and basically the poll is just returning data. Login is required to use it anyway.
I have been told that a POST in some way does a double send to the server but GET dose not. It sounds a bit crazy to me though.
You have been told wrong. The only difference is that POST allows for sending larger amount of data to the server and of course the more data you send the slower it will be. But if you send the same amount of data there won't be any difference in terms of performance between a GET and POST request.
One important thing to note as well is that if you are calling this service from javascript GET requests might be cached by the client browser. So for example if you are calling the same url over and over again using an AJAX GET request you might get cached values and the server never hit. To workaround this issue you could append a random number in the query string which has no meaning for the server but which changes the url and avoids it being cached.
When sending thru ajax post, some developers may have inited post on form submit and a submit button click. Later when they press the send button, both actions get fired. This might be the experience that people who have told you double sending thing experienced.
Note: This double sending of POST is totally a developer's fault. HTTP POST method has nothing to do with it.