Can anyone suggest a quick way to tell Elmah not to use the email handler for local requests?
i.e. when Request.IsLocal == true I don't want to receive an email every time I generate an exception. Alternatively, a way to simply disable elmah altogether for local requests would be good.
I'd prefer an answer that doesn't require that I use a different Web.config locally than I use in production.
You can configure error filtering in ELMAH and express conditions for when an exception should be filtered/excluded from logging and/or mailing. The following error filter should help you to filter out exceptions (as far as ELMAH is concerned) occurring on local requests:
<errorFilter>
<test>
<equal binding="Context.Request.IsLocal"
value="True" type="Boolean" />
</test>
</errorFilter>
For more details, see the wiki on Error Filtering and examples on the ELMAH project site.
Related
I am developing a Web service using Apache CXF and contract first approach with schema validation. Problem is, that validation is not working. There is no error, so it like is not activated. But validation is configured.
So, I have took a look to official Apache CXF examples you can find here.
I took a look to wsdl_first example and modify it adding schema validation and some restriction in WSDL:
<!-- HTTP Endpoint -->
<jaxws:endpoint xmlns:customer="http://customerservice.example.com/"
id="CustomerServiceHTTP" address="http://localhost:9090/CustomerServicePort"
serviceName="customer:CustomerServiceService" endpointName="customer:CustomerServiceEndpoint"
implementor="com.example.customerservice.server.CustomerServiceImpl">
<jaxws:features>
<bean class="org.apache.cxf.feature.LoggingFeature" />
</jaxws:features>
<!-- schema validation-->
<jaxws:properties>
<entry key="schema-validation-enabled" value="true" />
</jaxws:properties>
</jaxws:endpoint>
To my surprise, it doesn't work either.
OK, so I took a look to wsdl_first_xmlbeans example, where according with the README.txt file, it also shows how CXF configuration can be used to enable schema validation.
And for this example, schema validation works. The difference between both examples is that the second one use JAX-WS APIs and with the XMLBeans approach. Does it have something to do? Why schema validation is not working for first example? Probably, I am missing something.
For validation on the service side, it would likely need to have a wsdlLocation attribute set on the jaxws:endpoint so it would load the WSDL (that would then contain the schemas). Currently, the validation in that example is on the client side only. If you run the service, the log shows:
INFO: Creating Service {http://server.customerservice.example.com/}CustomerServiceImplService from class com.example.customerservice.CustomerService
which shows it's not using the WSDL at all.
I cant get my Webservice published, it should be simple:
I create the app in the IIS,
place it as a 4.0 Classic .Net
I publish it from .Net Solution within VS2012 Right click and publish
on the Webservice project.
The files are placed and it should show by itself on the browser on the URL of the server specified.
But I stumbled upon the following problems:
HTTP Error 404.17 - Not Found
The requested content appears to be script and will not be served by the static file handler.
So I've looked for It and found this two options:
Option 1:
http://www.banmanpro.com/support2/Requested_Content_Appears_to_be_Script.asp
This one says I should go to Integrated, instead of Classic App Pool. but it's like if I changed a problem for another because now it says:
HTTP Error 500.21 - Internal Server Error
Handler "WebServiceHandlerFactory-Integrated" has a bad module "ManagedPipelineHandler" in its module list
When I go to the web config see what is this error talking about I see no handler tag!
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appSettings />
<connectionStrings />
<system.web>
<compilation targetFramework="4.0" />
<!--
The <authentication> section enables configuration
of the security authentication mode used by
ASP.NET to identify an incoming user.
-->
<authentication mode="Windows" />
<!--
The <customErrors> section enables configuration
of what to do if/when an unhandled error occurs
during the execution of a request. Specifically,
it enables developers to configure html error pages
to be displayed in place of a error stack trace.
<customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">
<error statusCode="403" redirect="NoAccess.htm"/>
<error statusCode="404" redirect="FileNotFound.htm"/>
</customErrors>
-->
<pages controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID" />
</system.web>
<system.webServer>
<directoryBrowse enabled="true" />
</system.webServer>
<!--
The system.webServer section is required for running ASP.NET AJAX under Internet
Information Services 7.0. It is not necessary for previous version of IIS.
-->
</configuration>
Should I add one? If so, how?
Option 2:
Script not served by static file handler on IIS7.5
Basically it says I shoud do a aspnet_regiis -i, but when I try
going to %windir%\Microsoft.NET\Framework\v4.0.30319
Even when the folder exists, There is no aspnet_regiis!!
I've only found the aspnet_regiis on the 2.0 Fwk =(
Is that normal?
The handler tag wasn't the answer, however, both options drove me to look for the missing aspnet_regiis of fwk 4.
There was no aspnet_regiis because the full fwk 4.0 wasn't actually installed on a first place.
I had installed on the server the Framework 4 Client Profile and the debugger, which isn't the full version. From now on, whenever I think I have fwk 4 installed, I'll check twice.
After installing it, on Framework 4.0 Classic Pipeline Mode (instead of Integrated) made it work just fine.
But Attention!
After installing the framework, IIS will change the default pipeline to 4.0, that means, if you had ongoing a web(site/service) on 2.0 it will automatically stop working. (It happened to me)
I am trying to program a VisualWebPart using Visual Studio 2010 which has to do a simple thing: invoke a web service (hosted in a remote server, NOT locally). When I execute within the Sharepoint site (version 2010, which I have published in my IIS) I get this error:
"The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'NTLM'."
Pardon my ignorance, but the only difference here is the case of the Ntlm authentication scheme! I have been all over the web and found many related problems, but none of the solutions worked. Almost ALL solutions i found involve modifications in the webservice security configuration, this is not an option for me.
Looking for a solution, I created a sample windows form and invoked the web service from it: no problems whatsoever.
In order to be able to invoke the webservice correctly this is the necessary security configuration:
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm" proxyCredentialType="Ntlm" realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
I believe the problem is that I haven´t been able to properly set this security property to the web.config of my Sharepoint site, since I tried to put it in the security tag that appears in the web.config but still get the same error.
Any further information needed please ask, I am REALLY desperate, for days I have been with the SAME error.
In the end I was given permissions in their server: more precisely in the database which was the one that wouldn't let me create the web part in the server. Once this was done, the call to the webservice worked just fine, because they have the web.config correctly configured.
We have a site running on MOSS 2007 which makes calls to custom web service asmx methods on the same domain from the client.
On the live site requests are getting redirected to the following url:
http://[domain]/_layouts/error.aspx?ErrorText=Request format is unrecognized for URL unexpectedly ending in %27%2FIsSuspectWaterLevel%27.
We've added the following to the sites web.config without any joy:
<system.web>
<webServices>
<protocols>
<add name="HttpSoap" />
<add name="HttpGet" />
<add name="HttpPost" />
</protocols>
</webServices>
...
</system.web>
Interestingly enough we don't have this issue on the test server which is supposed to be pretty identical to the live server.
Any ideas to what other variable might be at play here?
Thanks in advance for any ideas,
Gavin
Update:
While a call to
http://[Domain]/_vti_bin/Custom/CustomFunctionality.asmx/IsSuspectWaterLevel
fails, I can still access
http://[Domain]/_vti_bin/Custom/CustomFunctionality.asmx?op=IsSuspectWaterLevel
though it fails when I invoke the method in the same way.
I wonder if this helps shed more light on the issue?
Another Update:
I've just observed the same error on the dev server. Removing the apps dll from GAC and then re-copying it in solved the issue. The live server tested fine with initial deployment so perhaps there's an issue with Sharepoint loosing some reference over time? Clutching at straws as very confusing behaviour!
Yet Another Update:
It seems everytime I touch (open and save) the web.config file in 12 Hives the problem is fixed again for a period, but after a while the problem comes back. I wonder if it's anything to do with the app pool being recycled?
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\ISAPI\web.config
An inelegant workaround to this issue that works for us: We've swapped out the web service asmx end point for a web handler ashx endpoint. This doesn't suffer the same issue for some reason.
I'm guessing from this that there's some issue creeping in after a period of time which is causing urls to resolve incorrectly. I suspect that the / after the .asmx in the url is the curprit. The ashx endpoint implemented is working purely on url parameters and posted data.
Obviously this work around won't always be an option for others who might experience the same issue as we're loosing a lot of the rich web service functionality that's pre-baked in to an asmx endpoint.
Unfortunately I won't be able to test any other solutions that people might put forward from now on as we've moved away from the web service asmx approach. Sorry.
I have a C# .net webservice that I need to restrict access to. I already require my consumers to use a username and password to call the service. But, is there a way to restrict access to the actual asmx page and the WSDL? I would need to restrict access to the webservice by username/password and IP address. If a user did not have the correct credentials, I would not want them to know what webmethods exist in the webservice.
Can this be done though IIS? I know that I can restrict IP addresses through IIS, but can I also use usernames/passwords?
Is there any other way to do this outside of IIS, maybe using C#.net?
Well, since it's ASMX you have the entire ASP.NET runtime stack at your disposal.
Step #1 - managing the resource through .config
Apply a <location> tag for the resources you want secured. Assuming it's a single ASMX file you can simply do the following in your web.config:
<location path="MyWebService.asmx">
<system.web>
<!-- resource specific options will go here -->
</system.web>
</location>
Step #2 - authenticating your users
You need to decide how you're actually going to authenticate users. There are several ways to do this and several authentication standards you could leverage. You need to pick the approach that's the right fit for you.
If you're on an intranet and are using Windows authentication I would highly suggest leveraging that because it's truly the simplest option to get setup. However, if your services are being accessed over the internet then Windows authenticatio is not really an option and you need to choose from a web standard. The simplest of those is Basic Authentication, but you should only use this over SSL since the username/password are not encrypted (only base64 encoded). The next step up from that is Digest authentication which doesn't require SSL because the username/password are sent using an MD5 hash. For the ultimate you can go with SSL v3 where you issue a specific client certificate to each user of your API.
Now, which option you select for security dictates what else needs to be done. If you choose Windows security, it's as easy as adding the following element to the <system.web> element we started with in Step #1:
<authentication mode="Windows" />
The remainder of the security protocols are going to require a little more work. ASP.NET doesn't provide intrinsic support for Basic, Digest or SSL v3. Technically you can leverage IIS to do this type of authentication for you, but it's always going to map to a Windows user. If that's an option for you, then simply leave the <authentication mode="Windows" /> element and configure IIS accordingly. If, however, that is not an option, either because you simply have no control over IIS/ActiveDirectory or you need to authenticate against a custom user database, then that means that you need to hook up a custom HttpModule to provide support for these security protocols.
Step #3 - securing the resource
The simplest approach to securing the resource is to basically say: "don't let anyone who hasn't successfully authenticated in some way into this resource". This is done using the following authorization configuration:
<authorization>
<deny users="?" />
</authorization>
If you wanted to only allow certain users you could change to do the following instead:
<authorization>
<deny users="*" />
<allow users="jdoe, msmith" />
</authorization>
Another approach is to define roles (groups) and simply lock the resource down to a special role which you put the users who you want to access the resource into.
<authorization>
<deny users="*" />
<allow roles="My Service Users" />
</authorization>
This maps well to Windows authentication because you can just setup a Windows group and let your MIS team manage which users are in that group using ActiveDirectory. However, the feature also works just fine for non-Windows authentication assuming the security implementation you've used exposes roles via its IPrincipal implementation.
I don't know how practical this is for you, but you could consider upgrading to WCF. WCF is fully backward compatible with ASMX web services, and lets you control whether or not the WSDL is exposed by defining a MEX (metadata exchange) endpoint. No MEX endpoint, no WSDL.
You can stop WSDL being shown by removing the Documentation protocol from the element in Machine.config
Update:
Web Services authentication - best practices?
If your users have usernames/passwords you can use HTTP basic authentication via HTTPS.
You can also implement it in a slightly differnt way. The first call to your web service should be the authentication method. Client authenticates and receives an authentication token. This token should be presented to all other methods exposed by your web service.
Two options: Create an entirely different site on a different port with locked down permissions. This has the advantage of providing some amount of "security through obscurity" (half joking...) Or you can add a new Application under your site(same port, different path), on a different app pool and assign permissions that way.
In either case, your web service isn't going to be able to talk with the various ASP.NET "things" like the application object (well it will, but it won't be the same one). Deployment is only slightly harder: deploy the same binaries, but only include the one web service file.
You can authenticate using an HttpModule.
SSL + BasicAuthentication should yield the best interop with other tool chains.
In the HttpModule, you have access to the request and can deny unauthenticated users access to just .asmx requests. And even then you might let them access the WSDL.
Add <add path="*.asmx" verb="*" type="System.Web.HttpForbiddenHandler" validate="True" /> to the <httpHandlers> section of the web.config file