WSO2 ESB Proxy using registry resource has invalid schema references - xsd

I am trying to publish a SOAP service registered in the Governance Registry through a proxy in WSO2 ESB. I get an error saving the proxy due to an incorrect schema location of the resources referenced in the WSDL.
In particular I get:
Caused by: javax.wsdl.WSDLException: WSDLException (at /wsdl:definitions/wsdl:types/xsd:schema): faultCode=PARSER_ERROR: Problem parsing '../../../../schemas/org/tempuri/1.0.0/TestSoap1.xsd'.: java.io.FileNotFoundException: /../schemas/org/tempuri/1.0.0/TestSoap1.xsd (No such file or directory)
When I search the WSDL in the Governance Registry the imported schemas have a location pointing to a relative path using "../../../{xsd name}", obviously the cause of the error. The solution seems to be to remap all the schemas locations to the registry internal keys (aka gov:/trunk/... and so on).
This behaviour does not make sense for me. The integration between ESB and GREG should be useful to use previously GREG imported WSDL when creating proxies. Am I missing something?

When you select a registry resource with dependencies, you need to specify them within the proxy service you are building. In the following example I show you the configuration that you need to perform in a proxy based on a WSDL that has an XSD as a dependency, and both are registered in the GREG.
<publishWSDL key="gov:/trunk/wsdls/org/example/www/util/auditoria/1.0.0/Auditoria.wsdl">
<resource key="gov:/trunk/schemas/org/example/www/util/auditoria/1.0.0/Auditoria.xsd"
location="../../../../../../../schemas/org/example/www/util/auditoria/1.0.0/Auditoria.xsd"/>
</publishWSDL>

Related

Can't call external API from Swagger UI inside Gitlab. Error with Content Security Policy

I’m trying to use an OpenAPI file into GitLab (which runs the UI for my file) but when I use the feature Try Out/Execute from Swagger UI (which sends a request to an external API) I get an error with Content Security Privacy.
My OpenAPI works on Swagger Editor online, and in Gitlab don’t. I think that I need to set this external URL but I have no idea where to do it. Maybe something in my OpenAPI code? Or a setting in GitLab?
The error:
Just change a file name to:
openapi.yaml

Azure API Management Import API always says: API with specified name already exists

