Wow!  That was painful.  I've gotten it working, but I had to have 4 Sources:
1. DPT-Sponsors, which is the SponsorEmail type.
2. ad1,  which is used to lookup the sponsor's email address in AD to confirm 
it's a real user.
3. email, because without that it won't let the sponsor respond to the email 
(see below for error).
4. DummyLogin, to support my one-click approval requirement.

  The "email" source thing is kind of weird.  Without it I get this in the logs:
Aug 07 10:28:56 email_activation.cgi(0) ERROR: No source of type 'EMAIL' 
defined for profile 'default' (pf::Portal::Profile::getSourceByType)
Aug 07 10:28:56 email_activation.cgi(0) INFO: User has nothing to do here, 
redirecting to http://www.dptlabs.com/ 
(ModPerl::ROOT::ModPerl::PerlRun::usr_local_pf_html_captive_2dportal_email_activation_2ecgi::handler)

  To accommodate that, since we DON"T want email (or SMS) registration, I 
simply edited to template file and removed the code to do that.  Not ideal, but 
good enough for now.  Ideally, there shouldn't be a requirement that there be 
"EMAIL" type registration when using sponsored registration. 
  This is SIGNIFICANTLY different that the behavior and configuration on 4.0.3.

  If I may make a suggestion it might make this a lot easier if intead of 
having a list of sources, you had multiple source entries where you could 
choose one or more, each based on where you are, e.g.:
Registration Sources:
        Email
        SponsorEmail
        SMS
Authentication Sources:
        AD
        Local
        LDAP
        RADIUS
        Htpasswd

  That way Registration Sources would map to one of the sources listed under 
"External Sources", and Authentication Sources to ones listed under "Internal 
Sources".  Internally you could continue to fold these together into a single 
list and process them as you do now, but I think this would make this easier to 
understand, and it would allow you to perform a check for a minimum of one 
internal and one external entry in the portal configuration (probably need an 
"Enable" check box which would simply clear these boxes if unchecked).
  Anyway, it's working again.  That was the goal.
  Thanks!
  Don

-----Original Message-----
From: Francis Lachapelle [mailto:[email protected]] 
Sent: Wednesday, August 07, 2013 8:25 AM
To: [email protected]
Subject: Re: [PacketFence-users] 4.0.4: Possible Bug in Sponsored Registration 
(maybe other guest registration)

Hi Don

On 2013-08-07, at 12:05 AM, Don Greer <[email protected]> wrote:

>  Francis,
>  Ok, here you go.
> =====================
> [local]
> description=Local Users
> type=SQL
> 
<snip>
> 
> [DummyLogin]
> description=This is a login file with a dummy login for the Sponsor's 
> page path=/usr/local/pf/conf/dummyLogin
> type=Htpasswd
> 
> [DummyLogin rule SponsorAcceptance]
> description=If we get here, go ahead and let the guest in.
> match=all
> action0=mark_as_sponsor=1
> =================
>  I've had sponsors working since y'all helped me on 4.0.1.  It worked through 
> 4.0.3 (although there were a few little hiccups along the way :^).  My config 
> may look a little strange because it was important that people be able to 
> authorize with one click from their smart phones, so I created a dummy login 
> file and changed the template in the profile so a dummy username and password 
> were preloaded on the web form for the authorizer.  It was decided that the 
> fact that the message got to their secured email box and they were expecting 
> it would be sufficient proof that they were the correct person to authorize 
> the guest.
>  Looking at the logs, as it stands today, it is getting the username from the 
> email (which it actually gets the email address for the username as it's 
> entered in AD, that seems kinda strange) but it fails to accept that email 
> address as being valid for the domain.

Delete your DummyLogin htpasswd source and instead create a local user with the 
"mark as sponsor" action (Web admin => Configuration => User/Create). The 
current code requires the sponsor email address to be found in an LDAP, 
ActiveDirectory or SQL source. When you create a user through the Web 
interface, it is added to the local SQL source.

