We are having a problem on our web server which is driving us mad!!
When we define defaultDocument in our web.config we always get the dreaded 403.14 Http error. The config is (inside system.webserver):
<defaultDocument enabled="true">
<files>
<clear/>
<add value="~/Forms_Mosaic/Our System.aspx"/>
</files>
</defaultDocument>
We are using IIS 7.0 and if we turn directory browsing on we can happily browse to the specified file. We have the folders that it reside in set to ANONYMOUS LOGON user credentials and can also access the page with a fully qualified url.
Can anyone suggest why we keep getting this error?
Thanks.
I came across a similar issue today and found that the tilde (~) and leading forward slash were causing the issue. For example, while the following doesn't seem to work:
<defaultDocument enabled="true">
<files>
<add value="~/test.htm" />
</files>
</defaultDocument>
specifying the file just as a plain-ole-relative URL worked fine, at least for me:
<defaultDocument enabled="true">
<files>
<add value="test.htm" />
</files>
</defaultDocument>
Note though that if your desired default document's in a subfolder relative to the application root (as seems to be the case for you) then when you browse to the subfolder you're going to get the same issue. For example, if you browse to http://example.com/Forms_Mosaic/ IIS'll be looking for a default document at http://example.com/Forms_Mosaic/Forms_Mosaic/Our%System.aspx which obviously won't exist.
Strikes me that a default.aspx in the root folder with a Server.Transfer or Response.Redirect might be a better solution in the specific case of the OP, rather than using a site-wide setting to handle what's really a folder-specific problem.
The value you specified is not a valid URL. Try:
<defaultDocument enabled="true">
<files>
<clear/>
<add value="~/Forms_Mosaic/Our%20System.aspx"/>
</files>
</defaultDocument>
You may also get this error if you are using urlMappings. In this case, the value will have to be the non-mapped value. So for the following situation, you will see the error if the value is page-b.aspx but not if it is page-a.aspx.
<urlMappings>
<add mappedURL="~/page-a.aspx" url="~/page-b.aspx" />
</urlMappings>
Related
I'm using Quartz.NET 2.2.400.0 and am experiencing problems installing multiple instances on a single machine.
I am trying to amend the name of the instance via the configuration file (Quartz.Server.exe) as follows:
<quartz >
<add key="quartz.checkConfiguration" value="false"/>
<add key="quartz.server.serviceName" value="CalSched"/>
<add key="quartz.server.serviceDisplayName" value="CalSched"/>
<add key="quartz.server.serviceDescription" value="CalSchedservice"/>
</quartz>
When running Quartz.Server.exe install without the above, everything works perfectly. When the service name is specified, the scheduler does not run.
I wondered if anybody would be able to shed any light on this?
This is an old thread. But I will put the answer here in case someone got same issue. When <quartz> tag (Quartz.Server.exe.config) is used, quartz will ignore configurations in quartz.config and therefore, this configuration line is ignored quartz.plugin.xml.fileNames = ~/quartz_jobs.xml. As a result, quartz won't read your job settings and won't run the job as expected.
So you need to move all your configuration to tag. You need to add
<quartz >
<add key="quartz.checkConfiguration" value="false"/>
<add key="quartz.server.serviceName" value="CalSched"/>
<add key="quartz.server.serviceDisplayName" value="CalSched"/>
<add key="quartz.server.serviceDescription" value="CalSchedservice"/>
<!-- MUST ADD -->
<add key="quartz.plugin.xml.type" value="Quartz.Plugin.Xml.XMLSchedulingDataProcessorPlugin, Quartz" />
<add key="quartz.plugin.xml.fileNames" value="~/quartz_jobs.xml" />
</quartz>
And it will work.
I have ran into the "max web.config size" for one of my applications running on IIS 7.5, Before editing the registry to increase this value, I tried to move all the rewriteMap rules into an external file but the server gave me back a 500 error.
After several checks I've noticed that this way will work
<rewriteMaps>
<rewriteMap name="OLDSITE">
<add key="/withonlythis_will_work" value="http://oldsite" />
</rewriteMap>
</rewriteMaps>
But if I put some non standard alphanumeric character it will crash (e.g.)
oldòsite
<rewriteMaps>
<rewriteMap name="OLDSITE">
<add key="/withonlythis_will_not_work" value="http://oldòsite" />
</rewriteMap>
</rewriteMaps>
Both rules work if I leave them on the webconfig, but the second one does not work on external rewritemap.config file
any clues?
Try to use the HTML named entity for ò that is ò ; (please remove space before ';'):
<rewriteMaps>
<rewriteMap name="OLDSITE">
<add key="/withonlythis_will_not_work" value="http://oldò ;site" />
</rewriteMap>
</rewriteMaps>
I'm trying to use a separate config file, named "rewritemaps.config", that contains the URLs I want to redirect. The file is in the root directory (same place as the web.config). The format of the Redirects.config file I have is:
<rewriteMaps>
<rewriteMap name="Redirects">
<add key="aspx/drvmain.aspx"
value="http://www.newdomain.com/folder2/page2.aspx" />
<add key="aspx/jobs_AboutUs.aspx"
value="http://www.newdomain.com/folder1/jobs.aspx" />
<add key="aspx/page.aspx"
value="http://www.newdomain.com/folder1/page2.aspx" />
</rewriteMap>
</rewriteMaps>
In my web.config file, I have:
<system.webServer>
<rewrite>
<rewriteMaps configSource="rewritemaps.config" />
<rules>
<rule name="Redirect rules">
<match url=".*" />
<conditions>
<add input="{Redirects:{REQUEST_URI}}" pattern="(.+)" />
</conditions>
<action type="Redirect" redirectType="Permanent"
url="{C:1}" appendQueryString="false" />
</rule>
</rules>
</rewriteMaps>
</rewrite>
</system.webServer>
In the IIS Manager (which, yes, I have installed the URL Rewrite module), I've even gone and tested the rule and condition against one of my URLs in the redirects.config file and it says it works. But then when I try going to the URL in my browser, it doesn't redirect as I've specified. In the rewritemaps.config file, I've tried putting the full domain, and I've tried with a "/" before aspx. Nothing seems to work. I'm not sure what I'm missing here.
Well I got it working. Was something stupid. In the rewritemaps.config file, I needed "/"s before the key URL. I know I had tried that before, but I must have been missing something somewhere else at the time. Oh well. It works now.
It is really hard to determine why this is failing but the best thing you can do is use Failed Request Tracing so that IIS tells you what is happening. With FREB you will get detailed tracing telling you which rules were evaluated and if they matched or they didn't and why not. You can also see the "right" patterns to match and every condition that is evaluated.
See the following link:
http://www.iis.net/learn/extensions/url-rewrite-module/using-failed-request-tracing-to-trace-rewrite-rules
I am using Docusign API to create and retrieve "envelopes" for signing. (docusign.com for more info).
Basically i am having some issues trying to adquire a SOAP trace based on their instructions https://github.com/docusign/DocuSign-eSignature-SDK/wiki/How-to-acquire-a-SOAP-trace-for-debugging-%28Windows%29
And here is where i am needing some help. Has anyone, using these intructions from Docusing support (that comes from the Microsoft page and according to one Community Comments, seems not to work) been able to create a trace?
i have tried all possible combinations and i don't see no log file created so far.
I really appreciate any help you can provide me with.
Thanks
Here's the trace config I use in my App.config for DocuSign. You'll need to clean up the log a bit (look for "<<<" and ">>>" before/after each call.
First add this to the system.serviceModel section:
<diagnostics>
<messageLogging
logEntireMessage="true"
logMalformedMessages="true"
logMessagesAtServiceLevel="true"
logMessagesAtTransportLevel="true"
maxMessagesToLog="50"
maxSizeOfMessageToLog="500000000" />
</diagnostics>
Then add this to the configuration section:
<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.Net" tracemode="protocolonly" maxdatasize="52428800" >
<listeners>
<add name="MyTraceFile"/>
</listeners>
</source>
</sources>
<sharedListeners>
<!-- Set path here. Make sure the app has permission to write to the location.-->
<add
name="MyTraceFile"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="c:\temp\DsTrace.log" />
</sharedListeners>
<switches>
<add name="System.Net" value="Verbose" />
</switches>
</system.diagnostics>
One more note, the DocuSign staff will really appreciate it if you remove the PDFBytes elements from your trace before you send it, unless that's needed for what you're having them troubleshoot.
How can I set the Secure flag on an ASP.NET Session Cookie, so that it will only be transmitted over HTTPS and never over plain HTTP?
In the <system.web> element, add the following element:
<httpCookies requireSSL="true" />
However, if you have a <forms> element in your system.web\authentication block, then this will override the setting in httpCookies, setting it back to the default false.
In that case, you need to add the requireSSL="true" attribute to the forms element as well.
So you will end up with:
<system.web>
<authentication mode="Forms">
<forms requireSSL="true">
<!-- forms content -->
</forms>
</authentication>
</system.web>
See here and here for MSDN documentation of these elements.
There are two ways, one httpCookies element in web.config allows you to turn on requireSSL which only transmit all cookies including session in SSL only and also inside forms authentication, but if you turn on SSL on httpcookies you must also turn it on inside forms configuration too.
Edit for clarity:
Put this in <system.web>
<httpCookies requireSSL="true" />
Things get messy quickly if you are talking about checked-in code in an enterprise environment. We've found that the best approach is to have the web.Release.config contain the following:
<system.web>
<compilation xdt:Transform="RemoveAttributes(debug)" />
<authentication>
<forms xdt:Transform="Replace" timeout="20" requireSSL="true" />
</authentication>
</system.web>
That way, developers are not affected (running in Debug), and only servers that get Release builds are requiring cookies to be SSL.
Building upon #Mark D's answer I would use web.config transforms to set all the various cookies to Secure. This includes setting anonymousIdentification cookieRequireSSL and httpCookies requireSSL.
To that end you'd setup your web.Release.config as:
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<system.web>
<httpCookies xdt:Transform="SetAttributes(httpOnlyCookies)" httpOnlyCookies="true" />
<httpCookies xdt:Transform="SetAttributes(requireSSL)" requireSSL="true" />
<anonymousIdentification xdt:Transform="SetAttributes(cookieRequireSSL)" cookieRequireSSL="true" />
</system.web>
</configuration>
If you're using Roles and Forms Authentication with the ASP.NET Membership Provider (I know, it's ancient) you'll also want to set the roleManager cookieRequireSSL and the forms requireSSL attributes as secure too. If so, your web.release.config might look like this (included above plus new tags for membership API):
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<system.web>
<httpCookies xdt:Transform="SetAttributes(httpOnlyCookies)" httpOnlyCookies="true" />
<httpCookies xdt:Transform="SetAttributes(requireSSL)" requireSSL="true" />
<anonymousIdentification xdt:Transform="SetAttributes(cookieRequireSSL)" cookieRequireSSL="true" />
<roleManager xdt:Transform="SetAttributes(cookieRequireSSL)" cookieRequireSSL="true" />
<authentication>
<forms xdt:Transform="SetAttributes(requireSSL)" requireSSL="true" />
</authentication>
</system.web>
</configuration>
Background on web.config transforms here: http://go.microsoft.com/fwlink/?LinkId=125889
Obviously this goes beyond the original question of the OP but if you don't set them all to secure you can expect that a security scanning tool will notice and you'll see red flags appear on the report. Ask me how I know. :)
secure - This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.