I'm finally able to connect to Windows Live completely with soap4r,
however, the server is very picky.
For example:
<n1:RequestSecurityToken xmlns:n1="http://schemas.xmlsoap.org/ws/2005/02/trust">
This doesn't work, the namespace needs to be defined on some parent
element. Bad implementation of the server, but there's nothing to do
on our side.
Also, for some strange reason, there's one part of the request that
must have the namespace tag as "wst"; it doesn't work with anything
else. Maybe it's hard-coded on the server?
The specific type works for most of the stuff, except RequestType,
which according to [1] should be RequestTypeOpenEnum, but that doesn't
work.
In order to generate a proper request I had to do modify the generator
so I could specify my own NS.
It would be nice if the Generator could also be specified.
This is the filter that allows me to do the magic:
class MyFilter < SOAP::Filter::Handler
def on_outbound(env, opt)
ns = XSD::NS.new({})
ns.assign("http://schemas.xmlsoap.org/ws/2005/02/trust", "wst")
ns.assign("http://schemas.microsoft.com/Passport/SoapServices/PPCRL", "ps")
ns.assign("http://schemas.xmlsoap.org/ws/2003/06/secext", "wsse")
ns.assign("http://schemas.xmlsoap.org/ws/2004/09/policy", "wsp")
ns.assign("http://schemas.xmlsoap.org/ws/2004/08/addressing", "wsa")
ns.each_ns do |value,tag|
env.extraattr["xmlns:#{tag}"] = value
end
opt[:generate_explicit_type] = false
opt[:ns] = ns
env
end
end
Attached are the patches, and the resulting XML.
Best regards.
PS. I don't know why that xmlns:n1 is added to UsernameToken.
[1] http://schemas.xmlsoap.org/ws/2005/02/trust/WS-Trust.xsd
--
Felipe Contreras
Hi,
Thank you for all your input.
Felipe Contreras wrote:
> I'm finally able to connect to Windows Live completely with soap4r,
> however, the server is very picky.
>
> For example:
> <n1:RequestSecurityToken xmlns:n1="http://schemas.xmlsoap.org/ws/2005/02/trust">
>
> This doesn't work, the namespace needs to be defined on some parent
> element. Bad implementation of the server, but there's nothing to do
> on our side.
Hmm. The following (n1 -> wst) does not work, too?
<wst:RequestSecurityToken
xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
XML namespace should be handled in XML processor and this kind of XML
processing incompatibility should not exist these days... But hearing
that changing namespace tag 'n1' to 'wst' solved the another problem,
the server must be a picky about XML namespace.
> Also, for some strange reason, there's one part of the request that
> must have the namespace tag as "wst"; it doesn't work with anything
> else. Maybe it's hard-coded on the server?
>
> The specific type works for most of the stuff, except RequestType,
> which according to [1] should be RequestTypeOpenEnum, but that doesn't
> work.
Do you know where's official samples of WS-Trust request?
> In order to generate a proper request I had to do modify the generator
> so I could specify my own NS.
Thank you for the patch. I applied soap-generator.diff to soap4r-1.5.7
with a little modified. Here's the changeset.
http://dev.ctor.org/soap4r/changeset/1887
And here's a sample.
http://dev.ctor.org/soap4r/browser/trunk/test/soap/test_custom_ns.rb
There's a little different of handling 'xmlns:custom=...' as an
extraattr. Passed opt[:default_ns] is treated as a template of NS and
extraattrs are added by generator itself.
> It would be nice if the Generator could also be specified.
This patch isn't included in 1.5.7 but I'll consider to add this. Do
you already have an concrete custom generator? I want to know how it helps.
> This is the filter that allows me to do the magic:
Happy to know the filter feature (from 1.5.6) works!
> PS. I don't know why that xmlns:n1 is added to UsernameToken.
Can I see the entire client source code? If not, a header handler you
are using?
// NaHi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
iQEVAwUBRpwnZh9L2jg5EEGlAQKseggAx9ykO8r8lYNloAB5nD/M7KHboG0kSazz
LVEhuaQfET3n5X0hUNRP7mREdPBHAcqhFNfRpCh++Shk5eqfR/Savbc1ekHAYwS4
4GKIMVyhg5z0vAoOORDL5vL5hh4VxLsvXJvKBsaASD6HItkAZUbygq2R9QRRSwRf
Rr7NJyBkwHlxeLvTLBtLAu0azAOplJORkYV/a9p2TdJpQwt32iuiKgvRr4sAVIAq
3IKhmfGfPydCsqcgRy5uT0xhNbeKzSASOTkW2IEf2VETRC4Dof7AgvvY+gNb9f1+
NyBc++9wFgacPYAZxtrTg13e4ydmfDFepSD5p1Kj4vm/i1cGQXtnZA==
=V+Ra
-----END PGP SIGNATURE-----
Nope, if the xmlns:foo is on the same element the query doesn't work.
> XML namespace should be handled in XML processor and this kind of XML
> processing incompatibility should not exist these days... But hearing
> that changing namespace tag 'n1' to 'wst' solved the another problem,
> the server must be a picky about XML namespace.
Very :)
> > Also, for some strange reason, there's one part of the request that
> > must have the namespace tag as "wst"; it doesn't work with anything
> > else. Maybe it's hard-coded on the server?
> >
> > The specific type works for most of the stuff, except RequestType,
> > which according to [1] should be RequestTypeOpenEnum, but that doesn't
> > work.
>
> Do you know where's official samples of WS-Trust request?
Nope, I know you can check the standard from:
http://schemas.xmlsoap.org/ws/2005/02/trust
> > In order to generate a proper request I had to do modify the generator
> > so I could specify my own NS.
>
> Thank you for the patch. I applied soap-generator.diff to soap4r-1.5.7
> with a little modified. Here's the changeset.
> http://dev.ctor.org/soap4r/changeset/1887
> And here's a sample.
> http://dev.ctor.org/soap4r/browser/trunk/test/soap/test_custom_ns.rb
That's great! Thanks.
> There's a little different of handling 'xmlns:custom=...' as an
> extraattr. Passed opt[:default_ns] is treated as a template of NS and
> extraattrs are added by generator itself.
>
> > It would be nice if the Generator could also be specified.
>
> This patch isn't included in 1.5.7 but I'll consider to add this. Do
> you already have an concrete custom generator? I want to know how it helps.
The custom generator basically allowed me to put my own NS.
> > This is the filter that allows me to do the magic:
>
> Happy to know the filter feature (from 1.5.6) works!
>
> > PS. I don't know why that xmlns:n1 is added to UsernameToken.
>
> Can I see the entire client source code? If not, a header handler you
> are using?
I have uploaded all the relevant code here:
http://people.freedesktop.org/~felipec/msn
You can try your own queries (if you have a hotmail account) with:
http://people.freedesktop.org/~felipec/msn/test/test.rb
http://people.freedesktop.org/~felipec/msn/test/sample.xml
If you don't have an account I could send you the login of a test
account I have.
You'll see that:
* You can s/*:/n1/ any ns tag except wst
* You can't define the ns tag in the same element
Here is my custom stuff:
http://people.freedesktop.org/~felipec/msn/myDriver.rb
Best regards.
--
Felipe Contreras
Hi,
I tried ruby-msn
(http://felipec.wordpress.com/2007/07/19/ruby-library-for-windows-live-messenger-msn/)
and found that the service is very selfish about SOAP spec. The service
behaves as you wrote.
One addition to your list, the server returns SOAP Fault element as a
direct child of SOAP Envelope which must be a child of SOAP Body. I
filed a ticket at http://dev.ctor.org/soap4r/ticket/384 and added a
workaround for interoperability.
Felipe Contreras wrote:
>> Thank you for the patch. I applied soap-generator.diff to soap4r-1.5.7
>> with a little modified. Here's the changeset.
>> http://dev.ctor.org/soap4r/changeset/1887
>> And here's a sample.
>> http://dev.ctor.org/soap4r/browser/trunk/test/soap/test_custom_ns.rb
>
> That's great! Thanks.
Attached is a patch for ruby-msn to use soap4r-1.5.7.
Your work is very interesting from interoperability point of view, too.
Please let me know if there seems to be an interoperability problem again.
// NaHi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
iQEVAwUBRqLpVR9L2jg5EEGlAQJKJQf7BuQ48BblxRccDWrrpG1EXiQBtCa4vTtl
8r84uIL9W+0ALj1pmep1uP/i6UzAr38RxqiHqB7seUAW4Xtx4mZW3aLjZFPeLhqX
kKZM4jLIiL4Oa4N/PBkPfS4T30CwkWroAp2l0EgckYbcv3GtfnJ8kzrTofqWpHub
+nsRLydISkypr7tcj2up/ZJhDHPHZ8lQI7vGqTnuLaPX4dWvYk5AwjCKHFfrHcCK
Px9aVMpzAGO1tOorO9i6DQrNYmc6j5rzrmtAqzjAidxs1LJXafBsppR0XSrpXr5A
MTHGCSiZ/P89JsVSMyFlR0yhfBlm6vbM30/lS7QxxC1s3w4SKS4ZAA==
=UIvG
-----END PGP SIGNATURE-----