Re: @INC problem with SOAP::Lite

[john_oshea]

in reply to @INC problem with SOAP::Lite

Update 2

It appears that changing the dispatch_to parameters to the following allows for Data::Dumper use:

-> dispatch_to('/Users/johno/Code/DCI/Wordbank-DCI-Server/lib', '/usr/local/lib/perl5/5.8.8/darwin-2level/');

This makes me feel somewhat happier than hacking at the SOAP::Lite code, which, quite frankly, I don't understand. This seems not to introduce any gaping security holes(*), but I'd appreciate it if anyone who feels faint / nauseous at this would let me know what I'm letting myself in for ;-)

(*) I can't, for instance, call getcwd from Cwd.pm, which lives in the second path parameter.

[Corion]

This makes me feel queasy. I think the problem results from SOAP::Lite lazy-loading your module after it has modified @INC:

  unless (defined(%{"${class}::"}) || exists($INC{join '/', split /::/
+, $class.'.pm'})) {
    # allow all for static and only specified path for dynamic binding
+s
    local @INC = (($static ? @INC : ()), grep {!ref && m![/\\.]!} $sel
+f->dispatch_to);
    eval 'local $^W; ' . "require $class";
    die "Failed to access class ($class): $@" if $@;
    $self->dispatched($class) unless $static;
  } 

I think you should be able to fix the problem by force-loading your class(es) instead of waiting until SOAP::Lite decides to load them:

use Wordbank::DCI::Server;
use Wordbank::DCI::Another::Package;
# and so on

[john_oshea]

Hmmm. Yes. Now that I've done some more reading in the meantime, I get it. I think.. ;-)

For anyone else who may get stuck on this, Corion's suggestion is the 'static linking' option mentioned in the security section of the SOAP::Lite documentation.

Thanks for the help - much appreciated.