I am trying to build REST service using Apache CXF.
One of the requirement is to sign XML using XAdES-T standard.
I was going over
jax-rs-xml-security
and made it to sign XML document.
How can I add a timestamp to the signature?
https://www.w3.org/TR/XAdES/
Is it possible to do XAdES-T using CXF?
Demo project can be found: https://gitlab.com/SamaraIT/orders-cxf
Please advice.
There are libraries which can be used to sign XML messages using XAdES standard, such as:
xades4j
Digital Signature Service
Related
Hopefully someone can help me.
I am currently using POSTMAN to run SOAP web service tests on NetSuite.
Annoyingly, I am having to generate the body of an XML request from scratch, and would really like a method whereby a basic template is generated for me, and I simply fill in the gaps. Creating an XML web request from scratch is prone to errors hence my question. I tried SOAPUI but it does not
Any ideas is most appreciated!
hope you remember me!! The easiest way would be to download any of the existing working SOAP web request from any running build and modify that to suit your need. There is no out of the box built in template that you could build on at least as per my knowledge. Please specify the record for which you are building the SOAP request
The easiest way is to not use POSTMAN.
I used to do a lot of this and what I'd do is:
generate the java client for SuiteTalk
install a recording proxy (I think WireMock does this -- the one I used to use doesn't seem to be around anymore)
use JUnit tests to hit SuiteTalk
in the test setup override the SSL config to ignore host name verification
test an API call
extract the complete working SOAP from the proxy logs
templatize the SOAP and use it where needed.
i would like to ask your help in relation with one issue i am facing. So basically i defined a swagger 2.0 spec for an API, and on the operation's responses i used the schema property in order to reference some definitions for objects that reflect the responses structure. I validated the spec on the Swagger Editor, and it is valid, and also if i generate the client code, using Swagger Codegen, the client app works well consuming the API. Now, the problem is. I went to the Developer Portal and on the API's details page, i checked the API definition (Open API option) and i compared the spec with my original spec that i used to import the API on the API Management service. And i noticed that the schema property is missing, so it is not referencing the schema of the response. Any idea?
Thanks
I figured out the issue. Apparently using the schema property on the responses, according to Swagger 2.0 spec, you can use nested $refs, in order to reference definitions inside each other. But apparently, it is not possible for Azure API Management Service, since it is mentioned as a limitation in the following link: API Management - API Import restrictions.
Anyway, i will try to change my API's spec in order to avoid nested $refs and workaround the issue.
Thanks
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.
I am very new to Salesforce and it's API.
I am having a sandbox org and with it I have url, username, password, security token and last but not the least partner.wsdl
My aim was to connect and retrieve/create data.
Technologies at hand was nodejs
So here is how I started.
I searched over the internet and came to know that I need to create a client, SOAP client in order to login, create the connection and use that connection to create and access the Leads data.So I followed this sample where the wsdl was being consumed.
So I was able to connect
I was very happy on this success and then suddenly I wasn't able to identify/find a way where I can get the sObject.I looked hard for this but no luck. So posted a question on SO
Meanwhile I also looked for other node module and found jsforce
I used jsforce starting guide and created a client that was connecting to salesforce however without using the wsdl file.
Again I was happy, even more happy because I was having the sObject with me.
Now, what is the fundamental difference if I login using the local wsdl file and without wsdl file in the language of salesforce. Which one is the correct way of logging in?
Sorry if this question is not according to SO rules or if there is a typo.
I'm the author of jsforce you mentioned.
In that lib we use REST API mostly and SOAP APIs are only used in some specific calls like login or metadata. Even in such calls we don't use WSDLs because there's no good lib to generate client modules from WSDL in JavaScript/Node.js area. Instead we wrote modules for each APIs which generate SOAP XML strings and parse the response XML.
It is enough because these API message schema are static and fiesible in the specific version, unlike SOAP API Enterprise WSDL differs in organizations. So we can hard code the client module directly w/o generate it from WSDL.
I am trying to use CreateEnvelopesFromTemplatesAndForms.
I have used the PDF that I am uploading effectively using the simple CreateEnvelope. I have also used the PDF effectively by manually uploading it via the Web UI. So I don't think the error relates to the PDF.
Any hints on how to troubleshoot "Unspecified_Error" ?
I would suggest downloading SoapUI from SmartBear, then create a new SOAP Project and point it at DocuSign's WSDL: https://demo.docusign.net/api/3.0/api.asmx?WSDL. SoapUI will create sample calls for each of the DocuSign SOAP methods in the WSDL.
The error message you're getting means (generally) that you're not providing a field value that's required, or you have included a node tree that isn't necessarily required but since you included it, all of the values need to be valid.