I have a wsdl (that works) and I've generated boilerplate code from it but wish to use my original wsdl not the auto generated one but on changing useOriginalwsdl to true I get errors. There is absolutely no documentation in the Axis website regarding this property so I have followed the steps here:
useOriginalwsdl=true is not working in axis2
specifically:
My services.xml has the same name as the wsdl service name
I have called my wsdl service.wsdl and put it in the META-INF folder (I also tried it with the service name)
But I get the error Unable to generate WSDL 1.1 for this service
Below is my folder structure:
.\com
.\lib
.\META-INF
services.xml
service.wsdl
My services.xml is:
<?xml version="1.0" encoding="UTF-8"?><!-- This file was auto-generated from WSDL -->
<!-- by the Apache Axis2 version: 1.6.2 Built on : Apr 17, 2012 (05:33:49 IST) -->
<serviceGroup>
<service name="MyService">
<messageReceivers>
<messageReceiver mep="http://www.w3.org/ns/wsdl/in-out" class="com.neil.systems.ServiceMessageReceiverInOut"/>
</messageReceivers>
<parameter name="ServiceClass">com.neil.webservice.MyService</parameter>
<parameter name="useOriginalwsdl">true</parameter>
<parameter name="modifyUserWSDLPortAddress">false</parameter>
<operation name="Provision" mep="http://www.w3.org/ns/wsdl/in-out" namespace="http://xmlns.neil.com/systems">
<actionMapping>http://xmlns.neil.com/systems/Provision</actionMapping>
<outputActionMapping>http://xmlns.neil.com/systems/ProvisionResponse</outputActionMapping>
</operation>
</service>
</serviceGroup>
My service.wsdl, the relevant part is:
<wsdl:service name="MyService">
Note, I changed a couple of things in the services.xml to reduce the size so any obvious errors is just down to my cutting.
Related
I am using asp.net identity and GenerateEmailConfirmationTokenAsync gives me a token for email confirmation. I cannot use this code in confirmation url, because it gets an error :
The request filtering module is configured to deny a request that contains a double escape sequence.
The solution for that issue was to allowDoubleEscaping in web.config, but how can I do it in appsettings.json? I should write this code somehow in appsettings, or in Startup.cs:
<system.webServer>
<security>
<requestFiltering allowDoubleEscaping="true"/>
</security>
</system.webServer>
It's still an IIS setting if you're running in IIS.
Create a web.Release.config file (you don't need a web.config file in your actual project) with the following:
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<location>
<system.webServer>
<security xdt:Transform="InsertIfMissing">
<requestFiltering allowDoubleEscaping="true" />
</security>
</system.webServer>
</location>
</configuration>
When you publish a release build this will get added. Very important to include the part InsertIfMissing or it will be ignored.
You DON'T need a third party package such as this. 7
See also https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/transform-webconfig?view=aspnetcore-3.1
I want to use WSO2EI 6.4.0 as a proxy for SOAP and REST services authentication platform (later maybe authorization).
I found solution in documentation of wso2 (https://docs.wso2.com/display/EI640/Applying+Security+to+an+API), but unfortunately it is not working.
Adding "handler" element into service definition
<handlers>
<handler class="org.wso2.carbon.integrator.core.handler.RESTBasicAuthHandler"/>
</handlers>
results into exception in design time (eclipse):
Invalid mediator <handler class="org.wso2.carbon.integrator.core.handler.RESTBasicAuthHandler"/> 1d6bbce1-08e3-42d5-b550-6a4e224b0028.xml /.tmp/.org.wso2.developerstudio.eclipse.esb line 15 org.wso2.developerstudio.eclipse.gmf.esb.diagram.synapseerror
Ignoring and deploying such API, makes the API stop working.
Could anyone help please?
The way you are trying to add the Basic authentication for API in WSO2EI 6.4.0 is correct. Developer studio will give a warning as you mentioned, but it should not be an issue. Developer studio will allow setting the handler regardless of the warning and you should be able to create a Composite Application which includes the API and deploy it to ESB. Following is a sample API with the RESTBasicAuthHandler.
<?xml version="1.0" encoding="UTF-8"?>
<api context="/testapi" name="testapi" xmlns="http://ws.apache.org/ns/synapse">
<resource methods="POST" protocol="https" url-mapping="/*">
<inSequence>
<send>
<endpoint name="testapi_EP">
<http uri-template="http://localhost:8080/testapi"/>
</endpoint>
</send>
</inSequence>
<outSequence/>
<faultSequence/>
</resource>
<handlers>
<handler class="org.wso2.carbon.integrator.core.handler.RESTBasicAuthHandler"/>
</handlers>
</api>
Yes, I've read the other questions on SO, MSDN, and other sites, but I found no answers as clear as I can understand. I need to set my Silverlight application's WCF references relative to the site that it's loaded from, but I can't get it to work. There is no problem with the service itself, it is working. When I move from local to my real server, I get errors in my SL app complaining about not connecting to localhost.
Here is my ServiceReferences.ClientConfig file:
<configuration>
<system.serviceModel>
<bindings>
<customBinding>
<binding name="CustomBinding_AccountManager">
<binaryMessageEncoding />
<httpTransport maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" />
</binding>
<binding name="CustomBinding_FileManager">
<binaryMessageEncoding />
<httpTransport maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" />
</binding>
<binding name="CustomBinding_SiteManager">
<binaryMessageEncoding />
<httpTransport maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" />
</binding>
</customBinding>
</bindings>
<client>
<endpoint address="http://localhost:60322/AccountManager.svc"
binding="customBinding" bindingConfiguration="CustomBinding_AccountManager"
contract="AccountManager.AccountManager" name="CustomBinding_AccountManager" />
<endpoint address="http://localhost:60322/FileManager.svc" binding="customBinding"
bindingConfiguration="CustomBinding_FileManager" contract="FileManager.FileManager"
name="CustomBinding_FileManager" />
<endpoint address="http://localhost:60322/SiteManager.svc" binding="customBinding"
bindingConfiguration="CustomBinding_SiteManager" contract="SiteManager.SiteManager"
name="CustomBinding_SiteManager" />
</client>
</system.serviceModel>
</configuration>
Yes, I will optimize the buffer/message sizes and I know the possible DoS exploits, forget about it for now, I need them for big file transfers. An approach I tried is while instantiating the clients, I've used this code:
fileManager = new FileManagerClient(new BasicHttpBinding(), new EndpointAddress("http://" + Settings.Host + "/FileManager.svc"));
accManager = new AccountManagerClient(new BasicHttpBinding(), new EndpointAddress("http://" + Settings.Host + "/AccountManager.svc"));
where Settings.Host is my own method which returns me the host that the SL app is running from, tested, works. When I uploaded my XAP and tried, it still wanted to go for http://localhost:60322/AccountManager.svc, after further investigation, I've realized that there are still lots of references to localhost, in unseen files:
AccountManager.disco:
<?xml version="1.0" encoding="utf-8"?>
<discovery xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/disco/">
<contractRef ref="http://localhost:60322/AccountManager.svc?wsdl" docRef="http://localhost:60322/AccountManager.svc" xmlns="http://schemas.xmlsoap.org/disco/scl/" />
</discovery>
Parts of AccountManager.wsdl:
... <wsdl:import namespace="" location="http://localhost:60322/AccountManager.svc?wsdl=wsdl0" />...
...[lots of operation declarations]...
<wsdl:service name="AccountManager">
<wsdl:port name="CustomBinding_AccountManager" binding="tns:CustomBinding_AccountManager">
<soap12:address location="http://localhost:60322/AccountManager.svc" />
<wsa10:EndpointReference>
<wsa10:Address>http://localhost:60322/AccountManager.svc</wsa10:Address>
</wsa10:EndpointReference>
</wsdl:port>
</wsdl:service>
Part of AccountManager1.xsd:
<xs:import schemaLocation="http://localhost:60322/AccountManager.svc?xsd=xsd2" namespace="http://schemas.datacontract.org/2004/07/Leftouch.Data.Summary" />
Part of configuration.svcinfo:
<endpoint normalizedDigest="<?xml version="1.0" encoding="utf-16"?><Data address="http://localhost:60322/AccountManager.svc" binding="customBinding" bindingConfiguration="CustomBinding_AccountManager" contract="AccountManager.AccountManager" name="CustomBinding_AccountManager" />" digest="<?xml version="1.0" encoding="utf-16"?><Data address="http://localhost:60322/AccountManager.svc" binding="customBinding" bindingConfiguration="CustomBinding_AccountManager" contract="AccountManager.AccountManager" name="CustomBinding_AccountManager" />" contractName="AccountManager.AccountManager" name="CustomBinding_AccountManager" />
Part of Reference.svcmap:
</ClientOptions>
<MetadataSources>
<MetadataSource Address="http://localhost:60322/AccountManager.svc" Protocol="http" SourceId="1" />
</MetadataSources>
<Metadata>
<MetadataFile FileName="AccountManager2.xsd" MetadataType="Schema" ID="e473b2d5-7af3-4390-87c3-a4fc3f54fb96" SourceId="1" SourceUrl="http://localhost:60322/AccountManager.svc?xsd=xsd2" />
<MetadataFile FileName="AccountManager1.xsd" MetadataType="Schema" ID="fd3a1ae0-b38b-4586-8622-5b0ee07e39fb" SourceId="1" SourceUrl="http://localhost:60322/AccountManager.svc?xsd=xsd0" />
<MetadataFile FileName="AccountManager.xsd" MetadataType="Schema" ID="6a49ee64-6eac-40e2-bcff-26418435e777" SourceId="1" SourceUrl="http://localhost:60322/AccountManager.svc?xsd=xsd1" />
<MetadataFile FileName="AccountManager.disco" MetadataType="Disco" ID="9ec9a8cc-0cf0-4264-a526-b5a6c08f7d36" SourceId="1" SourceUrl="http://localhost:60322/AccountManager.svc?disco" />
<MetadataFile FileName="AccountManager1.wsdl" MetadataType="Wsdl" ID="54a5b2c0-9d0e-4043-a7e4-d27ae6674bfc" SourceId="1" SourceUrl="http://localhost:60322/AccountManager.svc?wsdl=wsdl0" />
<MetadataFile FileName="AccountManager.wsdl" MetadataType="Wsdl" ID="f8923013-3a6c-412b-b7da-bee5a5a7bb64" SourceId="1" SourceUrl="http://localhost:60322/AccountManager.svc?wsdl" />
..and ALL these again for other 2 services too.
I am not a master of web services/bindings/endpoints/operation contracts or any related stuff. I just want to make my totally already-nice-working (when URI is hardcoded) system work for relative URIs, that's all I need. There must be a simple solution. Can someone explain what exactly those file types and declarations resemble, which are important and which are optional, and how can I create dynamic service references in the cleanest form. Please, with explanations. I've already seen lots of posts and articles about dynamic service bindings and references, but honestly, everything gets messed up and I end up not understanding anything from it. Any constructive criticism and solutions are welcome.
Is the config file for your service (not the client) using endpoints with fully qualified addresses (like your client config)? If so, the reason you're seeing all those localhost references is because when you add the service reference, it's going to carry through that address in the generated files.
Update the endpoint in your service config file to either use the fully qualified address on that machine (i.e., http://somname.com/service.svc), or set the baseAddresses in the config file to the machine name.
Additionally, if you're using WCF 4.0 (VS 2010/.NET 4.0), you can have WCF create a default endpoint for your service(s) by ommitting the endpoints from the config file altogether (as I understand it - we're just moving to 4.0 at work now, so I haven't played with the new features).
EDITED TO ADD
New approach, same basic idea (that the URI is being imported from somewhere). Based on your comments below, it sounds like your service's config is set up fine, with no hard-coded URIs pointing to localhost.
When you move your application to the target server(s), are you updating your reference to your service (via the Add Service Reference) as well, or simply moving the files that generates from your local box to the target server?
If you are, I'm wondering if that might be the source of your problem. I would think that specifying the service address when you create the client should override anything in the WSDL-related files, but maybe its not.
Something to try:
Delete the <client> section from your Web.config. Then, when you create the client, do so like this:
fileManager = new FileManagerClient(new BasicHttpBinding("CustomBinding_FileManager"), new EndpointAddress("http://" + Settings.Host + "/FileManager.svc"));
Make sure you pass in the name of the binding configuration section in the BasicHttpBinding constructor, otherwise you'll get the binding with the default values, not the larger values you specified.
The idea here is to eliminate any chance that the client config file settings are overriding what you're passing in on the FileManagerClient creation.
I'd consider it less than ideal to have to update the service reference for every deployment to each individual server - what you're trying to accomplish makes sense. I do something similar in an n-tier app I've written - the only difference is that I don't use service references, I generate the proxy via SvcUtil and then generate channels via ChannelFactory<T>, which is another route you might want to look at.
If none of this help, please feel free to e-mail me (my e-mail address is in my profile) - it might be easier to figure this out via e-mail exchange and then post the final solution.
Can I use NLog in a WCF Service? I am trying to but cannot get it to work.
First I set up a simple configuration in a Windows Forms application to check that I was setting up correctly and this wrote the log file fine (I am writing to a network location using name and not IP address).
I then did exactly the same thing in the WCF Service. It did not work.
To check permissions I then added some code to use a TextWriter.
TextWriter tw = new StreamWriter(fileName);
tw.WriteLine(DateTime.Now);
tw.Close();
This worked OK so I know I can write to the location.
Check that your NLog.config file is in the same directory as your .svc file and NOT the Bin directory.
If you've just added the config file to the WCF project, then published it you will probably find your config file has been copied to the bin directory which is why NLog can't find it. Move it to up a level then restart the website hosting the service (to make sure the change is picked up).
This had me stumped for a while this morning!
Put your NLog config in the web.config file. Like so:
<?xml version="1.0"?>
<configuration>
<configSections>
<section name="nlog" type="NLog.Config.ConfigSectionHandler, NLog"/>
</configSections>
. . . (lots of web stuff)
<nlog>
<targets>
<target name="file" xsi:type="File" fileName="${basedir}/logs/nlog.log"/>
</targets>
<rules>
<logger name="*" minlevel="Trace" writeTo="file" />
</rules>
</nlog>
</configuration>
See my comment to your original question for how to turn on NLog's internal logging.
To turn on NLog's internal logging, modify the top of you NLog config to look like this:
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.mono2.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
autoReload="true"
internalLogLevel="Trace"
internalLogFile="nlog_log.log"
>
The key parts are internalLogLevel and internalLogFile.
You can also set internalLogToConsole to true or false to direct the internal logging to the console.
There is another setting, throwExceptions, that tells NLog whether or not to throw exceptions. Ordinarily, this is set to false once logging is successfully configured and working. You can set it to true to help determine if your problem is due to an NLog error.
So, if you had all of those options enabled, the top of your NLog configuration might look like this:
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.mono2.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
autoReload="true"
internalLogLevel="Trace"
internalLogFile="nlog_log.log"
internalLogToConsole="true"
throwExceptions="true"
>
My first guess is that NLog is not finding the config information. Are you using an external config file (NLog.config) or "inline" configuration (in your app.config or web.config)? In your project, is(are) your config file(s) marked (in Properties) as Copy Always?
I am trying to add a web service reference to my C# application in Visual Studio. The web service is hosted on Sun's GlassFish server. Unfortunately Visual Studio produces the following warning when I try to add the service reference:
Custom tool warning: The following Policy Assertions were not Imported:
XPath://wsdl:definitions/wsdl:binding[#name='SecurityWebServicePortBinding']/wsdl:operation[#name='RegisterUser']
Assertions:
<wsat:ATAlwaysCapability xmlns:wsat='http://schemas.xmlsoap.org/ws/2004/10/wsat'>..</wsat:ATAlwaysCapability>
Apparently it cannot understand policy assertions in the WSDL published by the GlassFish server. Here's an excerpt from the WSDL:
<?xml version='1.0' encoding='UTF-8'?>
<definitions
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://test/securityservice.wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/"
targetNamespace="http://test/securityservice.wsdl"
name="SecurityService">
<wsp:Policy xmlns:wsat="http://schemas.xmlsoap.org/ws/2004/10/wsat" wsu:Id="SecurityWebServicePortBinding_AuthenticateUser_WSAT_Policy">
<wsat:ATAlwaysCapability />
<wsat:ATAssertion xmlns:ns1="http://schemas.xmlsoap.org/ws/2002/12/policy" wsp:Optional="true" ns1:Optional="true" />
</wsp:Policy>
<wsp:Policy xmlns:wsat="http://schemas.xmlsoap.org/ws/2004/10/wsat" wsu:Id="SecurityWebServicePortBinding_RegisterUser_WSAT_Policy">
<wsat:ATAlwaysCapability />
<wsat:ATAssertion xmlns:ns2="http://schemas.xmlsoap.org/ws/2002/12/policy" wsp:Optional="true" ns2:Optional="true" />
</wsp:Policy>
...
<binding name="SecurityWebServicePortBinding" type="tns:SecurityWebService">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
<operation name="RegisterUser">
<wsp:PolicyReference URI="#SecurityWebServicePortBinding_RegisterUser_WSAT_Policy" />
<soap:operation soapAction="RegisterUser" />
<input>
<wsp:PolicyReference URI="#SecurityWebServicePortBinding_RegisterUser_WSAT_Policy" />
<soap:body use="literal" />
</input>
<output>
<wsp:PolicyReference URI="#SecurityWebServicePortBinding_RegisterUser_WSAT_Policy" />
<soap:body use="literal" />
</output>
<fault name="UsernameExistsException">
<soap:fault name="UsernameExistsException" use="literal" />
</fault>
</operation>
</binding>
...
</definitions>
If I remove all the policy elements from the WSDL, Visual Studio is able to consume the service without any problems (in fact earlier I used to write the WSDL by hand and never put the policy statements). So my questions are:
Why is GlassFish insisting on adding the policies? Is there any way to suppress them?
Why is Visual Studio not able to consume the WSDL with the policies?
ws-AT (Atomic Transactions) seems to be part of the SOAP specification which WCF does not know about.
There is some information here - http://schemas.xmlsoap.org/ws/2004/10/wsat/
Update: Actually WCF is aware of the ws-AT spec, but doesn't support it fully (http://schemas.xmlsoap.org/ws/2004/10/wsat/). I suppose this is because WCF has alternatives which use OleTransactions.
Ok, I figured out why GlassFish is adding the ws-AT policies. My web service is being generated using an EJB (see below):
#Stateless
#WebService
public class SecurityWebService {
...
}
Since the default transaction attribute for a stateless EJB method is REQUIRED, GlassFish is making the web service method transactional too (see here for details). Not the behavior I want, but that's how it is!