I have an ASP.NET MVC 1.0 app and am setting a cookie to hold data.
It works fine when test in IE with VS2008.
When I deploy to IIS6 site no cookie is created.
Site uses HTTPS.
I am checking Temporary Internet Files folder for the cookie.
Any ideas of things to check?
Malcolm
Make sure that if the cookie you are setting has the Domain property set, the value should correspond to the domain you are hosting your web site under II6.
Related
i came to know : Under the covers, the MVC AntiForgeryToken attribute uses the machinekey for encryption. If you don't specify a machinekey in the web.config , one is automatically generated for you by ASP.NET.
If the ASP.NET application is restarted (e.g. do an iisreset), the AntiForgeryToken within the browser cookie will still be encrypted with an old machine key, hence why it crashes with the above error.
My concern is
before write the machine key in web.config i like to know where i should look for the machine key to copy & paste in web.config. when we are testing in local pc then we can copy & paste the machine key in web.config but when we will host our site in godady or ORCSWEB in shared environment then those company may not give machine key of the pc where our site will be hosted. so i need to know how to handle this situation. thanks
EDIT
<configuration>
<system.web>
<machineKey
validationKey="21F090935F6E49C2C797F69BBAAD8402ABD2EE0B667A8B44EA7DD4374267A75D7AD972A119482D15A4127461DB1DC347C1A63AE5F1CCFAACFF1B72A7F0A281B"
decryptionKey="ABAA84D7EC4BB56D75D217CECFFB9628809BDB8BF91CFCD64568A145BE59719F"
validation="SHA1"
decryption="AES"
/>
how to get or generate validationKey & decryptionKey separately ? any idea?
If the ASP.NET application is restarted (e.g. do an iisreset), the
AntiForgeryToken within the browser cookie will still be encrypted
with an old machine key???
I don't think machine key changes with iisreset.
You can generate machine key (validation and decryption key) yourself and specify it in web.config. The same key will be used in all cases where encryption is performed e.g. Auth tickets, AF Token.
A good introduction link.
UPDATE:
How to generate machine key?
There are various way, this msdn blog suggest using IIS which looks more secure to me as Microsoft tool being used. However, it seems this feature is only supported until IIS 7. I don't find it on my box IIS 8.5. I checked on IIS 7.5 and its not present there either. However, I found it in IIS 6.1 on a coworker box.
Second option is to use custom key generators
a. Machine Key Generator (online)
b. ASP.NET machineKey Generator (tool you can modify)
I have an ASP.NET MVC4 application running on Windows Azure and it uses Azure ACS for Federated Authentication.
When we first started testing the application, it was working in all the browsers except Safari and Opera because of the size of cookie.
I've read several articles online that asked me to use FederatedAuthentication.SessionAuthenticationModule.IsSessionMode = true;
The above statement will store the data in the cookie on the server side. That fixed the problem because only a session identifier is stored on the client(browser).
However, that attribue appears to be removed from the WIF 4.5 api.
Do you know if there is a work around?
Do you save the original token? Do you have something like this in your web.config, or do you set the saveBootstrapTokens config setting to true:
<securityTokenHandlers>
<securityTokenHandlerConfiguration saveBootstrapTokens="true" />
</securityTokenHandlers>
If you do, or if you don't, try setting the saveBootstrapTokens to false! This is will save you a lot of "space".
I had this issue only when I had saveBootstraptokens set to true.
Yes - #astaykov is correct - that's part of it.
As per #Dominick, it's called "IsReferenceMode" in .NET 4.5.
I added wildcard mappings to my website in IIS 6.0 so that my MVC application works properly but now I get a page can not be found for every request. Once wildcard mappings are inserted I can not browse to a test html file I created or any of my routes.
The site works fine when the wildcard mappings are off and I create a application extention called .mvc which is then used in my routes however I woupld prefer not using the extension in the Url.
Here are some highlights of my setup, server, and application:
Windows Server 2003 with IIS 6.0:
.Net 3.5 SP1
Bin deployment for the MVC dll's
Server has mutiple sites running on it. With this particular one being set up as its own site (not a virtual directory).
The site uses forms authentication
When setting up the wildcard mappings I unchecked "verify file exists" and mapped to c:\windows\microsoft.net\framework\v2.0.050727\aspnet_isapi.dll.
The web service extensions where pointing to framework64. As soon as the wildcard mapping was pointing to the correct folder (framework64 instead of framework) it worked.
Url rewriting can help you to solve the problem. I've implemented solution allowing to deploy MVC application at any IIS version even when virtual hosting is used.
http://www.codeproject.com/KB/aspnet/iis-aspnet-url-rewriting.aspx
After publishing a new build of my ASP.NET MVC web application, I often see this exception thrown when browsing to the site:
System.Web.Mvc.HttpAntiForgeryException: A required anti-forgery token was not supplied or was invalid. ---> System.Web.HttpException: 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. ---> System.Web.UI.ViewStateException: Invalid viewstate.
This exception will continue to occur on each page I visit in my web application until I close out of Firefox. After reopening Firefox, the site works perfectly. Any idea what's going on?
Additional notes:
I am not using any ASP.NET web controls (there are no instances of runat="server" in my application)
If I take out the <%= Html.AntiForgeryToken %> from my pages, this problem seems to go away
Under the covers, the MVC AntiForgeryToken attribute uses the machinekey for encryption. If you don't specify a machinekey in the web.config (see here), one is automatically generated for you by ASP.NET (full description).
If the ASP.NET application is restarted (e.g. do an iisreset), the AntiForgeryToken within the browser cookie will still be encrypted with an old machine key, hence why it crashes with the above error.
So you should always specify a machinekey in your web.config when using MVC, e.g.
<configuration>
<system.web>
<machineKey
validationKey="21F090935F6E49C2C797F69BBAAD8402ABD2EE0B667A8B44EA7DD4374267A75D7AD972A119482D15A4127461DB1DC347C1A63AE5F1CCFAACFF1B72A7F0A281B"
decryptionKey="ABAA84D7EC4BB56D75D217CECFFB9628809BDB8BF91CFCD64568A145BE59719F"
validation="SHA1"
decryption="AES"
/>
...
If you're on a server farm, make sure your machine key on every server is the same.
I too had this problem, and expecting the users to clear their cache, cookies or refreshing the page isn't acceptable.
Adding a machinekey to web.config is will fix this. I used this tool to quickly generate a key so I don't see these errors in development and then I generate one properly when the site goes into production.
http://aspnetresources.com/tools/machineKey
I am trying to deploy my MVC app on a subdomain, unfortunately I get 404 errors.
I tried to find out if it's MVC itself that can't handle being hosted on a subdomain.
I uploaded the standard bare MVC webapp that you get when you start a new project. The index page loads, but all the other pages that require actual routing based on the url do all give 404's.
What do I need to change to be able to use MVC on a subdomain.
(it's all setup on a IIS 7.5 server as a seperate website)
I had this problem with a shared hosting provider. I had to get them to change the Application Pool to "Integrated Mode" instead of "Classic" mode in iis7 for it to work. Not sure why, haven't really looked into IIS7 that much
Is this a shared host where the subdomain is resolved via URL rewriting to point to a sub folder?
MVC doesn't care what the domain name is. I've used it with a couple different subdomains, but they were not on the type of host that would be rewritting to a sub folder.