I am building an ASP.NET web application use ajax to request some content and it works well in FireFox, Chrome but in IE not stable:
When use login he/she can view owner files, if not login page return string "no permission".
I logined website, I refresh page in IE sometime it show file and sometime it show "no permission" (that not login) I refresh again it show file. I mean that some request it works correct and some request it works wrong! I have seen HTTP request and see that all cookie sent correct.
Here one request
POST http://abc.com/xxx.asmx/GetFileInfo HTTP/1.1
x-requested-with: XMLHttpRequest Accept-Language: en-us
Referer: http://abc.com/?work=home Accept: application/json,
text/javascript, /; q=0.01 Content-Type: application/json;
charset=utf-8 Accept-Encoding: gzip, deflate User-Agent:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0;
SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729;
Media Center PC 6.0; .NET4.0C; .NET4.0E) Host: abc.com
Content-Length: 27 Connection: Keep-Alive Pragma: no-cache
Cookie:
__utma=63255935.688817123.1357236998.1357236998.1357390216.2; __utmb=63255935.5.10.1357390216; __utmz=63255935.1357236998.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); .ASPXAUTH=E83DCA879A8A9AF5DAE72854241CFEBF2AF4BCE7E2227465E71FB428D6816C555176F9F1A1E94CB34F9C48C4FC7C64FBCAA013672182720254821F802242B90098A01A727AA30D4A621B921536B0F5E36F9DE9382972CE7AFC52EA819669E8B8F7D4C5ECCA1EDE07D971CEA64E5847BBC0E9ACB7B26F07BC769422B8C68A5F04F2B183533C95CC6849A8B98D83F22BC306FF564FE8519A1738AC8DB1F4C55A5B6E84FC02D863C22AF3CBD04E70186C497A240313C107DD74B3D28F2AE6BF95FED3E6EA2CC7EE1767F9E9FCBD5A6EEF77EF61198BD65342E6C10B978595DADA17FBDC83A2;
ASP.NET_SessionId=ibxe0t55thibhb45vcgkxmvx; __utmc=63255935
{'ID1':'13','ID2':'2'}
How I fix it?
Thank you!
I know why, because I not set Machine Key in web.config file.
Related
This is an example of HTTP request message transmitted to the web server. Inside headers there is an Accept header. I am confused about the meaning of it and how it is created. I thought it solely specifies my browsers capabilities to handle files. But that doesn't explain why does it differ when I visit amazon.com or joes-hardware.
There is also Content-Type header, which is a MIME for a file it requested. Same question. How does my browser know what is the type of file it requested? Is it based on the URI extension I requested or is this a generic header? This header seems to only be send in response headers. My mistake.
GET /tools.html HTTP/1.0
User-agent: Mozilla/4.75 [en] (Win98; U) Host: www.joes-hardware.com
Accept: text/html, image/gif, image/jpeg
Accept-language: en
First things first: Acceptand Accept-Language are headers defined in RFC 7231, section 5.3.2 and section 5.3.5, respectively. Together with Accept-* headers, they enable content negotiation through the client. There is an excellent article regarding content engotiation on the Mozilla Development Network. (On a side-note: The MDN is an excellent starting point for research. A lot of the articles are outdated, but the concepts are still largely valid)
The content of the Accept-Language is largely controlled by the language settings of a client's UI. Mozilla's Firefox (and - IIRC - Opera and Safari) allows to tweak these through its settings while MSIE seems to deduct them from the keyboard layouts installed in the system. There is nothing in the type of requested media that should influence this header.
The content of the Accept header on the other hand is very much depending on the context in which a resource is being requested. E.g. if you request a resource through your browser's address bar, the Accept header will pretty much read like "give me anything I can digest." If the browser is requesting a resource through an <img/>-tag, the header is going to differ in that the browser is trying to get a presentation of the requested resource that is fit for being displayed inside that tag. Same for <video/>, <audio/>, and <script/>.
Beyond that, I am not aware of any mechanisms effecting the Accept header. <a/>-tags have - unknownst to most - a type attribute which is carrying a MIME mediatype. This is, however, a fallback mechanism and should not alter Accept in any way.
As for your example, I took the liberty of requesting both sites and copying the relevant request headers:
amazon.com
GET / HTTP/1.1
Host: www.amazon.com
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
joes-hardware.com
GET / HTTP/1.1
Host: www.joes-hardware.com
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
The headers are no different when requesting /tools.html in the last example.
I have ASP.NET (4.5) Web Forms application in C#. My application is not hosted in neither in a web farm nor in a cluster.
My application (principal) is responsible to create a SAML message for SSO and send it with a POST method to a service party endpoint (SAMLhandler.aspx) which is another ASP.NET application.
I cannot check the service party endpoint and therefore I have to rely on the error messages they send to me. Every time I attempt to send a SAML message the following error is given:
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.
In my page the EnableViewStateMac="false" and I set in IIS a fixed machine key, as already seen in other solutions found on the web. I would like to know whether the error is because of something wrong in my application or it is the service provider which has to fine tune something on its side. Anybody has ever had such issue?
UPDATE:
Here you have Request and Response taken from a SAML sniffer (that identifies my SAML message as valid)
POST https://www.serviceprovider.com/SAMLhandler.aspx HTTP/1.1
Host: www.serviceprovider.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate DNT: 1
Referer: https://myApp.com
Cookie: OTDefaultLang=en; Login=LoginURL=http%253A%2F%2Fwww%2Eserviceprovider%2Ecom%2Fdefault%2Easp; brandingid=9; OTLang=en%2Dus; OTSEC670817=VHL8lUncM8RaRm8QbKdzI2Mjzh4-; CteMtRequestId=; AKSB=s=1409581037748&r=https%3A//www.serviceprovider.com/portal.asp; OTSESSIONAABQRN=FA7C6FA5G873EG4D89G82E2GE8809C8075EF
Content-Type: application/x-www-form-urlencoded
Content-Length: 5989
Service Provider Response:
HTTP/?.? 302 Moved Temporarily
Cache-Control: private
Content-Type: text/html; charset=utf-8
Location: /Errors/500.100.asp?aspxerrorpath=/SAMLhandler.aspx
Server: Microsoft-IIS/7.5
webserver: usseat_cte95
Content-Length: 187
Date: Tue, 02 Sep 2014 14:14:16 GMT
Connection: keep-alive
Set-Cookie: ADRUM_BT=R%3a40%7cclientRequestGUID%3a6c526398-acce-4ae7-ae29-ee40e42648ab%7cbtId%3a553%7cbtERT%3a10; expires=Tue, 02-Sep-2014 14:14:46 GMT; path=/
Here is the scenario:
A client has a fairly standard IIS site published via a UAG portal trunk. Clicking the link on the portal page from an external client is supposed to effect a redirect to said IIS site, hosted internally. Simple enough.
For every single domain user except one, this works just fine. Here is the output from a successful redirect:
GET
/uniquesig6192b908e3f362bf06404502c58f28f18ec5923ef22832661845904b888b6fc7/uniquesig1/[sitename]/[appdirectory]/[resource].aspx
HTTP/1.1 Accept: text/html, application/xhtml+xml, / Referer:
https://portal.[company].com/[appdirectory]/Pages/[resource].aspx
Accept-Language: en-US User-Agent: Mozilla/5.0 (compatible; MSIE 10.0;
Windows NT 6.1; Trident/6.0) Accept-Encoding: gzip, deflate Host:
[othersubdomain].[company].com
DNT: 1
Connection: Keep-Alive
Cookie: ASP.NET_SessionId= r5uavyvx0drz42453cml4055;
__utma=128077646.1396813579.1381846816.1381846816.1381846816.1;
However, there is a single AD user that does not successfully redirect, regardless of browser, OS, location, ISP, you name it. We had them recreate the user in AD to create a different descriptor and verify that user object wasn't corrupt somehow. When the 'bad' user attempts to click the redirect link, the following GET request is generated:
GET
/uniquesig6192b908e3f362bf06404502c58f28f18ec5923ef22832661845904b888b6fc7/uniquesig1/[sitename]/[appdirectory]/[resource].aspx
HTTP/1.1 Accept: text/html, application/xhtml+xml, / Referer:
https://portal.[company].com/[appdirectory]/Pages/[resource].aspx
Accept-Language: en-US User-Agent: Mozilla/5.0 (compatible; MSIE 10.0;
Windows NT 6.1; Trident/6.0) Accept-Encoding: gzip, deflate Host:
[othersubdomain].[company].com
DNT: 1
Connection: Keep-Alive
Cookie: __utma=128077646.1396813579.1381846816.1381846816.1381846816.1;
As you can see, the ASPNet session ID cookie is never sent to authenticate with IIS. at first, I thought it might be an affinity problem, wherein a cookie is not recognized due to load balancing; however, we drain-stopped one server to ensure that traffic was only authenticating on one box. ASP.NET cookies are issued by IIS, which again, would indicate a potential issue with IIS. However, again, it is confined to a single user. Another possibility is that the user has Logon Permitted hours incorrectly set, which might deny them that session ID cookie from IIS. According to the client, no dice.
Can anyone see anything I might be missing? Thanks!
I have a page with normal Ajax Update panel. There is a submit button which sends the user selection to server. If the user waits for a minute or two, the response from the server is HTTP 413 ( request entity is too large) from server. This only happens when I try to resubmit it after waiting for a minute or two. If a land of the page and submit the form, the server is able to process it.
I have modified the uploadReadAheadSize(as mentioned http://forums.asp.net/t/1574804.aspx) and set it to 200,000,000 - still the problem persists
Http Request
POST https://server/somepage HTTP/1.1
Accept: */*
Accept-Language: en-US,zh-Hans;q=0.9,zh-CN;q=0.8,zh-SG;q=0.7,zh-Hant;q=0.6,zh-HK;q=0.4,zh-MO;q=0.3,zh-TW;q=0.2,zh;q=0.1
Referer: https://server/somepage
x-requested-with: XMLHttpRequest
x-microsoftajax: Delta=true
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Cache-Control: no-cache
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.3; .NET4.0E)
Host: some-server
Content-Length: 86124
Connection: Keep-Alive
Form-Data...........
The request is over SSL.
I also tried to edit httpruntime configuration in web config
<httpRuntime executionTimeout="3600" maxRequestLength="1902400" />
That solved the error. Correct me, if I am able to correctly describe the problem.
The SSL opens a secure tunnel for some time. So whenever I tried posting data in that time frame everything went fine. But once the tunnel got closed and server preloads the request before client re-negotiation. But preload max length was small and hence it failed.
I tried to set the value of uploadReadAhead value to 120,000 which was greater than the entity request size of about 86,000. Still the request failed (weird .. ????).
It was fine once I set it to the value of approx 10 MB.
I am developing with the .NET framework, using jQuery 1.4.2 client side.
When developing in Firefox version 3.6, every so often an one of the many ajax calls I make on the page will fire twice, the second will return successfully but will not trigger the success handler of the ajax call and the first never returns anything. So basically the data is all sent to the server and response is sent down but nothing happens with the response.
Here is an example of the call I am making. It happens to any of the ajax calls, so there is not one particular that is causing the problem:
$.ajax({
type:"POST",
contentType : "application/json; charset=utf-8",
data:"{}",
dataType:"json",
success:function(){
alert('success');
},
error:function(){
alert('error');
},
url:'/services.aspx/somemethod'
});
})
From firebug, here are the headers of the first call which in firebug shows as never completely responding, meaning i see no response code and the loader gif in the firebug never goes away.
Note:In firebug it usually says Response Header but for the first call this space is blank
Server ASP.NET Development Server/9.0.0.0
X-AspNet-Version 2.0.50727
Content-Type application/json; charset=utf-8
Connection Close
Request Headers
Host mydomain.com
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3)
Gecko/20100401Firefox/3.6.3 ( .NET CLR 3.5.30729)
Accept application/json, text/javascript, */*
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Content-Type application/json; charset=utf-8
X-Requested-With XMLHttpRequest
Referer http://mydomain.com/mypage.aspx
Here is the header from the second request which just appear to complete in firebug (i.e response is 200):
Response Header
Server ASP.NET Development Server/9.0.0.0
X-AspNet-Version 2.0.50727
Content-Type application/json; charset=utf-8
Connection Close
Request Headers
Host mydomain.com
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3)
Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729)
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Content-Type application/json; charset=utf-8
Referer http://mydomain.com/mypage.aspx
To summarize my question, why are two requests being made and why are neither of them triggering a success or error handler in the ajax call.
I have seen this article about firefox 3.5+ and preflighted requests
https://developer.mozilla.org/En/HTTP_access_control#Preflighted_requests
In the article is says if a "POST" is made with any other content type than
"application/x-www-form-urlencoded, multipart/form-data, or text/plain" than the request is pre-flighted. If this is the case, this should happen to all of my calls.
Thanks
This isn't an answer as much as a proposed temporary workaround. Make the call synchronous with async:false and see if things work again.
I've been tearing my hair out over a similar-sounding bug recently.