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.
Related
I am developing a MVC 5 application for the first time. I have implemented a individual User Accounts authentication setup. This works fine when I am working on my local machine in Visual Studio 2015. But when I publish the project to a webserver I get the following annoying issue. Users can log in - no problems. They can go to another page, sometimes this gives no problems sometimes the user is redirected to the login page and has to login again. The user can login and no further problems arise on that page. But when the user goes to another page sometimes this gives no problems and sometimes the user is redirectes again to the login again.
I suspect there is some issue with the webserver (IIS) but I have examined every possible setting, but cannot find anything suspicious. Any suggestions/help on this would be appriciated.
I'm not sure if this is the problem you're facing, but still i would suggest to check your session timeout in Web.config file.
Try increasing it if it is too low.
Look for the sessionState tag in the config file.
<sessionState mode="InProc" timeout="9999" />
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.
I have an ASP.NET MVC project and I am testing deployment to Windows Azure via the local emulator. I can run the project file fine in the development server but when I build the Azure project and it launches via the emulator I am having an issue with content files not being returned correctly. My internal CSS and JS files are being re-directed to the login page as if the authorization is failing; however I do not see where this auth requirement would be coming from.
Things I have already tried:
I have manually removed all the build files from both project (I have also tried the "clean" action for the solution)
I have tried removing the Azure project all together and creating a new one from the current version of my project.
I have tried clearing the local storage through the Azure storage interface.
I have verified that all my content is marked as "Content" in my ASP.NET project.
I have tried flagging all of my content items as "Copy always"
I have verified that the Static Content optional feature is checked
EDIT: I did a deploy to the web and everything works great there ... this is an emulator issue it appears. Any suggestions with that new bit of info?
You should verify your web.config just to be sure. Do you see something like this?
<system.web>
<authorization>
<deny users="?" />
</authorization>
...
</system.web>
Did you put the [Authorize] attribute on some of your controllers, or your controller base?
If it works in the cloud and in ASP.NET Development Server, I am not very sure why it doesn’t work in emulator. However I don’t think the issue is related to your application. For now, I would like to suggest you to check your IIS settings, such as applicationHost.config. Please see if there’re any authorization settings that may cause this issue(Compute Emulator uses IIS under the hook to host web roles). Please also try to host the site in a local IIS directly and see if the same issue could be encountered. If you can reproduce this issue in IIS as well, I would recommend you to consider to add a “IIS” tag to this thread, so more IIS experts will provide further suggestions.
Best Regards,
Ming Xu.
This thread has been open for a long time so I wanted to close it with what ended up being the solution.
It ended up being a bug with the emulator and the environment being used. As I mentioned, I was able to get it working when deployed. I actually tried this same situation 6 months later after updating to the latest Azure tool set and it worked fine so I am chalking this up to a bug in the emulator that has since been resolved.
I have an ASP.NET MVC3 website with custom authentication (i.e. <authentication mode="None" />). It's hosted on IIS with only Anonymous Auth enabled to support some SSO work we're doing. That's just to say that requesting a plain old file from /Content typically "just works", e.g. https://oursite.com/Content/ourlogo.jpg opens in the browser window as expected without providing credentials.
Having a problem with CSV files in IE7 and 8, however. I've placed the [im]pertinent CSV in /Content/Documents/hello.csv and linked to it normally. When the user clicks the link and chooses "Open", as opposed to "Save", it should open smoothly with Excel. However, it appears that Excel is making additional requests for authentication, and the user gets prompted for username/password. Of course, they don't have those credentials to give, and IIS doesn't want them anyway. If the user cancels out the prompt, they'll get it one more time, and after a second cancel, the CSV opens in Excel as desired.
Really want to get rid of those prompts.
The problem in production behaves the same on my dev machine running ASP.NET Dev Server, so it's probably not a problem with HTTPS or something we configured on IIS. Did a test on an empty MVC site, putting the file in the same relative location. This works correctly. Kind of leaves me thinking there's a problem in our code, but I'm at a loss to what it might be.
Would love any thoughts, as I'm about out of ideas.
The solution in our case was to deny the HTTP verbs OPTIONS, HEAD and PROPFIND for the directory hosting the CSV in IIS. Apparently Excel is making these calls as part of WebDAV.
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.