I get the Error:
A potentially dangerous Request.Form value was detected from the
client (wresult="
I've used WIF in my .NET 4.0 website, and use
<httpRuntime requestValidationType="Namespace.FederatedRequestValidator"/>
which allows me to deal with the validation, and have no issues.
I now want to use WIF in my .NET 3.5 application in VS 2008, but the above config is not valid, and .NET 3.5 doesn't seem to have System.Web.Util.FederatedRequestValidator
How can I get around this error, preferable without turning validation off.
If I need to turn validation off, whats the best way to achieve this in VS 2008 .NET 3.5?
I ended up creating a sign in .aspx page which is a 'middle man' between the replying party and the STS. Call that page, and pull any extra parameters from the URL and then redirect to the STS with the sign in page .aspx as a return url.
I then made it that that page, and only that page ignored validation, which isn't a problem since that page does nothing but call and return from the STS.
Related
I have a rather old ASP.NET 4.5 application that is running on .NET Framework 4.7.2, which makes use of [WebMethod]s called from .aspx pages via jQuery. In our testing environment, these AJAX calls work fine, but when we deploy the same deployment package to production, the AJAX calls return 302 redirects to the home page.
The application uses a mix of WebForms and MVC.
Both environments are using Windows Server 2008 R2 SP1, and when I diff the web.configs, the configurations are identical outside of the usual appSettings and connectionStrings and other custom configuration blocks.
If it was a route registration issue (e.g. Calling asp.net 4.5 web service returns 302 and redirects to default page) then I would expect it to fail in UAT as well in production. Any suggestions as to how I can fix this?
In the end, I decided life was too short to spend too long on fixing up legacy technologies, and just moved the web method codes into Controller action methods that returned ASP.NET AJAX-friendly JSON, and everything works again.
WebMethods, being static, are an abomination these days anyway, unless you love ServiceLocator.
I have just performed an upgrade from 4 to 6 (still using WebForms) and got most things working again - but I'm unable to set the HTML form action correctly on a page with a usercontrol on a page which has a rewritten URL. The nice URL is like /developer-job-in-london-J12345 and the rewritten URL is /jobs/details.aspx?JobRef=J12345.
On v4 I just set the Request.Page.Form.Action to the Page.Request.RawUrl in the UserControl code, running the same code in v6 seems to work fine - but looking in the HTML output, it's still using the rewritten URL as the action (/jobs/details.aspx). Which means you're sent to a different URL on postback and a new entry is added in your history.
I can check Page.Form.Action and it looks correct from the control Page_Load and the master pages (actually tried all the events I could think of), but as I say, the final HTML is always incorrect.
Has something changed in v6 relating to this? Is there anything I can do to avoid having to fix this in JavaScript!? :(
New assembly version is: 1.0.5529.18434 if that matters.
Thanks!
Edit
<add name="JobRewrite" virtualUrl="(.*)-job-J(.+)$" rewriteUrlParameter="ExcludeFromClientQueryString" destinationUrl="~/Jobs/Details.aspx?JobRef=J$2" ignoreCase="true" />
Edit 2
Stranger and stranger: This was working fine on my CI server - the action is set correctly, but I have a mobile site which is just a WebForms project, with Umbraco installed so I can use the membership provider. That site appeared to have the opposite problem - there's a search form there which has a blank action on my CI server, but works fine on my dev machine.
However, I've now fixed that with help from here: https://stackoverflow.com/a/15353347/48348 - and it turns out to be a problem with changing my project to the latest version of ASP.NET - and the handling of form actions for default documents. Not sure if that can actually be related to this as it's Umbraco that should be handling everything here? Hmm...
As a slight aside: I'd love to use LESS umbraco on that site, but am struggling with that, too - question about that here: https://our.umbraco.org/forum/developers/api-questions/63161-Use-Umbraco-membership-(and-profile)-provider-in-non-Umbraco-ASPNET-web-forms-site
I am currently working on an ASP.NET MVC project and came upon an error that seemed peculiar.
In the ASP.NET MVC Templates forms always get an AntiForgeryToken (thus leading me to believe that this is a best practice). However AntiForgeryTokens don't seem to work well with caching.
For example when I open a site with a form including an AntiForgeryToken and I duplicate the browser window both windows have the exact same AntiForgeryToken leading to an exception when posting the form. This problem does not exist when caching is disabled (via ActionFilter NoCache, see Disable browser cache for entire ASP.NET website).
So I guess my question is: Is this supposed to be that way? Is there any other way besides disabling the cache to tackle the problem?
Especially the fact that the default ASP.NET MVC templates contain AntiForgeryTokens but don't disable the cache (and therefore are open to the error described above) makes me wonder.
Thanks in advance!
This is the expected behavior. Caching nicely caches the answer, including the value of the AntiForgeryToken. Disable caching on forms, and in particular on pages that use AntiForgeryToken. If you think about this further, if you're in a data-entry app, do you want to cache your data-entry forms? Probably not. However you do want to cache heavy reports -- even if it's just micro-caching -- a second or two.
I have an MVC 1.0 app with a form that works just fine.
The app also launches an SSRS using the URL ReportServer interface (**Not the Webform ReportViewer Control!). This also works just fine.
But if I export the generated SSRS report (say to .pdf), and then return to the MVC application, no form will work. By "not work" I mean that on the Post action, the form collection is not returned.
I'm completely lost as to what could be causing this behavior. Any ideas? Thanks in advance.
Figured it out. One site was NTML authenticated, and the other was not. I had assumed with IE8 and tab-session states that the NTML - non-NTML IE optimization interplay no longer applies. But this experience proves it does, at least on XP and Vista.
So the solution is to either hack the client registery (I've never thought this approach really practical) or in my case, use 2 sub-domains. In the latter case, it's important to know that the IE authentication optimization uses the full URL. So suba.mydomain.com and subb.mydomain.com will each be treated as a unique site by the IE authentication optimization, and hence not lead to the sequential site authentication dependancy problem.
This KB is relevant: http://support.microsoft.com/kb/251404
Once deployed parts of my web-application stop working. Index-es on each controller do work, and one form posting via Ajax, Login works too. Other then that yields 404. I understand that nothing particular should be done in integrated mode.
I don't know how to proceed with troubleshooting.
Some info:
App is using default app pool set to integrated mode.
WebApp is done in net framework 3.5.
I use default routing model.
OS is Windows Server 2008.
IIS 7
Any help is appreciated. Thx.
EDIT:
I determined that only actions that accept ID parameter don't work. On the contrary, when I add dummy id method in Home controller of default MVC app it works.
EDIT 2:
I found the problem. Links on few pages of the site didn't use ActionLink helper. It was harder to see because of the Ajax invoking. So, never hardcode links to the actions on the site, even temporary.
Please go through this link for details on deploying MVC application with IIS 7 integrated mode.
http://www.asp.net/mvc/tutorials/older-versions/deployment/using-asp-net-mvc-with-different-versions-of-iis-cs