__RequestVerificationToken always the same when reloading form in MVC4 application - entity-framework

While on a development server a standard MVC4 / EF4.5 login form with Html.AntiForgeryToken() refreshes its value with every page load. When deploying the same code on IIS the hidden value __RequestVerificationToken is always the same (at least in one browser session). Other similar applications on the same server do not seem to have this behavior.
Which web.config/IIS parameter might be responsible for this?
Already tried setting the machine key (single server) but this only seems to shorten the token, the refresh problem remains the same.
Also tested in different browsers. Here are some demo values for IIS and development server:
IIS:
Without machine key in web.config:
BGxqV7DjpHomi22By0r70WebHiWMV2OcsrCMN-dNDkRElZrv6BMQH23_zK9abmRsty_n1NImH2-gEsi3nBrWIQ2
With machine key in web.config:
dXBdht7mn2plT2rPvv0HzWtFvn-N9MT6xzW_xc8dVqnLdofzrL5v0SZFMAFPTANR0
Cassini / development:
Without machine key in web.config:
Yedkrxms9oYmHGzhV93qsrryVuNKZSWKBwCkP-RzK-tAZGgQ6J5g6Yp0LsCQPehucVwDcUs5lfRUf6Y6FxYUqY0olkE3-PmtF0ZnrCcbXD6XuA1PgPoFchreTPnCCSCwsh3E3FPmdKPlabyOfqiykkVqocxzYBMqd7A3bCZIxU01
With machine key in web.config:
iFjqi1OYplYfhCYdflAw1LSncVwK3b1yfDaJRgfrqVamucJ992D3-pFD__RolMZ_edp6muXQWLkxGOQp5Wn2ObTKXltO2J9tq32-JUMGu7cXdYZMkty3MRwuE-SuIFt7zo7TvQ2

Try the fix mentioned in the below KB. It solved the issue in our environment.
http://support.microsoft.com/kb/2656351

Related

Prompting of credentials on Edge browser despite already logged in on client PCs

Some background:
We were accessing our RSA Archer application on IE 11 via SSO, and all has been well. But we are required to move on to Edge browser, and that's where we started having the Windows Security credential prompt coming out, whenever we tried to access the application on Edge browser.
The strange thing is, the application is able to load up on Edge properly, in the logged in state, and then the prompt will appear. We can just click on Cancel to close the prompt and we are able to use the application normally. All end users on their client PCs encountered the same problem.
We want to remove the credentials prompt. The RSA support team has confirmed it is not an issue of their product, since there's no problem over at IE. What we have done on our end on the servers:
Enabled SSL on our load balanced environment
Updated the web.config file of the application with the entry below:
<security mode="Transport">
<transport clientCredentialType="Windows" />
</security>
Configure IIS settings to allow Anonymous Authentication instead of Windows Authentication for the application pages.
Will greatly appreciate some assistance or suggestions on how to move forward. Thanks!
Addon after investigation:
After finally being able to investigate via the development tool for this, we discovered that apparently, the behavior of some components / javascripts were different on IE / Edge.
On IE, if the components / javascripts took too long to load, it will fail (status 304) and retry again until it succeeded (status 200).
On Edge, instead of failing, it will go into "Pending", and then the credentials prompts pops out, and usually there's more than one prompt. We suspect the number is based on the number of pending components / javascripts that are in "Pending". Clicking on Cancel on the prompt will caused the components to not load (status 304), and no retry will happen like in the case of IE.
Able to advise what's wrong? Is there a timeout in the Edge settings?
Open Edges developer tools and go to the Network tab and see which request (URL) is prompting you for credentials. Then you can see what IIS has configured for its security.

IIS Express doesn't keep session data

I have an application that I run in Visual Studio 2013 under IIS Express server. The problem is that session data is not kept between pages and I find with null objects that weren't null the page before. If I compile the application and deploy it on a web server with IIS it works normally, so it must be something with IIS Express. I searched the config files in the document folders, but really don't know what it is.
Thanks,
Luke
Edit 25/11: I'm debugging the code on the same machine witn VS 2013 and VS 2010 and I found where the code behaves differently. After the code behind has been executed and the page has been built, in VS 2010 the execution ends. In VS 2013 after the page has been built I get another call to the method context_BeginRequest(object sender, EventArgs e), which redirects the application to the starting page, where the instruction Session.Clear() clears the session. The problem now is: why is there this additional call to context_BeginRequest method? Why does it redirect to the starting page and not to the page it is currently in? Thanks, Luke.
I was having a similar problem. My code was running fine on a production server, but when I debugged it on my test machine, the session would be null between saving and redirects.
When I set the session state to cookieless, <sessionState cookieless="true", the session variable would be retained. This was undesireable though because it adds the session name to the url.
Upon further review, I noticed a line in my system.web <httpCookies requireSSL="true" /> When I commented it out, everything worked as usual.
The problem was that my production IIS server was hosting the code using https://, while my test IIS Express server was only using http. So my unsecure cookies were getting discarded.