I am trying to import an API I have into Azure API Management using swagger, should be fairly simple but I always get the same error:
One or more fields contain incorrect values: API with specified name
already exists
I do not have ANYTHING setup in Azure API management yet, very frustrating.
UPDATE
I am using Swashbuckle (https://github.com/domaindrivendev/Swashbuckle) to add Swagger to my WebAPI project.
It is generating Swagger 2.0 docs.
Here is the info element of the Swagger Doc:
swagger: "2.0",
info: {
version: "v3",
title: "ShopZioAPIv3"
},
It does not matter what I change that to, I still always get:
One or more fields contain incorrect values: API with specified name
already exists
I my case the title {"info":{"title": "API-NAME",... in the Swagger file did not match the name of the selected API (because we had created several test APIs).
Simply changing the string value fixed it.
That error message appears when you don't specify a unique API prefix.
I realize that you said that you don't have anything already already setup in the API however, if you could try putting some unique value in this field:
An API Management service instance is designed to host multiple APIs, so the prefix is used to differentiate between the APIs by using the first part of the path.
The subdomain part of the URL is used to identify the service. e.g.
http://{servicename}.azure-api.net{/api-prefix}/path/segment?param=value
Update
Based on the provided Swagger, the problem comes from multiple operation objects with the same OperationId. This is invalid swagger.
Usually Swashbuckle will fail before generating operations with duplicate Ids. There is a ResolveConflictingActions method that allow you to put your own code to deal with these cases. It seems like in this case the resolution code is not doing the right thing.
The Azure API Management error, "API with specified name already exists," can be misleading, and in this case, it is inaccurate.
As discussed in Darrel Miller's answer, invalid Swagger can cause this issue. Although multiple operation objects with the same OperationId is invalid in Swagger 2.0, I think the core issue you are having is that Azure API Management does not yet support Swagger 2.0 (as of Dec 1, 2015).
Swashbuckle 5+ generates only Swagger 2.0 so some,if not all, definitions generated with it will fail with this error -- even well-formed Swagger definitions validated by http://editor.swagger.io, which also seems to only support Swagger 2.0.
Swashbuckle 4.2 supports generating Swagger 1.2 definitions.
Also, I was able to take my Swagger 2.0 definition (generated by Swashbuckle 5), and convert it to Swagger 1.2 using Restlet Studio.

Failing example in openam: exception.name = java.lang.NullPointerException

So I'm following the documentation listed here:
to create a user:
curl "http://localhost:2020/openam/identity/create?
admin=AQIC5wM2LY4SfczmNJCUo6W4qZZmJe8r46C0tWGQ7ZexXUU.*AAJTSQACMDIAAlNLAAoxNzk1NTIyMDEwAAJTMQACMDE.*
&identity_name=testuser
&identity_attribute_names=cn
&identity_attribute_values_cn=Test%20User
&identity_attribute_names=sn
&identity_attribute_values_sn=User
&identity_attribute_names=userpassword
&identity_attribute_values_userpassword=secret12
&identity_realm=%2F
&identity_type=user"
I'm getting a really strange response:
exception.name=java.lang.NullPointerException
what could be happening and how might I debug such an error?
I just tested your call and it works fine for me on OpenAM 11.0.0 so I guess you have some issue with your data store configuration. You may check the deployment container log for exception. Furthermore set debug level to 'message' in OpenAM and have a look in IdRepo debug log. Make sure you understand OpenAM data store / IdRepo and notice that OpenAM is not considered to be an IdM /provisioning tool as IdM only works under limited use-cases. OpenAM is not a web-based frontend to an LDAP Directory Server, IdRepo can be virtually any backend system like an SAP HR system.

How do you specify the deployIisAppPath to a site root that is not DefaultWebSite?

I have a ASP.NET MVC web application project that I want to deploy to my IIS webserver. The site tree is set up thusly:
SERVERNAME(myDomain\Username)
Application Pools
Sites
Default Web Site
MyProjectSite
bin
Content
...
Views
I am trying to deploy to the MyProject site. See below settings that I am using versus the errors I am returning. I am apparently not specifying my site path correctly, but for the life of me, I can't figure out what it should be.
The following settings stay the same between iterations:
/p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:CreatePackageOnPublish=False /p:MSDeployPublishMethod=WMSvc /p:AuthType=Basic /p:Username="myUserName" /p:Password="MyPassword" /p:AllowUntrustedCertificate=True
Specify SiteName/ as IISAppPath:
Parameters:
/p:MsDeployServiceUrl="https://serverName:8172/MsDeploy.axd?Site=MyProjectSite" /p:DeployIisAppPath="MyProjectSite/"
Error:
Could not complete an operation with the specified provider ("createApp") when connecting using the Web Management Service - I don't want to create a new site. I want to sync the content that is already there.
Specify IISAppPath as Root (supposing that the sitename in the URL is used)
Parameters:
/p:MsDeployServiceUrl="https://serverName:8172/MsDeploy.axd?Site=MyProjectSite" /p:DeployIisAppPath="/"
Error:
Could not complete an operation with the specified provider ("iisApp") when connecting using the Web Management Service - Looks like it is trying to access the Default WebSite or something (to which I have purposefully NOT given myself rights).
Specify IISAppPath as empty string(supposing that the sitename in the URL is used)
Parameters:
/p:MsDeployServiceUrl="https://serverName:8172/MsDeploy.axd?Site=MyProjectSite" /p:DeployIisAppPath=""
Error:
The "ConcatFullServiceUrlWithSiteName" task was not given a value for the required parameter "SiteAppName" - So it interprets "" as actually a null value thus breaking an attempt to concatenate it.
Specify no site attribute in the URL but SiteName/ as IISAppPath
Parameters:
/p:MsDeployServiceUrl="https://serverName:8172/MsDeploy.axd" /p:DeployIisAppPath="MyProjectSite/"
Error:
Could not complete an operation with the specified provider ("createApp") when connecting using the Web Management Service
Specify no site attribute in URL but SiteName as IISAppPath
Parameters:
/p:MsDeployServiceUrl="https://serverName:8172/MsDeploy.axd" /p:DeployIisAppPath="MyProjectSite"
Error:
Could not complete an operation with the specified provider ("createApp") when connecting using the Web Management Service
Now given that it is running a concatenate on the SiteAppName, it must be combining it with the Site name, yes? What are you supposed to put there to get the site to sync to the root of a site?
Update
In an attempt to figure out the proper path scheme, I have tried to publish using the Visual Studio 2012 Publish dialog. In this case, I am returned an error saying that The request timed out (testing the connection works almost instantly and previewing the changes works but takes a few seconds). I checked the event log, and the tracelog for wmsvc to no avail. Even with trace set to verbose, nothing shows up in the tracelog. I have tried disabling the firewalls on both computers, and nothing seems to work on that front either.
Figured this one out.
The problem stemmed from two settings in the Web Deploy page of the project properties. I had previously set this project up (in the Debug configuration) to copy only the files necessary to run the application, and NOT build a zip package. I neglected however to do anything to those settings for the release configuration.
The reason (confidence level 75%) it was trying to use createApp was because it was deploying from the Zip package it had created. So my IISAppPath settings in those cases were fine, I was just deploying the wrong thing.
I set the Create deployment package as a zip file setting to false, and the Items to deploy dropdown to Only files needed to run this application and everything went off without a hitch.
Incidentally I found out (as referred above) that you can use the Publish Profiles outputted by the Web Publish dialog in Visual Studio (2012 only unfortunately; 2010 you have to do some massaging that I am unsure of). I named mine with no spaces, and supplied the password as an argument as well as the Untrusted Certificate setting. Now MSBuild Arguments in the build definition for TFS look like this:
/p:DeployOnBuild=True;PublishProfile=NameOfPublishProfile /p:AllowUntrustedCertificate=True /p:Password=PleaseVerifyMe

Linqpad Can't connect to Sharepoint

I am trying to create a LinqPad connection to a SharePoint Server's List Services. I have selected WCF Data Services 5.1 (OData 3) as the data context and http://sharepoint.host.com/_vti_bin/Lists.asmx as the URL
I get the following error: XmlException: For security reasons DTD is prohibited in this XML document. To enable DTD processing set the DtdProcessing property on XmlReaderSettings to Parse and pass the settings into XmlReader.Create method.
It doesn't matter if I use credentials or not.
What is the cause of this error? What is the soure of this error? I don't see how I can change the property in XmlReaderSettings.
Is this a security configuration on the server? Is there a solution or workaround to this problem?
Please try to connect to /_vti_bin/ListData.svc

Resources