I'm running Firefox 36.0.4 on Windows 7 32-bit. I've diabled all add-ons, extensions and user scripts before retesting this.
I'd like to step through JavaScript code that is served up in a <script> tag in the HTML document being produced by a Java (Tomcat) web server.
Unfortunately, when I select the HTML document under Debugger > Sources, the source of the page returns to the login page of the application - it appears that session information is not being used to request the source.
I stepped through the server-side code and found that the correct session cookie values were being sent for the real page request and some AJAX requests sent by the page. However, when I tried to load the page source in the JavaScript debugger, I found that an incorrect session cookie was being sent by the JavaScript debugger.
I can replicate this behaviour in other webapps, not just my own. For example, Stack Overflow:
Is this a configuration issue, or a bug in the Firefox Developer Tools?
I can't reproduce your problem using StackOverflow as an example, at least in Firefox Developer Edition ( currently version 38 ):
One thing that might help - try disabling the cache while the toolbox is open - this setting is in the developer tools setting panel ( click on the 'gear' icon at the top right of the toolbox ):
After reviewing canuckistani's answer, I downloaded Firefox Developer Edition. Seemingly, the problem was fixed.
Five minutes in, I became sick of being asked whether to remember passwords and having to manually clear session cookies (I prefer being able to do it by simply closing the browser) - it makes testing easier.
As per usual, I went to Options > Privacy > History to disable this behaviour, by setting the value to Never remember history.
Changing this setting requires the browser to restart. However, upon restarting, I once again saw the same erroneous behaviour - the wrong session cookie was being sent to the web application again.
The workaround here is to not use the Never remember history setting. I have filed a bug report at Mozilla.org Bugzilla.
Related
Umbraco 7.6.6, running under IIS 8.5 on fully patched Windows Server 2011 R2 Standard, 64bit.
Our content editors notice that often when they create a new article (which has some graphics specified) the system hangs after they try to browse to a different article... or indeed anywhere in the front-end site, too. It only affects them; other users are still able to browse and/or create content.
F12 dev tools shows that browser is pending the result of this type of call:
http://whatever.com/media/1101/thumbnail_pmc-1x2.jpg?width=500&mode=max&animationprocessmode=first
If I try to view that thumbnail without the querystring data, it loads instantly... while the first call is still hanging in it's unresponsive tab:
http://whatever.com/media/1101/thumbnail_pmc-1x2.jpg
DEBUG level Umbraco logs just show this:
2017-10-10 17:02:53,120 [P2816/D6/T57] DEBUG Umbraco.Web.UmbracoModule - Begin request: http://whatever.com/media/1101/thumbnail_pmc-1x2.jpg?width=500&mode=max&animationprocessmode=first.
No errors in the umbraco logs, no errors in IIS logs, nothing in event viewer.
Best I can tell, something is going wonky in the browser. Can anybody please advise on how I can troubleshoot further?
Thanks!
I have a Firefox extension displaying its own HTML page via a chrome:// url, and scripts in it are running with chrome privileges. For users' security, I want to add a Content Security Policy to this page.
The obvious thing to do is to add it via <meta> tag, but that's not yet supported in Firefox (bug 663570). Update: Bug 663570 was fixed in Firefox 45, but my attempts to use a tag caused Firefox to crash. Bug 923902 seems to be the new bug to watch.
Is there any way to implement a CSP right now? Some way to fake the appropriate HTTP header for a chrome:// URL?
I asked this question waaay back in the days of XUL add-ons, which are long gone - in this era of WebExtensions, I could define a CSP in manifest.json, although the default CSP is plenty secure.
I have an existing website and suddenly some days ago I can't use Google Chrome anymore for developing. When I use a standard edit and create page, I get the above error. But i'm not getting it in Internet Explorer. I use Windows 10 (all updates installed) and VS2013 with Update 4. The project is the latest MVC version. I even checked the web.config but nothing is changed. I deleted all history, cookies, passwords etc.
Anyone any idea?
I had the same problem. For me the solution was to both clear my browser cookies and to disable Adblock. Other addons may have the same effect. I believe the problem is limited to the Visual Studio / Chrome development environment and will not occur in production regardless of whether the end user has Adblock enabled or not.
Do you have a
<httpCookies requireSSL="true" />
in your Web.config? Change that to false. Then in your transforms files (Web.Prod.config, and other environments that have SSL):
<httpCookies requireSSL="true" xdt:Transform="SetAttributes" />
I'm also having the same issue in recent weeks, but it's also extending cross-browser after originating from Chrome. What's even stranger is that it still works flawlessly with the identical project on a different machine using all browsers.
I have gone so far as to uninstall all extensions, delete all cookies / data, sign out of Chrome completely and re-install it. Problem still persists.
On deployment to Azure websites the problem isn't present on any platform. My current work-around is to Ctrl-F [ValidateAntiForgeryToken] and comment out every occurrence, and re-enable it upon deployment. Annoying, but it works.
This was happening to me in Chrome, and seemed related to using the 'remember me' checkbox on login forms, and closing then re-opening the browser. The token was present on inspecting page source, but was reported as being not present during debugging sessions in visual studio. By clearing the browser cache and not checking the 'remember me' box I did not get the problem - but I don't fully understand why!!
My steps to reproduce the bug in Chrome:
Sign in to your MVC web application, clicking on 'remember me' to make it checked
Close browser
Open browser to your current retained session
Try to sign out - error happens here.
Anyway, the following solution worked for me. Inside your MVC view form, try replacing this:
#Html.AntiForgeryToken()
with:
ViewContext.Writer.Write(Html.AntiForgeryToken().ToHtmlString());
Are you on cloud platform ? chrome emits cookies from cloud domains hence the only way to do it is to map another named domain to your cloud web site
This is probably because browsers like Chrome use the Public Suffix List(https://publicsuffix.org/list/effective_tld_names.dat) to restrict certain cookies. If the domain suffix set on the cookie is shared publicly then the browser may block such a cookie in order to prevent itself from sending "unauthorized" data to other servers running on the same domain.
While debugging a JavaScript program I was writing with Firebug, the Script panel stopped working and I got the following message:
I went through all menus and sub-menus I could find but didn't see a option to re-enable this feature. The console.log() command doesn't work in Firebug as well (while it does work in the built-in devtools' console).
How can I re-activate the Firebug Script panel? What may have caused this?
This may have different causes. One of them is described in issue 5646, which is related to going back and forward in the browser history.
In such cases it normally requires a browser restart to work again.
Note that Firebug up to version 1.12 is based on an old debugger API exposed by Firefox called JSD, which is unmaintained and buggy. Since version 2.0 Firebug uses a new debugger API, which fixes this problem.
Coincidentally, I just "fixed" the same problem with my Firebug.
I went through re-installs, options resets and such and nothing helped.
After some investigation it boiled down to the content of the page I was debugging.
I have a function called by jQuery when page load is finished:
<script>
$(onPageLoad);
</script>
Now, this function asks user to enter his name using prompt() function. It appeared that Firebug wouldn't activate script panel until prompt() is closed. That is not a problem when you have just one page opened since you just close the dialog and everything works. However, it is a problem when you have two same pages opened. Script panel is non-operational until you close both prompts.
I was facing this problem recently. I found that my Firebug was not getting updated because my Firefox was stuck on 29.x. Once I updated my Firefox the new Firebug got installed. It supports only Firefox 30+.
Note: I was using OSX v1.9.3.
I was having same problem, and, thanks to Roman Guralink, I figured out that the the dialogue Firefox prompts you to insert the master password was the cause. When you set a master password for all password stored, FFox usually opens a dialogue to ask it just after program started. BUT, sometimes this dialogu goes behind the main window, and you don't notice it is there.
I am trying to deploy a .NET MVC application to GoDaddy servers. I have an Html.AntiForgeryToken on one of my pages that is causing it throw an exception every time I hit it.
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.
I have generated a machine key using the following URL
http://aspnetresources.com/tools/machineKey
and have set the pages viewStateEncryptionMode to "Always"
<pages viewStateEncryptionMode="Always">
I am still receiving the error however and am at a lost as to what to do next. Any suggestions would be greatly appreciated.
I finally figured it out. I did a little bit more google searching and found that if I don't clear the cache on the browser it will retain the invalid viewstate. Apparently chrome holds onto some semblance of the viewstate in each consecutive browser unless all of the chrome browser windows are closed down (I use alot of chrome browsers), even when the cache has been cleared.
I found that the code worked by trying it in Firefox and IE which was successful. I then closed down all of the chrome windows (after clearing cache) and restarted. I was then able to navigate successfully to the page with the AntiForgeryToken on it.