troelskn / handsoap forked from unwire/handsoap
- Source
- Commits
- Network (3)
- Issues (0)
- Downloads (36)
- Wiki (4)
- Graphs
-
Branch:
master
Pledgie Donations
Once activated, we'll place the following badge in your repository's detail box:
Handsoap is a library for creating SOAP clients in Ruby — Read more
-
Hi,
not sure what your plans regarding SSL are, but for my use case a simple:
http_client.use_ssl = true if url.scheme == 'https'in the NetHttp#send_http_request method did the trick for submitting requests to a HTTPS endpoint.
Cheers,
FlorianComments
-
Hi,
handsoap is currently under an CC-BY 2.5 license which is not compatible with GPL v3. Would it be possible for you to release handsoap under a GPL v3 compatible license or to explicitly dual-license it?
Best regards,
ThomasComments
I'll have to check up on that, as the code belongs to my former employer, Unwire.
I have seen that, yes. It would help a lot if this would be possible!
OK. I have been given the go to issue Handsoap under LGPL 3. That should be compatible with GPL, I assume?
Yes, that would be fine (as can be seen at http://www.fsf.org/licensing/licenses/gpl-faq.html#AllCompatibility) - thanks a lot for the help and the fast response!
-
One other small request: some SOAP services don't like the <?xml version="1.0" ?> header (Intel AMT SOAP services being one of them). It seems to be trivial to add an accessor to Handsoap::XmlMason::Document which controls whether an XML header is written or not.
Comments
-
Hi,
would it be possible that you create a project on rubyforge for releasing the official handsoap library (as .tgz and .gem)? With the help of the rubyforge gem or the hoe gem, it is rather easy to release files/news on rubyforge and rubyforge is still the main gem server. Then it would be possible to specify handsoap as dependency in other gems.
If you like, I can provide you with the basic rake tasks.
Best regards,
Thomasps. Why .tgz? Linux distributions don't really like gems and are more comfortable with .tgz files. And creating the .tgz file along the .gem file is no additional effort.
Comments
What's wrong with github, in this respect? You can install with:
gem install troelskn-handsoap -s http://gems.github.comI'm pretty sure (although I don't recall the exact syntax), that you can specify
sourceof dependencies, in the gemspec.Okay, I have just tested installing a local test gem with a dependency on troelskn-handsoap and this works. However, I don't know if a gem served by Rubyforge will work. Will have to test this.
However, there is no option for specifying the source of a gem dependency in the gemspec.
However, I don't know if a gem served by Rubyforge will work.
I don't see why it shouldn't.I don't think Rubyforge has a privileged status over github, with regards to
gem.I'd rather not have to publish the gem in multiple places, just to save people from adding github as a gem source. There are lots of other gems that are distributed through github (For example Rails), so I think it's fair to assume that users add it as a source.
Rails is hosted on github but the official gems are distributed via Rubyforge (see Rails rubyforge project).
Although I kinda like having rubyforge as central gem repo, I'm not against adding github as gem source. I have pushed a test gem to rubyforge with a dependency on troelskn-handsoap and it worked. So I will specify troelskn-handsoap in the gemspec. However, I think you would probably avoid confusion if you released your handsoap library as handsoap gem and not as troelskn-handsoap.
Gem is now available through gemcutter. Please file a new issue on the tracker for
unwire/handsoap, if you still think we should distribute through Rubyforge.
kennethkalmer
Sun Oct 11 04:20:15 -0700 2009
| link
Great effort, thanks !
-
$ ./script/generate handsoap http://ws.cdyne.com/WeatherWS/Weather.asmx?wsdl weather exists app exists app/models Expected exactly 1 interface/portType in WSDLif I try the same steps that the generator does in script/console, I get that same failure with a stacktrace:
>> compiler.compile_service(protocol, :soap_actions) RuntimeError: Expected exactly 1 interface/portType in WSDL from /Library/Ruby/Gems/1.8/gems/troelskn-handsoap-0.5.4/lib/handsoap/parser.rb:133:in `interface' from /Library/Ruby/Gems/1.8/gems/troelskn-handsoap-0.5.4/lib/handsoap/compiler.rb:137:in `compile_service' from /Library/Ruby/Gems/1.8/gems/troelskn-handsoap-0.5.4/lib/handsoap/compiler.rb:54:in `write' from /Library/Ruby/Gems/1.8/gems/troelskn-handsoap-0.5.4/lib/handsoap/compiler.rb:120:in `compile_service' from (irb):17running on Mac OX 10.5.8, with the following software versions:
master $ rails -v Rails 2.3.2 master $ ruby -v ruby 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0] master $ gem list troelskn-handsoap *** LOCAL GEMS *** troelskn-handsoap (0.5.4)Comments
-
Digest Authentication/URI endpoint specification
11 comments Created 3 months ago by gettalongHi,
I'm trying to use handsoap to access the Intel AMT soap services. I have across two issues which should be easy to to overcome:
Digest authentication: Intel AMT needs digest authentication and httpclient already supports this. However, there is currently (0.5.4) no way to set the security credentials using the
httpclient.set_auth method.It would be good to have an
on_after_create_http_clientcallback method in the service class which is called after the http client is created but before the request is sent. This would probably mean that the http driver modules would need one more method for returning the driver and that the#send_http_requestwould need to take the returned http client object as additional parameter. This would allow one to set the credentials in a nice way.URI endpoint specification: With Intel AMT there are many hosts that implement one service. So it makes no sense to specify the URI of the endpoint at the class level. There should be some way to define the URI on a per-object basis and only fall back to the class level when no per-object URI is available.
ps. Would it be possible to make the http driver selectable on a per-service basis, ie. not use
Handsoap::Http.driver[Handsoap.http_driver]but something that uses an instance method of the current service to get the driver and if that is nil, fall back to the common one?Comments
Those are good suggestions. Making it possible to override the endpoint on the instance level should be fairly simple and makes good sense. Likewise, making it possible to set the http-driver on the instance level shouldn't be a big deal to implement either. I wonder what the use-case for this is though?
Regarding http-auth, you should be able to use basic www-authentication by setting the request headers. Have a look in the wiki for an example. That is unless I misunderstood your request?
Silly me. You specifically said "Digest authentication". No, this would require that the http-drivers were extended to allow the functionality. Again, this is probably fairly simple to implement, since some (Probably all, but I haven't checked) of the underlying drivers have support for it, so it should merely be a matter of wrapping that up nicely.
Could you explain why you want a
on_after_create_http_clientcallback?Regarding instance level endpoint: A nice solution would probably be to create a
#urimethod that returnsnilby default and change the line in#dispatchto sayresponse = send_http_request(uri || self.class.uri, doc.to_s, headers)This would allow a subclass to override the
urimethod for custom endpoint uri.Rational behind instance level endpoint: Some SOAP services are implemented by a number of clients, for example, Intel AMT SOAP services are implemented by all devices featuring the vPro sign. Therefore there only needs to be one service class with customizable endpoint URIs. I currently use the
on_after_create_http_requesthook to overwrite therequest.urlwith the customized one.Regarding http-driver on the instance level: As far as I know not all http drivers implement the digest authentication, httpclient surely does and I think curb does as well. However, the ruby built-in net/http library does not support digest authentication.
It would be useful on the instance level because consider two different libraries for accessing services via soap built on handsoap. One needs digest authentication and chooses to use httpclient for this since it is a pure ruby solution. The other library doesn't want to depend on any third-party gems except handsoap and therefore uses the net/http driver and REXML and sets them via class level accessors. When one uses both libraries the behaviour may be different to the case where only one of the libraries is used.
Regarding the
on_after_create_http_clientcallback: I have seen something like this mentioned in another issue but found no implementation. The reason for such a callback is that it would allow one to customize the http access, for example, by setting the used authentication credentials.My current solution to the digest authentication problem is that I copied the
#send_http_requestmethod to my service base class and modified the way the http driver is created and called, ie. I pass the credentials tohttp.send_http_request(request, username, password). For this I also needed to copy the httpclient driver nearly verbatimly and then changed the method signature to include the username and password and added one line to add the credentials to the created httpclient object. As you can see, the callback would help to avoid code duplication.Apart from these small issues, the handsoap library rules! ;-)
I have seen something like this mentioned in another issue but found no implementation. The reason for such a callback is that it would allow one to customize the http access, for example, by setting the used authentication credentials.
on_after_create_http_requestexisted in older versions. I removed it, when I introduced the current http-abstraction. I don't think it should be nescesarry to re-introduce it - The idea is to put all such things on the http-request and then let the abstraction layer translate to each underlying driver. There may be some features, that are simply not supported by the driver. In this case, I think a runtime error would be in place. Although, digest is relatively simple, so it could be implemented in userland code, if net/http doesn't support it directly. I'll see if I can find time to look at it in the near future.This would also be okay. Then it would be nice to set the authentication credentials (username, password, ev. domain) in the http request callback or even with the same system proposed for URI handling (ie. a class setting and an object setting).
I have added a new method to Http::Request in the repository. To authenticate, use:
class MyService < Handsoap::Service def on_after_create_http_request(http_request) http_request.set_auth @user, @pass endThe underlying drivers should then automagically determine which type of authentication the server wants, and use that. Both httpclient and curb supports at least basic and digest, and they may support other types, if the required libraries are installed etc. The bare-bones net::http only supports basic out of the box.
I haven't tested it in any way, since it's fairly complicated to do. Can you test this against your service, to verify that it works?
The 0.5.6 version works like a charm, thanks! I have tried it with httpclient and curb and both work as expected.
0.5.7 now has hooks that allow to specify the endpoint on a per-instance level.
Thanks, this does the trick!
One other small request: some SOAP services don't like the <?xml version="1.0" ?> header (Intel AMT SOAP services being one of them). It seems to be trivial to add an accessor to Handsoap::XmlMason::Document which controls whether an XML header is written or not.
Yes, that should be possible. Could you please open a new issue for this?
-
I'm getting errors when the service returns a chunked http-response. Curl seems to include this in the header part, causing a
bad header '"\r\n"'.error.Comments
-
I have an application that responds with multipart responses. When try to use the xml_document.parts method, I get this error:
<Handsoap::XmlQueryFront::NokogiriDriver:0x7ffe4c6e4ba8>
/var/lib/gems/1.8/gems/troelskn-handsoap-0.4.4/lib/handsoap/service.rb:277:in
parts': undefined local variable or methodresponse' for #<Handsoap::XmlQueryFront::NokogiriDriver:0x7ffe4c6e4ba8> (NameError)from ./nbi/datacentric_service.rb:113:in `parse_get_all_devices' from ./nbi/datacentric_service.rb:90:in `get_all_devices' from test.rb:78Any invocation of the .parts method yields the same error. It looks like a scope problem in service.rb, in the xml_document.parts method. xml_document appears to be out-of-scope for the method.
Comments
-
Setting additional headers in on_before_dispatch
4 comments Created 4 months ago by wvanbergenSetting additional headers on the HTTP client (only tested with Curb) in the on_before_dispatch hook does not work, because they are overwritten later on in the send_http_request method.
http_client = Curl::Easy.new(uri) on_after_create_http_client(http_client) # headers are set here http_client.headers = headers # overwrite occurs hereBecause of this, setting up Basic Authorization using a header does not work. This can easily fixed by using merge!:
http_client.headers.merge!(headers)However, maybe we can add an API to set additional HTTP headers?
Comments
OK. I'll add that patch, but I think you may be right about putting an interface before the http client library.
wvanbergen
Tue Aug 11 01:41:35 -0700 2009
| link
OK, if I have some time I'll fork the project an add an HTTP client interface. Besides from solving this problem, it is also possible to use a mock HTTP client for testing purposes.
I already have a http abstraction from another project that I could pull in. My biggest concern is really about adding complexity - and I'm more and more convinced that it is worth it.
wvanbergen
Tue Aug 11 02:49:45 -0700 2009
| link
My idea was to create different classes that implement the
send_http_requestmethod, and adding an API to set additional HTTP headers (e.g.Handsoap::Service.http_headers[:Authorization] = 'blah').But if you already have something available, it may be easier to use that than writing it from scratch.
-
I needed to use HTTP authentication for the SOAP service I was consuming. I forked the project to implement this, however I found out that it is actually possible already using on_after_create_http_client hook:
def on_after_create_http_client(http_client) http_client.userpwd = "#{self.class.username}:#{self.class.password}" endThis probably only works with curb; I haven't tested it with httpclient. Maybe this can be added as a feature to handsoap with a nicer API than the example above. Otherwise, this code snippet could be added to the documentation.
Comments
Yes, I actually have meant to document that for a while now, but I can't figure out where to put it in the documentation. Perhaps using the wiki would make sense here, as there are different ways to do authentication over soap.
In theory, I agree on your suggestion about abstracting the difference between curb and httpclient out, but it can quickly become rather complicated. For now, I have just accepted the lack of portability in return for less complex code. Not an overly consistent choice, I know ...
FWIW, I think the following variation is portable:
def on_after_create_http_client(http_client) # beware the missing chomp, it will make you cry.... auth = Base64.encode64("#{username}:#{password}").chomp http_client.headers['Authorization'] = "Basic #{auth}" end
wvanbergen
Mon Aug 10 12:07:23 -0700 2009
| link
Personally, I prefer using the Github project's wiki. For this issue, I would probably have added my code example to it myself :-)
I've enabled the wiki and started a page on authentication: http://wiki.github.com/troelskn/handsoap/authentication
I have now released 0.5.0, which puts the http interaction in a separate driver layer. This gives you much better control over the interaction. At present, I haven't exposed method for dealing with SSL certificates, but it's just a matter of adding them in. Note that this changes the API so code which used
on_after_create_http_clientpre 0.5.0 will have to be rewritten. -
In service.rb line 413, ::Tempfile objects don't have the .string method, so it died there. I hacked the following in an attempt to get around, but I don't know if this is correct:
*** /var/lib/gems/1.8/gems/troelskn-handsoap-0.4.3/lib/handsoap/service.rb 2009-08-09 11:41:50.433057698 -0400 --- /var/lib/gems/1.8/gems/troelskn-handsoap-0.4.3/lib/handsoap/service-dannys.rb 2009-08-09 11:39:26.297058435 -0400
* 360,365 ** --- 360,366 ----
loop do head = nil- mycontent_length=content_length
if 10240 < content_length require "tempfile" body = Tempfile.new("CGI")
* 410,416 **
"" end! parts << {:head => head, :body => body.string}
break if buf.size == 0 break if content_length == -1 end--- 411,425 ----
"" end! if body.kind_of? ::StringIO then ! parts << {:head => head, :body => body.string} ! elsif body.kind_of? ::Tempfile then ! bodystring="" ! body.read(mycontent_length, bodystring) ! parts << {:head => head, :body => bodystring} ! else ! raise "body must be StringIO or Tempfile" ! end
break if buf.size == 0 break if content_length == -1 endAnyway, after changing the service.rb, I now get:
"Exception `Handsoap::XmlQueryFront::ParseError' at /var/lib/gems/1.8/gems/troelskn-handsoap-0.4.3/lib/handsoap/xml_query_front.rb:56 - Handsoap::XmlQueryFront::ParseError"
This is probably to do with my hack not being the right way to do it, specifically I couldn't figure out whether "content_length" is the right size to use for the body.read.
Before throwing the parse error, I receive 3 parts of the response. The first two (64894 bytes and 34174 bytes) go fine. I'll forward all the files in an email.
=============== --- Request --- URI: http://10.0.1.231:8080/axis2/services/DataCentricService
SOAPAction: GetObjectViewByCategoryRequest
Content-Type: text/xml;charset=UTF-8
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header /> <env:Body><dat:GetObjectViewByCategoryRequest xmlns:dat="http://juniper.net/nbiservice/datacentricservice"> <core:AuthToken xmlns:core="http://juniper.net/core"> <core:Token>ee6a7186-208a-4d97-8427-40da4c73cda0</core:Token> </core:AuthToken> <dat:category>deviceobj</dat:category> <dat:domainId>1</dat:domainId> </dat:GetObjectViewByCategoryRequest></env:Body> </env:Envelope>
--- Response --- HTTP Status: 200
Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_FF5B45112F1A1EA3831249832076826; type="application/xop+xml"; start="0.urn:uuid:FF5B45112F1A1EA3831249832076827@apache.org"; start-info="text/xml"
--- Part #1 --- Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: binary
Content-ID: 0.urn:uuid:FF5B45112F1A1EA3831249832076827@apache.org
--- Part #2 --- Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: binary
Content-ID: 1.urn:uuid:FF5B45112F1A1EA3831249832076828@apache.org
--- Part #3 --- Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: binary
Content-ID: 2.urn:uuid:FF5B45112F1A1EA3831249832076830@apache.orgComments
- mycontent_length=content_length
-
I have a soap application that returns a zero length http "accept" (202) in response to a request. handsoap doesn't seem to like this, and this condition doesn't trigger the "on_missing_document" or the "on_fault" hooks. It appears this is an unexpected response, because handsoap generates an exception:
Exception `Handsoap::XmlQueryFront::ParseError' at /var/lib/gems/1.8/gems/troelskn-handsoap-0.4.2/lib/handsoap/xml_query_front.rb:56 - Handsoap::XmlQueryFront::ParseError
Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_FF5B45112F1A1EA3831249656129588; type="application/xop+xml"; start="0.urn:uuid:FF5B45112F1A1EA3831249656129589@apache.org"; start-info="text/xml"
--- Part #1 --- Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: binary
Content-ID: 0.urn:uuid:FF5B45112F1A1EA3831249656129589@apache.org
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body><ns2:LoginResponse xmlns:ns2="http://juniper.net/webproxy/systemservice" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ns2:LoginResponseType"> <ns1:Status xmlns:ns1="http://juniper.net/core">Success</ns1:Status> <ns2:loginStatus> <ns2:status>Success</ns2:status> </ns2:loginStatus> <ns2:authToken> <ns1:Token xmlns:ns1="http://juniper.net/core">f30c2116-e407-42bd-89a0-6d38fbfa6b32</ns1:Token> </ns2:authToken> </ns2:LoginResponse></soapenv:Body>
</soapenv:Envelope>
--- Request --- URI: http://10.0.1.231:8080/axis2/services/SystemService
SOAPAction: LogoutRequest
Content-Type: text/xml;charset=UTF-8
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header /> <env:Body><ns2:LogoutRequest xmlns:ns2="http://juniper.net/webproxy/systemservice" /></env:Body> </env:Envelope>
--- Response --- HTTP Status: 202
Content-Type: text/xml;charset=UTF-8
Comments
This is odd. The xml parser is supposed to raise an exception, but this is then caught and handled higher up in the library. Can you give me a complete stack trace?
Github is hatcheting the stack trace, but I did send it to you in an attachment to your email address. I will resend in case it didn't get to you.
Doh just realized you said "Stack Trace" not wiredump...can you give me some guidance on how to do the stack trace?
I know you can put it inside a begin..rescue..end block (error.backtrace), but I don't see a good place in xml_query_front.rb to do that.
If I wrap my own code that way, it doesn't produce anything more than what we already have.
You need to catch the exception on the top level of your test-script, and print out the stack trace. Eg. wrap your code in something like:
begin # call code here rescue Exception => ex puts ex.to_s + "\n" + ex.backtrace.join("\n") end.. normally this would happen automatically, but if you're running the code inside a testcase, it may be why the stack trace is squelched. You can also try to run the testcase with
--verboseoption to get the same output.Isn't testcase part of Rails? I've never used Rails, and am not using any formalized "testcase" libs or anything. This is really strange. It doesn't even show the normal level of verbosity in the trace when the exception is raised, and I can't seem to make it produce more.
I ran my code using "irb -tracer" which I can send to you. It is really verbose though, and quite the output is quite large. I don't think its of much value.
Forgot to add my code so you can see what I am doing.
Here's the snippet:
System Servicesystem_service = NBI::SystemService.new
resp = system_service.login($config.username, $config.password, $config.domain)if system_service.logged_in? then
puts "Login Successful" begin resp = system_service.logout() rescue => error puts error.backtrace endelse
puts "Error logging in"end
Here's the login() and logout() methods:
def login(username, password, domain_name="global") $log.info "LoginRequest =>" begin response = invoke("ns2:LoginRequest") do |message| message.add("ns2:domainName", domain_name) message.add("ns2:userName", username) message.add("ns2:password", password) end rescue => error puts error.backtrace end $log.info "LoginResponse <=" parse_login_response(response) end def logout begin invoke("ns2:LogoutRequest") do |message| message.add("ns2:authToken", @auth_token) end rescue => error puts error.backtrace end endAnd here is the output:
mcnultyd@deskcat:~/nsm-api/handsoap-ver$ ruby test.rb
Wiredump device = FILE
<File:0x7f52756be120>
<File:0x7f52756bdf18>
<File:0x7f52756bdfb8>
<File:0x7f52756be058>
Exception
LoadError' at /usr/lib/ruby/1.8/rubygems/custom_require.rb:31 - no such file to load -- curb<br/> Login Successful<br/> ExceptionHandsoap::XmlQueryFront::ParseError' at /var/lib/gems/1.8/gems/troelskn-handsoap-0.4.3/lib/handsoap/xml_query_front.rb:60 - Handsoap::XmlQueryFront::ParseError
mcnultyd@deskcat:~/nsm-api/handsoap-ver$As you can see, I've put exception handlers around everything that seems to matter. The exception is never caught. What am I doing wrong here?
-
I was attempting to interact with a service that uses the namespace "http://www.w3.org/2003/05/soap-envelope" for its SOAP Envelope (as specified in the Soap 1.2 specification ) ,and I can't seem to find a way to create a handsoap service that supports that namespace. Does this just need to be added to Handsoap::SOAP_NAMESPACE, or am I missing something?
Comments
It looks like I made a mistake. It doesn't make sense to use
http://www.w3.org/2003/05/soap-envelopefor the soap-envelope. I think I copied this from an example, which must have gotten it wrong. The services I have used have been v. 1.1, so that's why I haven't noticed before. I'll make the change and push an update.I've done a little more research, and it looks like http://www.w3.org/2003/05/soap-envelope is the correct current namespace for SOAP 1.2. However, it appears that during the drafting phase for the SOAP 1.2 specification, that namespace changed a few times, which is why you still see other ones (like http://www.w3.org/2001/12/soap-envelope) "in the wild" (in some of the w3schools SOAP articles, for instance). You can see older versions of the spec by following the "Previous Versions" link at the top of the current spec.
What I don't know is whether it makes sense to support any older versions of the SOAP 1.2 namespace other than the one that made it into the Recommendation.
Aha. Thanks for the research then. I would say that it does make sense, since service-providers have a way of misinterpreting the protocol all the time, and Handsoap is foremost a pragmatic tool. We could add an
:envelope_namespaceparameter to theendpointclass-method, instead of the current:version.I'll have a closer look at it tomorrow.
It's now possible to specify the envelope namespace explicitly in
endpoint. Use as:class MyService < Handsoap::Service endpoint :uri => 'blah', :envelope_namespace => 'lorem', :request_content_type => 'application/soap+xml' endOr:
class MyService < Handsoap::Service endpoint :uri => 'blah', :envelope_namespace => 'lorem', :version => 2 endUpdate to 0.4.0 for this.
-
Hello:
I am a moderately experienced Ruby scripter, but with almost zero soap experience. I am just starting writing an client that is running against a service provided through Axis2. It appears the service accepts my request, processes it, and sends a response.
The problem comes when handsoap's parser (nokogiri in this case) tries to parse the response. It always raises an error and I have to see the result using the result to the "on_missing_document" method.
EDIT: Removed junk that was the result of a misunderstanding on my part. SOAP isn't easy on beginners!
Comments
Hi. I didn't see your message before now. Can you mail me a copy of the service class and a dump of the http-activity? The issue tracker here at github messed the formatting up. My address is troelskn@gmail.com
Thank you troelskn. I am pretty sure this is a problem with the service I am trying to consume, or with my code. I sent the information you requested however, perhaps you will see something. Thanks very much!
-
Hi,
the "on_fault" method raise the Fault object but if it is not formatted the way it is supposed to be (Code and Reason tags), I didn't find a way to get to the Response object to parse it manually and raise the real error code, …
Maybe, if it is possible to set something different than "lazy" for the fault handling, we could have the Response object returned instead of a regular Fault object
Comments
poorlilrichboy
Fri Jul 10 12:16:04 -0700 2009
| link
I have the same issue. I think its because Response.fault is using soap_namespace that I set in on_create_document. But a fault response has a generic nampespace.
I'm logging faults by overriding the on_fault method but i would like to actually get the code and reason captured in the log also.
Just saw this message now, so sorry for the late reply.
If you're using a 1.2 service, I think the problem may be related to issue#7.
More generally, a better solution could be to move the document-parsing into the service class. Then it would be possible to override the default parsing code with your own. That would also allow you to parse out more detailed information that your fault might contain. I'll have a stab at that.
OK. I have now moved the fault-parsing into the service class, which means that you can hook into it, by overriding
parse_soap_fault. This also simplified the code a bit, so that I could removeResponsefrom the code-base. Update to 0.4.0 to get this new functionality.Thank you for the effort.
I'm trying right now and I'm struggling with some xpath problem so I can't tell exactly for sure if it's solving my issues, but it seems so.I think that Nokogiri's documentation is very poor. I don't understand how to define namespaces to parse my returned xml.
Yeah, well actually you should blame Handsoap for that. The XML parsers are wrapped in a thin abstraction layer
XmlQueryFront. To use a namespace in a query, you can do one of two things. Either you register the namespace globally for the document:doc.add_namespace(prefix, uri)You can then use
prefixfordoc.Alternatively, you can pass the namespace in the call to
xpath, like this:doc.xpath('//foo:WhatEver', 'foo' => uri)Since you usually use the same namespace all over a single service, it's convenient to register the prefixes globally in the
on_response_documenthook:class MyService < Handsoap::Service def on_response_document(doc) doc.add_namespace(prefix, uri) end endThanks for the tip. Yesterday I've ended using the second "manual" option, because I think the first didn't work for (I must have done something wrong).
Anyway, It's definitly better to be able to customize the fault handling. A little too much overriding for my taste, but still a huge improvement. Thanks again.
-
script/generate handsoap - No such file or directory
2 comments Created 6 months ago by enterprise-railsscript/generate handsoap -t https://gateway.developer.telekom.com/p3gw-mod-odg-sms/services/SmsService?wsdl
exists app exists app/modelsreadlink: illegal option -- f
usage: readlink [-n] [file ...]
create app/models/sms_service.rbNo such file or directory - /opt/local/lib/ruby/gems/1.8/gems/handsoap-0.3.4/generators/handsoap/templates/var/folders/hi/hijrjnD8Fr8jbSKY1SYB+E+++TI/-Tmp-/handsoap_generator.2017.0
/opt/local/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/rails_generator/commands.rb:377:ininitialize' /opt/local/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/rails_generator/commands.rb:377:inopen' /opt/local/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/rails_generator/commands.rb:377:inrender_file' /opt/local/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/rails_generator/commands.rb:260:infile' /opt/local/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/rails_generator/commands.rb:259:inopen' /opt/local/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/rails_generator/commands.rb:259:infile' /opt/local/lib/ruby/gems/1.8/gems/handsoap-0.3.4/generators/handsoap/handsoap_generator.rb:87:infile_contents' /opt/local/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/rails_generator/manifest.rb:47:insend' /opt/local/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/rails_generator/manifest.rb:47:insend_actions' /opt/local/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/rails_generator/manifest.rb:46:ineach' /opt/local/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/rails_generator/manifest.rb:46:insend_actions' /opt/local/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/rails_generator/manifest.rb:31:inreplay' /opt/local/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/rails_generator/commands.rb:42:ininvoke!' /opt/local/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/rails_generator/scripts/../scripts.rb:31:inrun' /opt/local/lib/ruby/gems/1.8/gems/rails-2.3.2/lib/commands/generate.rb:6 /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:ingem_original_require' /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:inrequire' script/generate:3Comments
-
script/generate handsoap - certificate verify failed
1 comment Created 6 months ago by enterprise-railsscript/generate handsoap -t https://gateway.developer.telekom.com/p3gw-mod-odg-sms/services/SmsService?wsdl
--> certificate verify failed
Comments
-
I'm having some problem when going from 0.2.9 => 0.3.1.
There is an exception when using xml_to_str
undefined method `to_utf8' for #<Handsoap::XmlQueryFront::NokogiriDriver:0xb66b28b0>Comments
The
xml_to_stret al methods are deprecated now. You should replace code like this:xml_to_str(node, 'foo/bar')With:
(node/'foo/bar').to_sOr:
node.xpath('foo/bar').first.to_sI am adding a patch for 0.3.2 to create backwards compatibility for these helpers, but you should get rid of them.
-
XmlMason: CDATA values shouldnt be escaped
1 comment Created 6 months ago by enterprise-railsContents of statements like his souldnt be encoded:
element.set_value("<[[CDATA[bla]]>")
It would be great If there was a way to prevent it.
A quick workaround could look like this:
module Common class NonEscapingString < String
def gsub(arg) self end def to_s self endend end
Just wrap code that shouldn't be escaped with a NonEscapingString class. Not very beautiful.
Comments





Thanks. I've applied the patch in master. Remember to update to
unwire/handsoap, where the new home is.