I'm using gSOAP with EWS via proxy services to connect to Exchange services. I've fully working C++ gSOAP code for sending message on Windows, but when I compile and run the same code on Ubuntu, I've got 401 Unauthorized Error, Why?
On Windows:
I've used the binaries of soapcpp2.exe and wsdl2h.exe to generate header files etc.
For compile and run: I'm using MobaXterm (a kind of Terminal)
Please anyone who are familiar with gSOAP help me to figure out the possible problem. Many thanks in advance.
The 401 Unauthorized Error requires HTTP authentication, either with HTTPS and basic authentication or with HTTP digest authentication. The proxy also likely requires authentication.
See the tutorial on HTTP Digest Authentication
Related
I implement a bittorrent client using libtorrent. but I meet a problem. I have a http file server as the web seed. The server just support digest authentication for http request. and Libtorrent support basic auth by default. Does it have any way to make libtorrent to support digest auth? It would be nice to give an example. Thanks in advance.
no, libtorrent does not support digest authentication for HTTP seeds.
Patches are welcome! (and really, web servers and HTTP trackers should really be transitioned to use boost.beast instead of a homegrown HTTP parser)
After installing google-api-client library for C++ on a Fedora 20 machine, I find out that it has external dependencies on libcurl (for example, setting up http proxy). I was planning to use google-api-client for sending HTTP request, mainly, HTTP multipart POST request. However, libcurl does provide support for multipart HTTP POST request also.
Could someone let me know the advantages of using Google API Client library for C++ over libcurl in order to send HTTP request?
Any suggestions/recommendations would be highly appreciated.
Thanks
The Google API Client Library is just a C++ wrapper around libcurl which is pure C library. I would use Casablanca REST SDK which is written in modern C++11, has no external dependencies and is cross platform.
I get the following error when I run a web service client that contacts a remote web service server:
SOAP 1.1 fault: SOAP-ENV:Client[no subcode]
"Client fault"
Detail: [no detail]
I have looked at the client and the server and I can find no faults. Other web server clients can contact web services on the server no problem. The code to the web service client is here, but more than that, I'm actually just wondering how to go about debugging a problem like this one. The web service client and server were constructed using the gSOAP toolkit.
Also, could it have something to do with web service name spaces? I use the ns namespace for all of my webservice applications. See this.
It is likely that there was an EOF or interruption before the response message was fully delivered to the client. Without further details there is no way of knowing for sure.
I suggest to compile the client with -DDEBUG (macro DEBUG set) to generate log files. The log files will be helpful to determine the cause of the problem.
Use the latest version of gSOAP if possible.
I have successfully installed ldap and kerberos. I was also able to make a simple c program with SASL/GSSAPI to search data in my ldapserver?
But I was not find any article (that I can follow easily) on how to use the the single sign on functionality in a client server system? I am not even sure how the communication between client and server happens in SSO.
How would a server know that client is a valid client?
Are there any sample examples/tutorials to make such a system?
Edit:
The server can be as simple as receiving hello from authenticated client. So client should have kerberos ticket and server should verify the ticket if it is valid or not.
I could compile gsspapi program using libs and dll provided by MIT.
the files I needed were gsskrb5.dll,gssapi32.lib,comerr32.lib
These will depend upon the version of kerberos for which they were compiled but I was successful in compiling the example given by mit http://web.mit.edu/macdev/KfM/KerberosFramework/Kerberos5/Tools/GSSExample/ using MinGW gcc compiler after few tweaks.
However I could not communicate successfully using SSPI api by microsoft (that may be due to my lack of knowledge)
I have a .WSDL file from our client company, for which I need to use to call a web service. Their system is SAP (SAP PI). My application is a C# .NET 3.5 client developed in VS 2008. I added a Service Reference in Visual Studio using their provided .WSDL file. This created a reference class for me to use to call their service, and set up several bindings in the app.config file for me.
I did not change anything in the app.config file, but did create code to call their web service. However, when I call their webservice, I receive the following exception:
The HTTP request is unauthorized with client authentication scheme 'Anonymous'. The authentication header received from the server was 'Basic realm="SAP NetWeaver Application Server ..."'.
(I modified slightly the string used in the 'Basic realm' section so as to not give it out.)
Did the app.config not get built correctly from the WSDL? Am I supposed to modify the app.config file somehow?
Things I've tried:
changed authenticationScheme in app.config from Anonymous to Basic
(as well as all the other authentication types)
changed realm string in app.config to match the realm in the exception message
set username/pw fields in the ClientCredentials.Username object in my code
Any pointers or help would be appreciated.
Edit: After some more investigation, I found that Visual Studio has several warnings about the extension element Policy and Policy assertions:
Custom tool warning: The optional WSDL extension element 'Policy'
from namespace 'http://schemas.xmlsoap.org/ws/2004/09/policy' was not
handled.
Custom tool warning: The following Policy Assertions were not Imported:
XPath://wsdl:definitions[#targetNamespace='urn:sap-com:document:sap:rfc:functions']/wsdl:binding[#name='Binding_FieldValidation']
Assertions: ...
I wasnt able to find out if this was related or not to my current issue with the authentication scheme. It does seem to be related, but I havent been able to find any solutions to getting these policy warnings resolved either. It seems WCF doesnt handle the statements in the wsdl very well.
Most SAP services dont support anonymous.
So pass some form of authentication data with the call.
User and password / X.509 Ticket...
If you are sending auth data with the call the try this
Ask the SAP guy to regenerate the WSDL with
No SAP assertions, No policy, SOAP 1.1.
You can also try and edit the WSDL by hand to remove the extra guff...
As a starting point, I'd verify that you can call the service successfully with the provided username and password. Use something like SoapUI to test that everything works correctly - just create a new project, import the WSDL provided by SAP PI, set the username and password and execute the call. You'll probably get some form of exception with an empty payload, but at least that'll verify that the username and password are correct.
Once you've verified that's working, check that your application is calling the service correctly and that the http basic authentication headers are being sent. You can confirm this by using a network monitoring tool and checking that the http request is being generated correctly. Something like netcat for Windows can do it - just make it listen to a port on your local machine and then specify localhost and the port as your SOAP endpoint.
Once you've verified both of those are correct, your call should succeed.
There must be the Basic authentication header missing or something wrong
with the credentials.
SAP PI always defaults to Basic Authentication if a Service is published via it's SOAP Adapter. I would investigate if WCF really does send out that header (e.g. Point your client endpoint to TCP Gateway and let TCP Gateway point to the SAP PI Endpoint from the WSDL).
About the Warnings: AFAIK the WSDL generated by SAP PI will always contain these Policy Tags, you can't really ommit it. What you can do is simply throw them out as they are not really validated