Hi Don On 2013-08-07, at 11:57 AM, Don Greer <[email protected]> wrote:
> 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) I'll improve email_activation.cgi to avoid this requirement. > 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). That's a good idea. I'm adding it to my TODO list! Thanks! > 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
