Working on a DNN (9.2) module and am getting the following error in the DNN log file when trying to call http://dnndev.me/desktopmodules/rentalz/server.ashx directly from URL address bar in browser:
DotNetNuke.Entities.Urls.UrlRewriterUtils - System.ArgumentNullException:
Value cannot be null.
Parameter name: url
at System.Web.HttpResponse.Redirect(String url,
Boolean endResponse, Boolean permanent)
at DotNetNuke.Entities.Urls.AdvancedUrlRewriter.ProcessRequest(
HttpContext context, Uri requestUri, Boolean useFriendlyUrls,
UrlAction result, FriendlyUrlSettings settings,
Boolean allowSettingsChange, Guid parentTraceId)
When I remove the following entry from the Web.config file, the ASHX page works, but the rest of the site bombs out!
<add name="UrlRewrite" type="DotNetNuke.HttpModules.UrlRewriteModule,
DotNetNuke.HttpModules" preCondition="managedHandler" />
Does anyone know what's causing this?
This request shouldn't be handled by the URL rewriter, it ignores ashx requests by default. You can go to the SEO Settings page, and check the Expressions tab under URL Management to see if ashx is listed in the Do Not Rewrite URL Regular Expression. You can also go the the Test URL tab and put your URL in to see what sort of rewriting the system is trying to perform.
You shouldn't use a handler anymore. It's an old technique that can easily create security flaws on your website. You should instead us Web API. It's so much easier to do as well.
http://www.dnnsoftware.com/wiki/services-framework-webapi
Related
I host a website that provides public API access for my customers to track their orders with an order number. I have allowed them to use both POST or GET (with URI parameter) to pass the order number to me. Some of them however wrote careless codes that passes illegal chars (asterisk, colon or incorrectly encoded asian characters), like this https://mycompany.com/tracking/orderno:ODR12345 which causes IIS to throw exception:
Exception information:
Exception type: HttpException
Exception message: A potentially dangerous Request.Path value was detected from the client (:).
at System.Web.HttpRequest.ValidateInputIfRequiredByConfig()
at System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)
I have inherited Application_Error method to log this exception. But it still gets thrown as a 400 Bad Request error to user browser and leave an Event 1309 in my event viewer, hence spamming the log with it.
I know I can turn off illegal-chars-exam from Web.config universally but that's a security risk. I just want to be able to handle this exception myself: capture it, log it my own way, provide useful response to user and then suppress it so it doesn't pollute my system log. How can I do this?
UPDATE
Lex gave me an idea to rewrite the URL. What I think is, I can put the parameter into the query string instead of leaving it a part of the path, so that dangerous path error will disappear. I then wrote the following rule:
<rule name="TrackingRewrite" enabled="true" stopProcessing="true">
<match url="/tracking/(.*)" />
<action type="Rewrite" url="tracking?querystring={R:1}" />
</rule>
So that https://mycompany.com/tracking/orderno:ODR12345 becomes https://mycompany.com/tracking?querystring=orderno:ODR12345 and the correct action was executed and users gets a 200 response with tracking information. However - after the controller action returned, Applciation_Error call back still gets called with the "A potentially dangerous Request.Path value was detected from the client (:)." exception and system log was added. Breaking into the Applciation_Error call back and printing the Request.Url shows the original illegal URL, not the rewritten one. How does one to comprehend this behavior?
Tried to use Window Authentication mode for my ASP web form (So I can retrieve the current user's name when hosted with IIS), in an intratnet environment (only accessible via network login):
Result in error message below (The URL has 8000 character counts) :
Things I have attempted so far:
1) Increase maxQueryStringLength / max UrlLength in Web.config:
httpRuntime maxQueryStringLength="2097151" maxUrlLength="10999" targetFramework="4.5"
2) Make sure I do not have any redirect in my code:
Error Redirect Loop
3) Remove blackslash at the end of my URL:
Remove Trailing Slash From the URL
4) Set UsePortNumber to true to preserve the port number:
https://searchcode.com/codesearch/view/14375781/
5) Cleared browser cookie
Also there're some client-side javascript on my default.aspx that only check target browser (IE / Chrome / etc). Is there some pieces I am missing that needs to resolve the URL too long issue? Also, it is normal to have such long URL?
I had this exact same problem.
It is caused bny disabling the Anonymous Authentication on the site.
The solution that I found was to add the following to my appsettings in the web.config file:
<add key="owin:AutomaticAppStartup" value="false"/>
In my ASP.NET MVC3 application when I queue some request to /Controller/Action?param=whatever and it fails and IIS custom errors handling configured in web.config kicks in and performs a "default redirect" (which is configured to redirect to /GenericHandler.htm I get redirected to /GenericHandler.htm?aspxerrorpath=/Controller/Action and the query string (param=wheveter part) is lost.
How do I make the query string preserved?
We're using the Jasig .NET CAS Client to interface with our organization's CAS SSO server.
However, we've noticed that in ASP.NET MVC 3 (and I would assume this affects ASP.NET WebForms as well) applications, when users log out, we see the following error in our error log:
System.Web.HttpRequestValidationException (0x80004005):
A potentially dangerous Request.Form value was detected from the client
(logoutRequest="<samlp:LogoutRequest...").
at System.Web.HttpRequest.ValidateString(String value, String collectionKey, RequestValidationSource requestCollection)
at System.Web.HttpRequest.ValidateNameValueCollection(NameValueCollection nvc, RequestValidationSource requestCollection)
at System.Web.HttpRequest.get_Form()
at System.Web.HttpRequest.FillInParamsCollection()
at System.Web.HttpRequest.GetParams()
at DotNetCasClient.Utils.RequestEvaluator.GetRequestIsCasSingleSignOut() in C:\Projects\Jasig\CAS\dotnet-client\trunk\DotNetCasClient\Utils\RequestEvaluator.cs:line 292
at DotNetCasClient.CasAuthenticationModule.OnBeginRequest(Object sender, EventArgs e) in C:\Projects\Jasig\CAS\dotnet-client\trunk\DotNetCasClient\CasAuthenticationModule.cs:line 93
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
I don't believe this is an error message users are receiving -- it seems to only be seen by the server. As far as the users are concerned, log out is successful.
Is there any way I can get ASP.NET MVC to stop trying to validate these types of requests? I know I can disable request validation completely, but that's out of the question. The site with a hyphen has a good question on this, but not really an acceptable answer:
add the following setting to the web.config:
<httpRuntime requestValidationMode="2.0" />
After setting this value, U can disable request validation by setting validateRequest="false"
So, is there any way to disable ASP.NET validation for this request without turning it off completely?
Edit: This is also tricky to debug because this request is coming from the CAS server, NOT from the user's browser. I think this is the CAS server attempting to notify all running applications that the user has signed out (single sign out). So we're only receiving this error in production, not when testing locally.
The dotnetcas client gets access to the request before it gets to an MVC controller action, so it is not possible to simply set the validation attribute on an MVC controller or action.
The target of this request seems to be the last URL that was validated, so it is not possible to disable validation for a specific path in your application by using this method either: http://erikbra.wordpress.com/2012/04/17/wif-saml-token-post-and-requestvalidationmode2-0/
From what I see you have a couple of options:
Disable this validation:
<system.web>
<httpRuntime requestValidationMode="2.0" />
</system.web>
or
.Net 4.5 allows you to access a request before it goes through validation. If you have access to this you can re-compile the client from source, fixing the relevant issue.
I am not familar with Jasig .NET CAS but ASP.NET MVC allows you to disable request validation at the page level.
Add the following attribute to your controller action:
[ValidateInput(false)]
I generate an XML/Google sitemap on the fly using an Http Handler, so that I don't need to maintain an XML file manually.
I have mapped my Http Handler to "sitemap.xml" in my web.config like this:
<httpHandlers>
<add verb="*" path="sitemap.xml" type="My.Name.Space, MyAssembly" />
</httpHandlers>
It works nicely. Now, www.mywebsite.com/sitemap.xml sets my Http Handler into action and does exactly what I want. However, this url will do the same: www.mywebsite.com/some/folder/sitemap.xml and I don't really want that i.e. I just want to map my handler to the root of my application.
I have tried changing the "path" of my handler in my web.config to "/sitemap.xml" and "~/sitemap.xml" but neither works.
Am I missing something here?
Try adding the following to your web.config
<urlMappings enabled="true">
<add url="~/SiteMap.xml" mappedUrl="~/MyHandler.ashx"/>
</urlMappings>
This uses a little known feature of ASP.NET 2.0 called 'Url Mapping'
Following on from Kirtan suggested solution #1 you can do a workaround like follows:
public void ProcessRequest(HttpContext context) {
//Ensure that the sitemap.xml request is to the root of the application
if (!context.Request.PhysicalPath.Equals(Server.MapPath("~/sitemap.xml"))) {
//Invoke the Default Handler for this Request
context.RemapHandler(null);
}
//Generate the Sitemap
}
You might need to play with this a bit, not sure if invoking the default handler will just cause IIS to re-invoke your Handler again. Probably worth testing in Debug mode from VS. If it does just re-invoke then you'll need to try invoking some static file Handler instead or you could just issue a HTTP 404 yourself eg
//Issue a HTTP 404
context.Response.Clear();
context.Response.StatusCode = (int)System.Net.HttpStatusCode.NotFound;
return;
See the MSDN documentation on HttpContext.RemapHandler for more info -
http://msdn.microsoft.com/en-us/library/system.web.httpcontext.remaphandler.aspx
2 solutions to this:
Soln #1:
You can check the request path using the Request.Url property, if the request is from the root path, you can generate the XML, else don't do anything.
Soln #2:
Put a web.config file with the following setting in every folder in which you don't want to handle the request for the sitemap.xml file.
You can, alternately, run a check in the global.asax, verify the request, and finaly re-assigning a new handler throughtout context.RemapHandler method.
The only thing is that you would´ve to implement a factory for that matter.
I would suggest you inherit the HttpApplication, and implement there the factory, but that's your call.