Webtop 6.7 SP1 GUI missing frames after login by SSO auth

I have terrible issue with Webtop 6.7 SP1 P12 (I have tried also testing P26) with SSO (kerberos) login into Webtop application.
On the user enviroment Web browser is in version IE 8.0.7601.17514 and operation system is Windows 7.
When I login into application (SSO authentication is succesful) result screen is missing some frame:
Sometimes frames are not behaving like this:
in this case URL is also strangely modified (part of it was deleted).
Java (1.6.0.27) is installed correctly. I also checked security setttings on JAVA and IE, but I don't see any incorrect parameters here.
When I use web browser Firefox 3.5.19 to login into the Webtop (SSO is active too) GUI is loaded correctly with frames..
My another test was under operation system Windows XP, IE 8.0.6001.18702. The Webtop GUI workiing correctly.
When I tried logging into Webtop instead of the hostname by use IP address application server, GUI working correctly. In this case SSO is off.
I tried change verzion JAVA vs IE but nothing helps.
Wireshark network protocol analyze capture this HTTP issue:
this problem occurs on 6 users of total 100.
Please, do you have any ideas for me?
Thank you so much.
Lukas
Investigating further we found that non-working users were part of 100+ AD groups resulting in a large kerberos token size.
I changed tomcat config file "server.xml" to increase http header limit to "maxHttpHeaderSize="16384"".
<Connector port="8080" maxHttpHeaderSize="16384" protocol="HTTP/1.1" ... />
Here is the link to fix:
http://blogs.adobe.com/livecycle/2012/08/avoiding-livecycle-kerberos-based-sso-problems-for-active-directory-users-with-large-group-memberships.html

Intalio Ajax Forms pointing to localhost

Anyone working with Intalio|BPMS?
I'm trying to implement a process using the Comunity Edition, and I'm having a problem I can't seem to solve.
The process has an AJAX Form and if I go to ui-fw in the server using localhost everything works, but if I try to access the server remotely using the url it doesn't.
The iframe for the AJAX Form is pointing to localhost and not the url.
From the very bad foruns at Intalio, I've checked /tried:
deploy from the designer using the url
finding every mention of localhost in the process deploy dir, and also in the var/conf
Still no luck.
Any ideas anyone??
Thanks in advance
Ricardo, IIRC the form is deployed according to the settings you use in the deployment manifest. I believe you can also set an other host name in the deployment manifest to deploy to localhost, but declare a different host name for the form and processes.

MONO / ASP.NET Authentication Persistence

I'm deploying an ASP.NET MVC 2 application using Apache / mod_mono / MONO (2.8.1) that uses the built in ASP.NET authentication framework.
When I restart Apache, or use the mod_mono control panel to restart the mono server process, users are logged out. I don't want this occurring.
I'm using custom Profile / Membership / Role providers (that are backed by a Redis database), and these currently have a bare minimum implementation. I can not see where my problem fits in here however, but am I missing something obvious?
I notice that the .MONOAUTH cookie changes value when a user logs back in, so I guess there is some persistence that needs to happen that is not happening.
Any solutions or pointers to the relevant documentation would be great!
NOTE: I'm not sure if the information below differs when you're using a Membership Provider -- it may be that session state is persisted by the Membership Provider itself.
It's likely that you're using "in-process" session state storage. This means that whenever you restart the web server process, you're clearing out all the session information stored in the web server process's memory space.
To avoid wiping out session information, you can move to using an out-of-process session state server, either running as an in-memory service (see below for the Mono version) or on SQL Server. Otherwise there are also a number of unofficial custom session store providers that use alternative storage mechanisms (e.g. MongoDB etc.)
I found what you may want, which is this Mono ASP.NET Session State Server: http://manpages.ubuntu.com/manpages/gutsy/man1/asp-state2.1.html
As a first step, take a look in your web.config at the system.web -> sessionState property. If it's set to mode="InProc" then there's your problem. It should look more like:
<sessionState
mode="StateServer"
stateConnectionString="tcpip=server:port"
stateNetworkTimeout="number of seconds"/>
Solution: set the validationKey and decryptionKey manually:
<machineKey validationKey="blahblah" decryptionKey="blahblah" />
I think this is probably a bug in mono that these take on different values over server resets when auto-generated (which is the default).