>  For instance, when I test it with my personal computer, I enter my personal 
> data, and "[email protected]" for the sponsor.  This works fine in 4.0.3, 
> but in 4.0.4 it says "[email protected]" isn't a valid sponsor.  Looking 
> at the logs shows that it finds the user in AD, but still fails.  I messed 
> with this all day today, then rolled back to 4.0.3 when I left.  I saved my 
> work, so I can try again tomorrow, but without two clues to rub together, I'm 
> not making much progress I'm afraid.
>  Thanks for any help you can give me.  I'm sure you'll find something fairly 
> obvious wrong and I'll feel  dumb, but that's better than making the bruise 
> on my forehead bigger from banging it on the wall any longer :^).
>  Don
> 
> -----Original Message-----
> From: Francis Lachapelle [mailto:[email protected]]
> Sent: Tuesday, August 06, 2013 1:44 PM
> To: [email protected]
> Subject: Re: [PacketFence-users] 4.0.4: Possible Bug in Sponsored 
> Registration (maybe other guest registration)
> 
> Hi Don
> 
> On 2013-08-06, at 12:52 PM, Don Greer <[email protected]> wrote:
> 
>>  Not sure if this is a fix, or a work around, but I got past this error by 
>> changing line 189 in ./pf/lib/pf/web/guest.pm to the following:
>>    if ($source && (ref($source) ne 'ARRAY')) {  This simply ignores 
>> the source if it doesn't return an array reference.  Yes, I know, 
>> this is probably the wrong thing to do :^)
> 
> But yet, it will work. We'll come up with a cleaner fix.
> 
>>  Then I get to the next hurdle, which is I no longer match the condition 
>> "mark_as_sponsor".  I've tried very combination I can think of.  On the 
>> profile, I have a rule to define the guest, and a rule to define the 
>> authentication of the sponsor users, but NOT a rule that explicitly sets up 
>> the "mark_as_sponsor".  Do I now need to add this?
> 
> The sponsors need to be able to authenticate but also require to have the 
> action "mark as sponsor". Can you share your authentication.conf file?
> 
> FYI, the sponsor email address is validated by the "mark as sponsor" action 
> when the guest submit the self-registration form. When the sponsor clicks on 
> the activation link she/he received by email, PacketFence only makes sure the 
> user is or can authenticate.
> 
> 
>>  Thanks.
>>  Don
>> 
>> From: Don Greer [mailto:[email protected]]
>> Sent: Tuesday, August 06, 2013 8:45 AM
>> To: [email protected]
>> Subject: [PacketFence-users] 4.0.4: Possible Bug in Sponsored 
>> Registration (maybe other guest registration)
>> 
>>  After upgrading to 4.0.4, when testing the Sponsored Registration, I get 
>> the following error after entering my registration info:
>> [URL: https://pf.../signup?mode=guest-register]
>> Software Error:
>> Not a HASH reference at /usr/local/pf/lib/pf/web/guest.pm line 189 
>> For help, please send mail to the webmaster ....
>> 
>> From the portal_error_log:
>> [Tue Aug 06 08:34:56 2013] [error] [Tue Aug  6 08:34:56 2013] -e: Not 
>> a HASH reference at /usr/local/pf/lib/pf/web/guest.pm line 189.\n [Tue Aug  
>> 6 08:34:56 2013] -e: Constant subroutine 
>> ModPerl::ROOT::ModPerl::PerlRun::usr_local_pf_html_captive_2dportal_guest_2dselfregistration_2ecgi::UCHAR_MAX
>>  redefined at /usr/lib64/perl5/ModPerl/Util.pm line 69.
>> [Tue Aug  6 08:34:56 2013] -e: Constant subroutine 
>> ModPerl::ROOT::ModPerl::PerlRun::usr_local_pf_html_captive_2dportal_guest_2dselfregistration_2ecgi::SIGQUIT
>>  redefined at /usr/lib64/perl5/ModPerl/Util.pm line 69.
>> [Tue Aug  6 08:34:56 2013] -e: Constant subroutine 
>> ModPerl::ROOT::ModPerl::PerlRun::usr_local_pf_html_captive_2dportal_guest_2dselfregistration_2ecgi::USHRT_MAX
>>  redefined at /usr/lib64/perl5/ModPerl/Util.pm line 69.
>> [Tue Aug  6 08:34:56 2013] -e: Constant subroutine 
>> ModPerl::ROOT::ModPerl::PerlRun::usr_local_pf_html_captive_2dportal_guest_2dselfregistration_2ecgi::SIG_IGN
>>  redefined at /usr/lib64/perl5/ModPerl/Util.pm line 69.
>> [Tue Aug  6 08:34:56 2013] -e: Constant subroutine 
>> ModPerl::ROOT::ModPerl::PerlRun::usr_local_pf_html_captive_2dportal_guest_2dselfregistration_2ecgi::SEEK_SET
>>  redefined at /usr/lib64/perl5/ModPerl/Util.pm line 69.
>> 
>> Those last 5 lines are just the first of probably 50 or more similar 
>> messages about ModPer/Util.pm line 69.  Not sure if these are related or not 
>> to the hash issue or not.
>> 
>> Any help on this would be appreciated.
>> 
>> Thanks!
>> 
>> Don

--
[email protected] :: +1.514.755.3640 :: http://www.inverse.ca Inverse :: 
Leaders behind SOGo (http://sogo.nu) and PacketFence (http://packetfence.org)


------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users

Reply via email to