You need to hack the code in the file
/usr/local/pf/html/captive-portal/lib/captiveportal/PacketFence/Controller/Activate/Email.pm.
I simply added back the code for the from the 5.7 and called it instead of
generating the error message:-
#
# EDIT BY APKT to re-enable activation from a different device from the one
being registered.
#
# Commented out the next two lines and replaced with
#
# $self->showError($c, "Please use the device you are registering to
validate the e-mail link");
# $c->detach();
#
# EDIT by APKT - added call to original 5.7 sub-routine to activate
registration based on original MAC address
#
$logger->info( "Registration activation from remote source - using
5.7 activation." );
$c->forward('doEmailRegistration', [$code]);
$c->detach();
}
And then add back in the code from 5.7:-
=head2 doEmailRegistration
TODO: documention
APKT: Added the routine back in from 5.7 source
=cut
sub doEmailRegistration : Private {
my ( $self, $c, $code ) = @_;
my $request = $c->request;
my $logger = get_logger();
my $activation_record = $c->stash->{activation_record};
my $profile = $c->profile;
my $node_mac = $c->portalSession->guestNodeMac;
my ( $pid, $email ) = @{$activation_record}{ 'pid', 'contact_info' };
my $auth_params = {
'username' => $pid,
'user_email' => $email
};
my $email_type = pf::Authentication::Source::EmailSource->getDefaultOfType;
my $source = $profile->getSourceByType($email_type) ||
$profile->getSourceByTypeForChained($email_type);
if ($source) {
# On-site email guests self-registration
# if we have a MAC, guest was on-site and we need to proceed with
registration
if ( defined($node_mac) && valid_mac($node_mac) ) {
my %info;
# Setting access timeout and role (category) dynamically
$info{'unregdate'} = &pf::authentication::match($source->{id},
$auth_params, $Actions::SET_UNREG_DATE);
$info{'category'} = &pf::authentication::match( $source->{id},
$auth_params, $Actions::SET_ROLE );
pf::auth_log::record_completed_guest($source->id,
$c->portalSession->clientMac, $pf::auth_log::COMPLETED);
$c->session->{"username"} = $pid;
$c->session->{"unregdate"} = $info{'unregdate'};
#
# Added by APKT to use in message format
#
my $unregdate = $info{'unregdate'};
$c->session->{source_id} = $source->{id};
$c->session->{source_match} = undef;
$c->stash->{info}=\%info;
$c->stash->{info}=\%info;
# $c->forward('Authenticate' => 'createLocalAccount', [$auth_params])
if ( isenabled($source->{create_local_account}) );
# change the unregdate of the node associated with the submitted
code
# FIXME
node_modify(
$node_mac,
( 'unregdate' => $c->stash->{info}->{unregdate},
'status' => 'reg',
'category' => $c->stash->{info}->{category},
)
);
#
# APKT added from 6.0.1 code to complete the patch
#
$c->stash(
title => "Access granted",
template => "activation/email.html",
message => "Email activation code has been verified. Access
granted until : $unregdate"
);
}
# Pre-registration email guests self-registration
# if we don't have the MAC it means it's a preregister guest generate a
password and send
# an email with an access code
else {
my %info = (
'pid' => $pid,
'email' => $email,
'subject' => utf8::decode(i18n_format(
"%s: Guest access confirmed!",
$Config{'general'}{'domain'}
)),
'currentdate' =>
POSIX::strftime( "%m/%d/%y %H:%M:%S", localtime )
);
# we create a password using the actions from
# the email authentication source;
my $actions = &pf::authentication::match( $source->{id},
$auth_params );
$info{'password'} =
pf::password::generate( $pid, $actions );
# send on-site guest credentials by email
pf::web::guest::send_template_email(
$pf::web::guest::TEMPLATE_EMAIL_EMAIL_PREREGISTRATION_CONFIRMED,
$info{'subject'}, \%info
);
$c->stash(
template => $pf::web::guest::EMAIL_PREREG_CONFIRMED_TEMPLATE,
%info
);
}
# code has been consumed, deactivate
pf::activation::set_status_verified($code);
$c->detach();
} else {
$logger->warn( "No active email source for profile "
. $profile->getName
. ", redirecting to "
. $c->portalSession->destinationUrl );
$c->response->redirect( $c->portalSession->destinationUrl );
}
}
HTH
Andrew
From: Morris, Andi [mailto:[email protected]]
Sent: 06 June 2016 15:49
To: [email protected]
Subject: Re: [PacketFence-users] Still a problem with registration process
On my current reverse proxy solution there’s very little config that can be
done. I can forward the original host header and/or I can proxy the request
with the original IP or the proxied IP.
When I choose to send the original IP the requests don’t seem to ever reach the
server, so I’m currently playing around with that.
I presume this check is something new to 6.0.x? If we can’t work around my
current proxy appliance, is there a way to disable this check? We should have a
new reverse proxy solution very soon which may provide many more options,
however that may be a few months off. Obviously I can’t answer for Andrew here
either, I don’t know his situation.
Cheers,
Andi
From: Louis Munro [mailto:[email protected]]
Sent: 06 June 2016 15:31
To: [email protected]
Subject: Re: [PacketFence-users] Still a problem with registration process
On Jun 6, 2016, at 10:19 , Morris, Andi
<[email protected]<mailto:[email protected]>> wrote:
Hi Andrew,
I’m also seeing the exact same issue. Users choose to register by email, then
click the email validation link and get a message to say they must use the same
device to validate.
My packetfence.log looks just like yours but I also noticed in mine that I see
my reverse proxy appliance IP address in the log, which is where I think
packetfence is failing to match the mac address:
I don’t know whether this is a similar situation with your setup or not.
I’m just playing with the transparency settings on the reverse proxy to see if
that will help.
PacketFence tries to detect which device is connecting to the portal http
server based on the incoming IP of the connection.
Proxying is indeed likely to break it.
Can you have the Proxy send a header with the origin IP such as X-Forwarded-for?
Regards,
--
Louis Munro
[email protected]<mailto:[email protected]> ::
www.inverse.ca<http://www.inverse.ca>
+1.514.447.4918 x125 :: +1 (866) 353-6153 x125
Inverse inc. :: Leaders behind SOGo (www.sogo.nu<http://www.sogo.nu>) and
PacketFence (www.packetfence.org<http://www.packetfence.org>)
________________________________
[Cardiff Metropolitan University - Queens Anniversary Prizes
2015]<http://www.cardiffmet.ac.uk/news/Pages/Cardiff-Met-research-recognised-in-Queens-Anniversary-Prizes-for-Higher-and-Further-Education.aspx>
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
