Re: SOAP::Lite IP Address Validation
- Original Message - From: "Leo Lapworth" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 20, 2003 3:16 PM Subject: Re: SOAP::Lite IP Address Validation > On Mon, Jan 20, 2003 at 12:46:53PM -, Andy Williams (IMAP HILLWAY) wrote: > > I have a SOAP server (using SOAP::Lite) that I only want to access from > > certain IP addresses. > > > > Is this possible? If so, how do I do it? > > Put a firewall in between the SOAP server and then limit access > to what ever port the SOAP is running on to the access machine only. > > Ok, non-perl but might work :) Good plan. why didn't I think of that! Thanks
Re: SOAP::Lite IP Address Validation
On Mon, Jan 20, 2003 at 12:46:53PM -, Andy Williams (IMAP HILLWAY) wrote: > I have a SOAP server (using SOAP::Lite) that I only want to access from > certain IP addresses. > > Is this possible? If so, how do I do it? Put a firewall in between the SOAP server and then limit access to what ever port the SOAP is running on to the access machine only. Ok, non-perl but might work :) Leo
Re: SOAP::Lite IP Address Validation
On Mon, Jan 20, 2003 at 01:12:19PM -, Andy Williams (IMAP HILLWAY) said:
> Forgot to mention that the server in not an HTTP server but a Daemon so
> $ENV{'REMOTE_ADDR'} is not populated.
Well, if it's TCP then I presume you'd subclass
SOAP::Transport::TCP::Server and modify the handle() method so that it
reads something like (this is completely untested)
sub handle {
my $self = shift->new;
my $sock = $self->{_socket};
my $session_set = IO::SessionSet->new($sock);
my %data;
while (1) {
my @ready = $session_set->wait($sock->timeout);
for my $session (@ready) {
next unless (is_allowed_ip($session));
my $data;
if (my $rc = $session->read($data, 4096)) {
$data{$session} .= $data if $rc > 0;
} else {
$session->write($self->SUPER::handle(delete $data{$session}));
$session->close;
}
}
}
}
# warning! bad code
sub is_allowed_ip {
my $session= shift;
my $sockaddr = $session->handle()->peername();
my ($port, $iaddr) = sockaddr_in($sockaddr);
return $allowed_ips{$iddr};
}
Re: SOAP::Lite IP Address Validation
On Mon, Jan 20, 2003 at 01:12:19PM -, Andy Williams (IMAP HILLWAY) wrote:
> - Original Message -
> From: "Simon Wistow" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, January 20, 2003 1:07 PM
> Subject: Re: SOAP::Lite IP Address Validation
>
>
> > On Mon, Jan 20, 2003 at 12:46:53PM -, Andy Williams (IMAP HILLWAY)
> said:
> > > Hi,
> > >
> > > I have a SOAP server (using SOAP::Lite) that I only want to access from
> > > certain IP addresses.
> >
> > Check $ENV{'REMOTE_ADDR'} ?
> >
>
> Forgot to mention that the server in not an HTTP server but a Daemon so
> $ENV{'REMOTE_ADDR'} is not populated.
>
Um, if it's a daemon then don't you get the client port and IP when you open a
socket for it? Am I missing something?
/joel
Re: SOAP::Lite IP Address Validation
- Original Message -
From: "Simon Wistow" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 20, 2003 1:07 PM
Subject: Re: SOAP::Lite IP Address Validation
> On Mon, Jan 20, 2003 at 12:46:53PM -, Andy Williams (IMAP HILLWAY)
said:
> > Hi,
> >
> > I have a SOAP server (using SOAP::Lite) that I only want to access from
> > certain IP addresses.
>
> Check $ENV{'REMOTE_ADDR'} ?
>
Forgot to mention that the server in not an HTTP server but a Daemon so
$ENV{'REMOTE_ADDR'} is not populated.
Nice thought though :)
Andy
Re: SOAP::Lite IP Address Validation
On Mon, Jan 20, 2003 at 12:46:53PM -, Andy Williams (IMAP HILLWAY) said:
> Hi,
>
> I have a SOAP server (using SOAP::Lite) that I only want to access from
> certain IP addresses.
Check $ENV{'REMOTE_ADDR'} ?
Re: SOAP::Lite
That reminds me. Is .NET the way to automatically pass a load of lat/long values into Mappoint so that it displays automatically? Well, MapPoint *does* do that, but I believe it is a premium service. I know that Tellme is billed by MapPoint on a per-request basis (some fraction of a pence), though we don't actually use the mapping features. We use it to get driving directions from their route-generation interface, which we then convert to speech. (Note to those I was discussing this with back in November at the pub: much to my surprise [and error], MapPoint coverage does in fact include London. And I'm still quite relieved at not having to write any code to generate travel directions around any part of London.) Randy -- """ Randy J. RayCampbell, CAhttp://www.rjray.org[EMAIL PROTECTED] Silicon Valley Scale Modelers: http://www.svsm.org
Re: SOAP::Lite
> The use of namesp2 instead of declaring a default namespace (which is what > happens with "xmlns=") is not a problem, except that it prevents the namespace > from also applying to the LanguageCode and SportID elements. When working on a > project at my day-job that talked to MicroSoft's MapPoint.NET service, I wrote > custom serialization routines for the classes I was working with, that set the > xmlns attribute at their outer element, so that the inner ones were covered. I > don't recommend that for you, it's pretty damned ugly. Use the example above, > instead. Ah Mappoint... That reminds me. Is .NET the way to automatically pass a load of lat/long values into Mappoint so that it displays automatically? Possibly even use it to publish positions of vehicles as they move around? I have this need, from time to time, to generate coverage plots showing position of vehicles after failures of transmission of messages. At the moment this involves running a perl program which generates a .csv or .xls file which I input manually to mappoint for display. Is there some way of automating this? Dirk -- Please Note: Some Quantum Physics Theories Suggest That When the Consumer Is Not Directly Observing This Product, It May Cease to Exist or Will Exist Only in a Vague and Undetermined State.
Re: SOAP::Lite
>
> *sigh* My apologies. I wrote last night's reply at a late hour when I was
> about to go to sleep, and I forgot one of the stickiest points about .Net.
It
> lives and dies by the namespace.
No problem I tought this was the case and didn't knwo quite what to do
to fix it.
>
> The creation of the SOAP::Header and SOAP::Data objects all need to give
> explicit namespaces to their objects. You do this with the uri() method:
>
> my $head = SOAP::Header->name(Authentication =>
> { User => 'abcde',
> Password => '12345' })
>->uri('http://www.xx.com/Events');
>
> With something similar later where you create the SOAP::Data objects for
the
> call to Competitions.
Hooray. it worked. namespaces are now correct.
>
> The use of namesp2 instead of declaring a default namespace (which is what
> happens with "xmlns=") is not a problem, except that it prevents the
namespace
> from also applying to the LanguageCode and SportID elements. When working
on a
> project at my day-job that talked to MicroSoft's MapPoint.NET service, I
wrote
> custom serialization routines for the classes I was working with, that set
the
> xmlns attribute at their outer element, so that the inner ones were
covered. I
> don't recommend that for you, it's pretty damned ugly. Use the example
above,
> instead.
>
> > The last thing that the server seems to "disagree" with is
> > xsi:type="xsd:string" in each of the data elements.
>
> I can't say without seeing the WSDL, but those elements may not be typed
as
> "string". The SportID is probably int (though I would expect SOAP::Lite to
> have typed it as such, since it matched the regex for an integer). Just as
you
> can set a namespace with uri(), you can set a specific type identification
> with a type() method. (I noticed from your example output that even the
> numbers are getting default types of xsd:string, in fact.)
>
I managed to get the WSDL from the server and found that the Authentication
part and all the data elements had to be done with out a prefix so the final
code was:
use strict;
### Added maptype => {}
use SOAP::Lite ( maptype => {} );
use Data::Dumper;
$|++;
my $hdr = SOAP::Header->name(
Authentication => {
'User' => 'abcde',
'Password' => '12345'
}
)->uri('http://www..com/Events')->prefix(''); # Added
uri and prefix
my $client = SOAP::Lite
-> uri('http://www..com/Events')
-> proxy('http://odds..com/EventService.asmx')
-> on_action(sub{sprintf '%s/%s', @_ });
my $res = $client->Competitions(
$hdr,
SOAP::Data->name(LanguageCode =>
'en')->uri('http://www.xxx.com/Events')->prefix(''),#
Added uri and prefix
SOAP::Data->name(SportID =>
1)->uri('http://www.xx.com/Events')->prefix('')# Added
uri and prefix
);
And this now works.
Thanks for all your help Randy.
Andy
Re: SOAP::Lite
- Original Message -
From: "Randy J. Ray" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 11, 2003 10:53 AM
Subject: Re: SOAP::Lite
> Many people do. .Net is designed in a way that makes it much harder for
> non-.Net toolkits to work with it, than it truly needs to be.
>
>
> You don't say how you used the SOAP::Header object, and it isn't obvious
from
> your example code.
>
> When you create a SOAP::Header object, you're just creating a SOAP::Data
> object in a different namespace. When SOAP::Lite goes to serialize a
request
> from a call, it looks at all the arguments passed, and any that are
blessed
> into the SOAP::Header namespace go into the Header section, rather than
the
> body. Using your code's call as an example, you should have done:
>
> my $head = SOAP::Header->name(Authentication =>
> {'User' =>
> 'abcde',
> Password =>
> '12345'});
>
> my $res = $client->Competitions($head,
> {
> 'LanguageCode' => 'en',
> 'SportID' =>
> '1' });
>
> Note that you aren't setting a header with the SOAP::Header->new call,
you're
> creating a data element that must be passed into the later call as a
parameter.
>
>
> The SOAP-ENV vs. soap issue is unimportant. Those are just labels for
> namespaces; you could call it "Spike" if you wanted.
>
> The bigger problem is with c-gensym3. That is because you didn't give the
SOAP
> call a piece of fully-qualified data; you gave it an anonymous hash
reference
> instead. And .Net services are notorious for being picky and retentive
about
> what they'll accept. Plus, you should be passing LanguageCode and SportID
as
> separate parameters, not a hash. The "Competitions" tag is what identifies
the
> remote operation (as seen by the fact that you are calling
> $client->Competitions()).
>
> Try using SOAP::Data objects to control how things look:
>
> my $res = $client->Competitions($head, # Don't forget this one :-)
> SOAP::Data->name(LanguageCode => 'en'),
> SOAP::Data->name(SportID => 1));
>
Hi,
OK I couldn't wait to try your suggestions. And I am a lot closer to getting
this to work.
There now appears to be another problem.
These three lines are added to the Envelope and seem to be causing a
problem.
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance";
xmlns:xsd="http://www.w3.org/1999/XMLSchema";
xmlns:namesp1="http://xml.apache.org/xml-soap";
I assume that this also causes the instead of http://www.xx.com/Events";> that seems to be required.
I also get http://www.xx.com/Events";> instead of http://www.xx.com/Events";>
which the server doesn't seem to like.
The last thing that the server seems to "disagree" with is
xsi:type="xsd:string" in each of the data elements.
I have managed to get access to the server by using LWP and constructing my
own XML but this is far from ideal and I could do with a little more help.
There seems to be a lack of documentation on SOAP::Lite - or maybe it's just
me not understanding it properly (more likely)!
Here is the new code:
use strict;
use SOAP::Lite +trace => 'all';
use Data::Dumper;
$|++;
my $hdr = SOAP::Header->name(Authentication => {'User' => 'abcde', Password
=> '12345'} );
my $client = SOAP::Lite
-> uri('http://www..com/Events/EventByEvent')
-> proxy('http://soap..com/EventService.asmx')
-> on_action(sub{sprintf '%s/%s', @_ });
my $res = $client->Competitions($hdr,
SOAP::Data->name(LanguageCode => 'en'),
SOAP::Data->name(SportID => 1));
print Dumper($res);
Here's the new output:
http://schemas.xmlsoap.org/soap/encoding/";
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance";
xmlns:xsd="http://www.w3.org/1999/XMLSchema";
xmlns:namesp1="http://xml.apache.org/xml-soap";>
12345
abcde
http://www..com/Events";>
en
1
Re: SOAP::Lite
- Original Message - From: "Randy J. Ray" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, January 11, 2003 10:53 AM Subject: Re: SOAP::Lite > > (Do I get to shill my web services book? :-) > > Randy > -- Thanks Randy, I'll give it all a try on monday, after I've bought your book. Andy
Re: SOAP::Lite
On Sat, Jan 11, 2003 at 02:53:22AM -0800, Randy J. Ray ([EMAIL PROTECTED]) wrote: > > (Do I get to shill my web services book? :-) Absolutely you do. I've just started reading it. Looking pretty damn good so far. Dave... -- .sig missing...
Re: SOAP::Lite
I am trying to get access to .NET soap service from perl using SOAP::Lite
and have hit a brickwall
Many people do. .Net is designed in a way that makes it much harder for
non-.Net toolkits to work with it, than it truly needs to be.
I have 2 problems:
1) The Header. I can't seen to find a way of adding the authentication.
I have tried the following:
a) SOAP::Header->name(Authentication => {'User' => 'abcde', Password =>
'12345'} );
b) Setting the HTTP_proxy_[user|pass] variable
c) adding -
sub SOAP::Transport::HTTP::Client::get_basic_credentials {
return 'abcde' => '12345';
}
None of these have worked.
You don't say how you used the SOAP::Header object, and it isn't obvious from
your example code.
When you create a SOAP::Header object, you're just creating a SOAP::Data
object in a different namespace. When SOAP::Lite goes to serialize a request
from a call, it looks at all the arguments passed, and any that are blessed
into the SOAP::Header namespace go into the Header section, rather than the
body. Using your code's call as an example, you should have done:
my $head = SOAP::Header->name(Authentication =>
{'User' =>
'abcde',
Password =>
'12345'});
...
my $res = $client->Competitions($head,
{
'LanguageCode' => 'en',
'SportID' =>
'1' });
Note that you aren't setting a header with the SOAP::Header->new call, you're
creating a data element that must be passed into the later call as a parameter.
2) The output from SOAP::Lite (ignoring problem 1) is as follows:
http://xml.apache.org/xml-soap";
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance";
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/1999/XMLSchema";>
http://www..com/Events";>
en
1
Which is close but not exactly the same as what is reqired. For example
SOAP-ENV: instead of soap:; and where has the extra element 'c-gensym3' come
from???
The SOAP-ENV vs. soap issue is unimportant. Those are just labels for
namespaces; you could call it "Spike" if you wanted.
The bigger problem is with c-gensym3. That is because you didn't give the SOAP
call a piece of fully-qualified data; you gave it an anonymous hash reference
instead. And .Net services are notorious for being picky and retentive about
what they'll accept. Plus, you should be passing LanguageCode and SportID as
separate parameters, not a hash. The "Competitions" tag is what identifies the
remote operation (as seen by the fact that you are calling
$client->Competitions()).
Try using SOAP::Data objects to control how things look:
my $res = $client->Competitions($head, # Don't forget this one :-)
SOAP::Data->name(LanguageCode => 'en'),
SOAP::Data->name(SportID => 1));
(Do I get to shill my web services book? :-)
Randy
--
"""
Randy J. RayCampbell, CAhttp://www.rjray.org[EMAIL PROTECTED]
Silicon Valley Scale Modelers: http://www.svsm.org
