Adquiring a SOAP trace for debugging is not woking - soap

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.

Related

fontawsome-webfont.woff not found error in deployed Orchard CMS website

I use Orchard CMS 1.10.1. In the layout.cshtml file of current theme, I added these:
Style.Require("bootstrap");
Style.Require("fontawesome");
and the web.config file of Orchard.Web contains these:
<staticContent>
<remove fileExtension=".svg" />
<mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
<remove fileExtension=".woff" />
<mimeMap fileExtension=".woff" mimeType="application/font-woff" />
<remove fileExtension=".woff2" />
<mimeMap fileExtension=".woff2" mimeType="font/woff2" />
</staticContent>
In my machine there was no problem but when I deployed this on server I get these errors in browser console:
Get http://x.com/Themes/y/fonts/fontawesome-webfont.woff2?v=4.3.0
GET http://x.com/Themes/y/fonts/fontawesome-webfont.woff?v=4.3.0
GET http://x.com/Themes/y/fonts/fontawesome-webfont.ttf?v=4.3.0 404 (Not Found)
What might cause this problem?
You need a <clear/> as first element inside static handlers before first <remove..../> and add a ttf handler as well

Installing multiple Quartz.NET services on one machine

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.

Modifying web.config with powershell to have smtp section

I'm trying to modify the web.config with powershell to add a smtp section. I saw this post :
http://ybbest.wordpress.com/2012/02/28/how-to-add-configuration-settings-using-spwebconfigmodification-and-powershell-script/#comment-1070
which add some appsettings defining smtp section. But I want to know if these line:
<add key="businessSupportEmailAddress" value="contosointergenfax#gmail.com" />
<add key="copyMoveTempFolder" value="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS\SharePointProducts" />
<add key="faxEmailAddress" value="contosointergenfax#gmail.com" />
<add key="fromEmailAccount" value="contosoAdmin" />
<add key="fromEmailAddress" value="contosointergenfax#gmail.com" />
<add key="smtpServerName" value="build.contoso.local" />
<add key="smtpServerPort" value="25" />
are the same as this :
<system.net>
<mailSettings>
<smtp deliveryMethod="Network" from="testuser#domail.com">
<network defaultCredentials="true" host="localhost" port="25" userName="kaushal" password="testPassword"/>
</smtp>
</mailSettings>
</system.net>
Thanks
Nope.
First block represents key,value pairs that will be loaded in the default hash by the Configuration Manager (appSettings, see http://odetocode.com/Articles/345.aspx).
The other one is the .NET system config for mailing, mostly used in ASP webapps : http://msdn.microsoft.com/en-US/library/w355a94k.aspx
Thanks for visiting my blog and my solution is specific to a SharePoint project we are working on.In the end we actually end up putting the configuration settings into a list as we need the SharePoint timer job to access the configuration settings too.
If your solution is asp.net application , you should use the latter.

403.14 and defaultDocument

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>

How can I set the Secure flag on an ASP.NET Session Cookie?

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.