On 05-Jul-2005 Mike Schroeder wrote:
> [EMAIL PROTECTED] wrote:
>
>>Doing it that way makes encapsulation gods cry.
>>
>>
> My apologies to the encapsulation gods... Just wanted to make sure the
> data existed *somewhere* before asking how to get at it correctly...
The encapsulation gods are fickle and prone to break your code at the next
refactoring.
> What I'm really interested in is looking at the remote IP during
> registration and potentially rejecting the connection if it is coming
> from an unapproved address or block. Is there a better way to do that?
IKC deliberately doesn't have any access control.
Thinking about your problem, I see that you need to talk to the
IKC::Channel session, not the IKC::Responder session. Channel does the
negociation and holds the socket's Wheel. Closing a connection is done by
sending a shutdown event to the Channel.
One way you could add what you want is by overloading
POE::Component::IKC::Channel. However, IKC::Server hard codes the package
name, so there's no clean way to change the package that's used.
Better yet, overload POE::Component::IKC::Server. Define a package method
called 'accept' which is the SocketFactory's SuccessEvent. In the method
you check ARG1, which contains $peer_host or ARG0 which contains the
socket handle. Sort of like :
package My::IKC::Server;
use strict;
@ISA=qw(POE::Component::IKC::Server);
sub accept
{
my ($kernel, $handle, $peer_host, $peer_port) =
@_[HEAP, KERNEL, ARG0, ARG1, ARG2];
my $ip = inet_ntoa($peer_host);
if($ALLOWED{$ip}) {
shift()->SUPER::accept(@_);
}
# remote isn't allowed
warn "Disallowing connection from $ip:$peer_port\n";
close($handle); # don't know if this is necessary, nor
# even a good thing to do
return;
}
Best way is probably to block the port IKC is listening on at the firewall
level.
-Philip
