From john.thurston at alaska.gov Tue Nov 5 23:30:30 2024 From: john.thurston at alaska.gov (John Thurston) Date: Tue, 5 Nov 2024 14:30:30 -0900 Subject: [ZendTo] ZendTo installer with Alma Linux - feature request References: <5ebc612b-8ec1-4732-bc39-eb4e1a8b6fdf@alaska.gov> Message-ID: The installer is happy to work with Red Hat, CentOS, and Rocky. It won't proceed when it finds Alma. Red Hat/Rocky/Alma should be binary-compatible, so I just tweaked a file so the installer was convinced I was running Rocky: echo "RockyLinux release 8.10 (Green Obsidian)" > /etc/rockylinux-release rm -f /etc/redhat-release && ln -s /etc/rockylinux-release /etc/redhat-release When the installation was? complete, I switched it back rm -f /etc/redhat-release && ln -s /etc/almalinux-release /etc/redhat-release Can we get the installer logic adjusted so it will directly handle Alma ? -- -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska -------------- next part -------------- An HTML attachment was scrubbed... URL: From jules at zend.to Wed Nov 13 15:01:17 2024 From: jules at zend.to (jules at zend.to) Date: Wed, 13 Nov 2024 15:01:17 +0000 Subject: [ZendTo] ZendTo installer with Alma Linux - feature request In-Reply-To: References: <5ebc612b-8ec1-4732-bc39-eb4e1a8b6fdf@alaska.gov> <548d6d67-4637-46c6-9495-58c440ba10e3@zend.to> Message-ID: Hi John, I'm just installing Alma 9 now to do that tweak for you. Cheers, Jules. On 05/11/2024 11:30 pm, John Thurston via ZendTo wrote: > > The installer is happy to work with Red Hat, CentOS, and Rocky. It > won't proceed when it finds Alma. Red Hat/Rocky/Alma should be > binary-compatible, so I just tweaked a file so the installer was > convinced I was running Rocky: > > echo "RockyLinux release 8.10 (Green Obsidian)" > /etc/rockylinux-release > rm -f /etc/redhat-release && ln -s /etc/rockylinux-release > /etc/redhat-release > > When the installation was? complete, I switched it back > > rm -f /etc/redhat-release && ln -s /etc/almalinux-release > /etc/redhat-release > > Can we get the installer logic adjusted so it will directly handle Alma ? > > -- > -- > Do things because you should, not just because you can. > > John Thurston 907-465-8591 > John.Thurston at alaska.gov > Department of Administration > State of Alaska > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Alice doesn't trust Bob. Now most people in Alice's position would give up. Not Alice. She has courage which can only be described as awesome. Against all odds, over a noisy telephone line, tapped by the tax authorities and the secret police, Alice will happily attempt, with someone she doesn't trust, whom she can't hear clearly, and who is probably someone else, to fiddle her tax return and to organise a coup d'etat, while at the same time minimising the cost of the phone call.' - Steven Bellovin www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.thurston at alaska.gov Wed Nov 13 15:25:02 2024 From: john.thurston at alaska.gov (John Thurston) Date: Wed, 13 Nov 2024 06:25:02 -0900 Subject: [ZendTo] Problem updating 6.05-4 to 6.13-3 References: <0b5a4557-08b3-4448-88a4-114f9117d930@alaska.gov> Message-ID: Updating our test-system seemed to work perfectly. Not so for production. After updating from 6.05-4 to 6.13-3, I have some strange behavior (and have reverted to the old, by way of a VMWare snapshot). New drop-off and pickup seems to work as expected. Picking up recent drop-offs seemed to work as expected. But the "Show All Drop-offs" now contains some entries with numeric values (e.g. "235 637 597") in place of the expected strings (e.g. "22iUmVdjs9WxszxD"). I exported all of the drop-offs to a CVS. All of the numeric clamIDs show a zero size. And most of them are well past their expiration date. Most are only a little old, but some are more than 6-months old. So I /suspect/ there are some old entries in the database which weren't cleaned up in the normal course of operations. The new code in 6.13 is finding them, interpreting them, and adding them to the list of available downloads. I also /suspect/ that the next reaping through the database by the new code would clean them out. But I couldn't be sure, so I've reverted to 6.05 while I try to figure out what it is doing and if it is safe. I know that 6.13 is now a couple of years old, so others probably performed their update in the distant past. But does anyone have any insight or advice? -- -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska -------------- next part -------------- An HTML attachment was scrubbed... URL: From KLE at msktd.com Wed Nov 13 15:37:08 2024 From: KLE at msktd.com (Ken Etter) Date: Wed, 13 Nov 2024 15:37:08 +0000 Subject: [ZendTo] Problem updating 6.05-4 to 6.13-3 In-Reply-To: References: <0b5a4557-08b3-4448-88a4-114f9117d930@alaska.gov> Message-ID: Sorry, but I bumped mine to 6.13 over a year ago. I just checked it now out of curiosity, but nothing like that shows up in my all drop-offs. I either did not have that issue or they were cleaned up automatically. Ken From: ZendTo On Behalf Of John Thurston via ZendTo Sent: Wednesday, November 13, 2024 10:25 AM To: ZendTo List Cc: John Thurston Subject: [ZendTo] Problem updating 6.05-4 to 6.13-3 Updating our test-system seemed to work perfectly. Not so for production. After updating from 6.05-4 to 6.13-3, I have some strange behavior (and have reverted to the old, by way of a VMWare snapshot). New drop-off and pickup seems to work as expected. Picking up recent drop-offs seemed to work as expected. But the "Show All Drop-offs" now contains some entries with numeric values (e.g. "235 637 597") in place of the expected strings (e.g. "22iUmVdjs9WxszxD"). I exported all of the drop-offs to a CVS. All of the numeric clamIDs show a zero size. And most of them are well past their expiration date. Most are only a little old, but some are more than 6-months old. So I suspect there are some old entries in the database which weren't cleaned up in the normal course of operations. The new code in 6.13 is finding them, interpreting them, and adding them to the list of available downloads. I also suspect that the next reaping through the database by the new code would clean them out. But I couldn't be sure, so I've reverted to 6.05 while I try to figure out what it is doing and if it is safe. I know that 6.13 is now a couple of years old, so others probably performed their update in the distant past. But does anyone have any insight or advice? -- -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska -------------- next part -------------- An HTML attachment was scrubbed... URL: From jules at zend.to Wed Nov 13 15:51:08 2024 From: jules at zend.to (jules at zend.to) Date: Wed, 13 Nov 2024 15:51:08 +0000 Subject: [ZendTo] Problem updating 6.05-4 to 6.13-3 In-Reply-To: References: <0b5a4557-08b3-4448-88a4-114f9117d930@alaska.gov> <4983bdcf-f105-4c03-a3c2-01d329c7a687@zend.to> Message-ID: The ones with the numeric values should be labelled as "requests" in one of the other columns. They are requests-for-dropoffs, not dropoffs themselves. They should get cleared up like they have been in the past, it's just now they show in that table. Cheers, Jules. On 13/11/2024 3:25 pm, John Thurston via ZendTo wrote: > > Updating our test-system seemed to work perfectly. Not so for production. > > After updating from 6.05-4 to 6.13-3, I have some strange behavior > (and have reverted to the old, by way of a VMWare snapshot). > > New drop-off and pickup seems to work as expected. Picking up recent > drop-offs seemed to work as expected. But the "Show All Drop-offs" now > contains some entries with numeric values (e.g. "235 637 597") in > place of the expected strings (e.g. "22iUmVdjs9WxszxD"). I exported > all of the drop-offs to a CVS. All of the numeric clamIDs show a zero > size. And most of them are well past their expiration date. Most are > only a little old, but some are more than 6-months old. > > So I /suspect/ there are some old entries in the database which > weren't cleaned up in the normal course of operations. The new code in > 6.13 is finding them, interpreting them, and adding them to the list > of available downloads. I also /suspect/ that the next reaping through > the database by the new code would clean them out. > > But I couldn't be sure, so I've reverted to 6.05 while I try to figure > out what it is doing and if it is safe. > > I know that 6.13 is now a couple of years old, so others probably > performed their update in the distant past. But does anyone have any > insight or advice? > > > -- > -- > Do things because you should, not just because you can. > > John Thurston 907-465-8591 > John.Thurston at alaska.gov > Department of Administration > State of Alaska > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Talent is God-given ... be humble; fame is man-given ... be grateful; conceit is self-given ... be careful.' - John Wooden www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From jules at zend.to Wed Nov 13 15:54:30 2024 From: jules at zend.to (jules at zend.to) Date: Wed, 13 Nov 2024 15:54:30 +0000 Subject: [ZendTo] Can I disable Captcha for specific users? In-Reply-To: References: <73abe35e-db86-411b-872a-84a05535df93@zend.to> Message-ID: You can disable the requirement for a CAPTCHA for users on internal networks. Look for the word "localIPSubnets" in /opt/zendto/config/preferences.php. There is also the 'humanDownloads' setting in there which you should investigate. Hope that helps, Jules. On 16/09/2024 4:55 pm, Ray Lauff via ZendTo wrote: > Hello all. I have a couple of users who are frequently using a ?departmental? account to receive documents and then forwarding the links to other folks. > > A few of the folks constantly have issues with the captcha. > > Is there a way to disable that requirement for specific internal users? > > Thanks in advance for any help. > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'I never saw a wild thing Sorry for itself.' - D.H. Lawrence www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.thurston at alaska.gov Wed Nov 13 16:44:05 2024 From: john.thurston at alaska.gov (John Thurston) Date: Wed, 13 Nov 2024 07:44:05 -0900 Subject: [ZendTo] Problem updating 6.05-4 to 6.13-3 In-Reply-To: References: <0b5a4557-08b3-4448-88a4-114f9117d930@alaska.gov> <4983bdcf-f105-4c03-a3c2-01d329c7a687@zend.to> <1fb199fb-611d-4fe6-ba31-ec4ae46be59d@alaska.gov> Message-ID: I can see what you mean when I look at my new-to-me 6.13 test-installation. Thank you for the guidance. On that system, after I make a 'request', the "Global Drop-off List" has similar looking numeric "Claim ID" (e.g. "828 320 622") and the word "Request" in the "Size" column. Interestingly, the 'requests' are shown with yellow backgrounds in the table cells. On the system I updated from 6.05 --> 6.13, the numeric entries appeared with "0" (zero) in the "Size" column (rather than the word "Request"). And they appeared in the same table color-scheme as all of the drop-offs. On that system, the entries carried dates ranging from 20240416 --> 20241112 (our requests should expire after 7 days). They all appeared with numeric "Claim ID", "0" in the "Size", and with no distinctive background. So my concerns here are: * Some parts of the code recognize them as Requests, other parts seem not to * New Requests must be stored differently than old instances, as they are displayed differently in the Global List 1. Will these Old Requests (which display differently), behave as expected? 2. Will the ancient Requests now be caught by the reaper? I can live with yes or no for either question. I'd like to know what to tell my customers to expect. -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska On 11/13/2024 6:51 AM, jules at zend.to wrote: > The ones with the numeric values should be labelled as "requests" in > one of the other columns. They are requests-for-dropoffs, not dropoffs > themselves. They should get cleared up like they have been in the > past, it's just now they show in that table. > > Cheers, > Jules. > > > On 13/11/2024 3:25 pm, John Thurston via ZendTo wrote: >> >> Updating our test-system seemed to work perfectly. Not so for production. >> >> After updating from 6.05-4 to 6.13-3, I have some strange behavior >> (and have reverted to the old, by way of a VMWare snapshot). >> >> New drop-off and pickup seems to work as expected. Picking up recent >> drop-offs seemed to work as expected. But the "Show All Drop-offs" >> now contains some entries with numeric values (e.g. "235 637 597") in >> place of the expected strings (e.g. "22iUmVdjs9WxszxD"). I exported >> all of the drop-offs to a CVS. All of the numeric clamIDs show a zero >> size. And most of them are well past their expiration date. Most are >> only a little old, but some are more than 6-months old. >> >> So I /suspect/ there are some old entries in the database which >> weren't cleaned up in the normal course of operations. The new code >> in 6.13 is finding them, interpreting them, and adding them to the >> list of available downloads. I also /suspect/ that the next reaping >> through the database by the new code would clean them out. >> >> But I couldn't be sure, so I've reverted to 6.05 while I try to >> figure out what it is doing and if it is safe. >> >> I know that 6.13 is now a couple of years old, so others probably >> performed their update in the distant past. But does anyone have any >> insight or advice? >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.thurston at alaska.gov Wed Nov 13 20:30:26 2024 From: john.thurston at alaska.gov (John Thurston) Date: Wed, 13 Nov 2024 11:30:26 -0900 Subject: [ZendTo] Problem updating 6.05-4 to 6.13-3 In-Reply-To: References: <0b5a4557-08b3-4448-88a4-114f9117d930@alaska.gov> <4983bdcf-f105-4c03-a3c2-01d329c7a687@zend.to> <1fb199fb-611d-4fe6-ba31-ec4ae46be59d@alaska.gov> Message-ID: A little more information. I've lifted the cover and peeked at the data tables in the sqlite database. It looks like I have several 'requests' with "Expiry" values of 4080127620 and 4083327900. If my epoch calculations are correct, those are April 17, 2099 and May 24, 2099? So I suppose it is little wonder that the reaping process hasn't cleaned them out. It is interesting that they all have the same "SrcEmail", and were created at 1713286033 and 1716486355 (April 16, 2024 and May 23, 2024). It kind of looks like they were assigned a 75-year lifetime. And it looks like that is just an editable number in the 6.05 web interface. "Drop-off must occur between XXX and YYY", and the fields are user-editable with no limits. Where the 6.13 interface has a nice little calendar control, managed by the new 'maxRequestEndDays' setting. So my user in April was tricky, and simply changed the '2024' in that text box to '2099', giving me entries in my 'reqtable' which the reaper will never act on. It looks like in 6.13, 'Requests' can be deleted from the "Global Drop-off List" in the same way that 'Dropoffs' can be deleted in 6.05. So my hunch is, I can proceed with my 6.05 --> 6.13 update. And when it is done, I can use the "Global Drop-off List" to select and delete those long-lived 'requests'. -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska On 11/13/2024 7:44 AM, John Thurston via ZendTo wrote: > > I can see what you mean when I look at my new-to-me 6.13 > test-installation. Thank you for the guidance. > > On that system, after I make a 'request', the "Global Drop-off List" > has similar looking numeric "Claim ID" (e.g. "828 320 622") and the > word "Request" in the "Size" column. Interestingly, the 'requests' are > shown with yellow backgrounds in the table cells. > > On the system I updated from 6.05 --> 6.13, the numeric entries > appeared with "0" (zero) in the "Size" column (rather than the word > "Request"). And they appeared in the same table color-scheme as all of > the drop-offs. > > On that system, the entries carried dates ranging from 20240416 --> > 20241112 (our requests should expire after 7 days). They all appeared > with numeric "Claim ID", "0" in the "Size", and with no distinctive > background. So my concerns here are: > > * Some parts of the code recognize them as Requests, other parts > seem not to > * New Requests must be stored differently than old instances, as > they are displayed differently in the Global List > > 1. Will these Old Requests (which display differently), behave as > expected? > 2. Will the ancient Requests now be caught by the reaper? > > I can live with yes or no for either question. I'd like to know what > to tell my customers to expect. > > -- > Do things because you should, not just because you can. > > John Thurston 907-465-8591 > John.Thurston at alaska.gov > Department of Administration > State of Alaska > On 11/13/2024 6:51 AM, jules at zend.to wrote: >> The ones with the numeric values should be labelled as "requests" in >> one of the other columns. They are requests-for-dropoffs, not >> dropoffs themselves. They should get cleared up like they have been >> in the past, it's just now they show in that table. >> >> Cheers, >> Jules. >> >> >> On 13/11/2024 3:25 pm, John Thurston via ZendTo wrote: >>> >>> Updating our test-system seemed to work perfectly. Not so for >>> production. >>> >>> After updating from 6.05-4 to 6.13-3, I have some strange behavior >>> (and have reverted to the old, by way of a VMWare snapshot). >>> >>> New drop-off and pickup seems to work as expected. Picking up recent >>> drop-offs seemed to work as expected. But the "Show All Drop-offs" >>> now contains some entries with numeric values (e.g. "235 637 597") >>> in place of the expected strings (e.g. "22iUmVdjs9WxszxD"). I >>> exported all of the drop-offs to a CVS. All of the numeric clamIDs >>> show a zero size. And most of them are well past their expiration >>> date. Most are only a little old, but some are more than 6-months old. >>> >>> So I /suspect/ there are some old entries in the database which >>> weren't cleaned up in the normal course of operations. The new code >>> in 6.13 is finding them, interpreting them, and adding them to the >>> list of available downloads. I also /suspect/ that the next reaping >>> through the database by the new code would clean them out. >>> >>> But I couldn't be sure, so I've reverted to 6.05 while I try to >>> figure out what it is doing and if it is safe. >>> >>> I know that 6.13 is now a couple of years old, so others probably >>> performed their update in the distant past. But does anyone have any >>> insight or advice? >>> >>> > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.thurston at alaska.gov Thu Nov 14 19:47:47 2024 From: john.thurston at alaska.gov (John Thurston) Date: Thu, 14 Nov 2024 10:47:47 -0900 Subject: [ZendTo] Extraneous log message in 6.13 ? References: <891a19c3-6bbd-464f-b6a7-9d64eabc5073@alaska.gov> Message-ID: Since updating from 6.05 --> 6.13 I see new lines in my zendto.log > 2024-11-14 10:31:09 10.3.65.34 [Alaska ZendTo]: Looking for recip > 311218 in dropoff 206186 produced Array > ( > ??? [0] => John Doe > ??? [1] => John.Doe at alaska.gov > ??? [2] => 311218 > ) At first I thought they were trying to tell me something was wrong after my update, but with more study, they appear to be informational. I think I've traced this back to line 1408 of /opt/zendto/lib/SQLite3.php > $this->dropbox->writeToLog("Looking for recip $rID in dropoff $dID > produced ".print_r($rows[0],TRUE)); Which looks to me like a bit of pre-production logging. I can't think of any reason I care more about this lookup activity than anything else being retrieved from the database. Nor can I think of any reason not to comment this out and reduce the noise in my log. Anyone wanna talk me out of this? -- -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska -------------- next part -------------- An HTML attachment was scrubbed... URL: From jules at zend.to Fri Nov 15 17:46:23 2024 From: jules at zend.to (jules at zend.to) Date: Fri, 15 Nov 2024 17:46:23 +0000 Subject: [ZendTo] Problem updating 6.05-4 to 6.13-3 In-Reply-To: References: <0b5a4557-08b3-4448-88a4-114f9117d930@alaska.gov> <4983bdcf-f105-4c03-a3c2-01d329c7a687@zend.to> <1fb199fb-611d-4fe6-ba31-ec4ae46be59d@alaska.gov> Message-ID: Hi John, Yes, that sounds entirely sensible. Clearly something I addressed in some version between 6.05 and 6.13. I might have even mentioned it in the ChangeLog somewhere... :-) Cheers, Jules. On 13/11/2024 8:30 pm, John Thurston via ZendTo wrote: > > A little more information. I've lifted the cover and peeked at the > data tables in the sqlite database. > > It looks like I have several 'requests' with "Expiry" values of > 4080127620 and 4083327900. If my epoch calculations are correct, those > are April 17, 2099 and May 24, 2099? So I suppose it is little wonder > that the reaping process hasn't cleaned them out. It is interesting > that they all have the same "SrcEmail", and were created at 1713286033 > and 1716486355 (April 16, 2024 and May 23, 2024). It kind of looks > like they were assigned a 75-year lifetime. > > And it looks like that is just an editable number in the 6.05 web > interface. "Drop-off must occur between XXX and YYY", and the fields > are user-editable with no limits. Where the 6.13 interface has a nice > little calendar control, managed by the new 'maxRequestEndDays' > setting. So my user in April was tricky, and simply changed the '2024' > in that text box to '2099', giving me entries in my 'reqtable' which > the reaper will never act on. > > It looks like in 6.13, 'Requests' can be deleted from the "Global > Drop-off List" in the same way that 'Dropoffs' can be deleted in 6.05. > > So my hunch is, I can proceed with my 6.05 --> 6.13 update. And when > it is done, I can use the "Global Drop-off List" to select and delete > those long-lived 'requests'. > > -- > Do things because you should, not just because you can. > > John Thurston 907-465-8591 > John.Thurston at alaska.gov > Department of Administration > State of Alaska > On 11/13/2024 7:44 AM, John Thurston via ZendTo wrote: >> >> I can see what you mean when I look at my new-to-me 6.13 >> test-installation. Thank you for the guidance. >> >> On that system, after I make a 'request', the "Global Drop-off List" >> has similar looking numeric "Claim ID" (e.g. "828 320 622") and the >> word "Request" in the "Size" column. Interestingly, the 'requests' >> are shown with yellow backgrounds in the table cells. >> >> On the system I updated from 6.05 --> 6.13, the numeric entries >> appeared with "0" (zero) in the "Size" column (rather than the word >> "Request"). And they appeared in the same table color-scheme as all >> of the drop-offs. >> >> On that system, the entries carried dates ranging from 20240416 --> >> 20241112 (our requests should expire after 7 days). They all appeared >> with numeric "Claim ID", "0" in the "Size", and with no distinctive >> background. So my concerns here are: >> >> * Some parts of the code recognize them as Requests, other parts >> seem not to >> * New Requests must be stored differently than old instances, as >> they are displayed differently in the Global List >> >> 1. Will these Old Requests (which display differently), behave as >> expected? >> 2. Will the ancient Requests now be caught by the reaper? >> >> I can live with yes or no for either question. I'd like to know what >> to tell my customers to expect. >> >> -- >> Do things because you should, not just because you can. >> >> John Thurston 907-465-8591 >> John.Thurston at alaska.gov >> Department of Administration >> State of Alaska >> On 11/13/2024 6:51 AM, jules at zend.to wrote: >>> The ones with the numeric values should be labelled as "requests" in >>> one of the other columns. They are requests-for-dropoffs, not >>> dropoffs themselves. They should get cleared up like they have been >>> in the past, it's just now they show in that table. >>> >>> Cheers, >>> Jules. >>> >>> >>> On 13/11/2024 3:25 pm, John Thurston via ZendTo wrote: >>>> >>>> Updating our test-system seemed to work perfectly. Not so for >>>> production. >>>> >>>> After updating from 6.05-4 to 6.13-3, I have some strange behavior >>>> (and have reverted to the old, by way of a VMWare snapshot). >>>> >>>> New drop-off and pickup seems to work as expected. Picking up >>>> recent drop-offs seemed to work as expected. But the "Show All >>>> Drop-offs" now contains some entries with numeric values (e.g. "235 >>>> 637 597") in place of the expected strings (e.g. >>>> "22iUmVdjs9WxszxD"). I exported all of the drop-offs to a CVS. All >>>> of the numeric clamIDs show a zero size. And most of them are well >>>> past their expiration date. Most are only a little old, but some >>>> are more than 6-months old. >>>> >>>> So I /suspect/ there are some old entries in the database which >>>> weren't cleaned up in the normal course of operations. The new code >>>> in 6.13 is finding them, interpreting them, and adding them to the >>>> list of available downloads. I also /suspect/ that the next reaping >>>> through the database by the new code would clean them out. >>>> >>>> But I couldn't be sure, so I've reverted to 6.05 while I try to >>>> figure out what it is doing and if it is safe. >>>> >>>> I know that 6.13 is now a couple of years old, so others probably >>>> performed their update in the distant past. But does anyone have >>>> any insight or advice? >>>> >>>> >> >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'We have an asset out of containment.' - Jurassic World www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From jules at zend.to Fri Nov 15 17:49:08 2024 From: jules at zend.to (jules at zend.to) Date: Fri, 15 Nov 2024 17:49:08 +0000 Subject: [ZendTo] Extraneous log message in 6.13 ? In-Reply-To: References: <891a19c3-6bbd-464f-b6a7-9d64eabc5073@alaska.gov> Message-ID: Hi John, Sorry about that, a debug message I forgot to remove! Yes, just delete it or comment it out ("//" at the start of the line should do the trick). There's no need to restart anything after that edit. Cheers, Jules. On 14/11/2024 7:47 pm, John Thurston via ZendTo wrote: > > Since updating from 6.05 --> 6.13 I see new lines in my zendto.log > >> 2024-11-14 10:31:09 10.3.65.34 [Alaska ZendTo]: Looking for recip >> 311218 in dropoff 206186 produced Array >> ( >> ??? [0] => John Doe >> ??? [1] => John.Doe at alaska.gov >> ??? [2] => 311218 >> ) > > At first I thought they were trying to tell me something was wrong > after my update, but with more study, they appear to be informational. > I think I've traced this back to line 1408 of /opt/zendto/lib/SQLite3.php > >> $this->dropbox->writeToLog("Looking for recip $rID in dropoff $dID >> produced ".print_r($rows[0],TRUE)); > > Which looks to me like a bit of pre-production logging. > > I can't think of any reason I care more about this lookup activity > than anything else being retrieved from the database. Nor can I think > of any reason not to comment this out and reduce the noise in my log. > > Anyone wanna talk me out of this? > > -- > -- > Do things because you should, not just because you can. > > John Thurston 907-465-8591 > John.Thurston at alaska.gov > Department of Administration > State of Alaska > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'The past is supposed to be a place of reference, not a place of residence! There is a reason why your car has a big windshield and a small rearview mirror. You are supposed to keep your eyes on where you are going, and just occasionally check out where you have been.' - Willie Jolley www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From jules at zend.to Fri Nov 15 17:54:48 2024 From: jules at zend.to (jules at zend.to) Date: Fri, 15 Nov 2024 17:54:48 +0000 Subject: [ZendTo] Adding Support for Cloudflare's Turnstyle for Captcha/Human Verification In-Reply-To: References: Message-ID: Hi Ricky, Kris, That would be a great contribution, yes please. If you could send me a patch against the current beta that's on the website, that would be great. My git knowledge is growing, but I haven't got as far as pull requests yet. :) Thanks! Jules. On 14/08/2024 3:43 pm, Ricky Boone via ZendTo wrote: > I agree. I'm not sure if Jules or others he may have delegated this > to are taking contributions such as pull requests (or equivalent) for > possible inclusion to the main project. Time permitting, I am going > to try to take what Kris Lou provided and have it as a selectable > option, so people can choose between the CAPTCHA services. I'm sure > there would be necessary testing and validation before assuming any > changes were appropriate for the "production" release, but I don't > want to assume, obligate, or step on anyone's toes with thiat. > > On Wed, Aug 14, 2024 at 2:25?AM Gregg Douglas via ZendTo wrote: >> Hi, >> >> Would be great if this was included in the ZendTO packages. >> >> regards >> Gregg >> >> >> On Tue, Aug 13, 2024 at 8:03?PM Ricky Boone via ZendTo wrote: >>> (Just realized I misspelled "Turnstile" as "Turnstyle"... oof) >>> >>> Nice, thanks! I'll have to give that a shot. >>> >>> On Tue, Aug 13, 2024 at 12:27?PM Kris Lou via ZendTo wrote: >>>> I did this last year: >>>> >>>> ----------------------- >>>> >>>> With the CloudFlare Turnstile Site Key (as recaptchaPublicKey), Secret Key (as recaptchaPrivateKey) and using "?compat=recaptcha", the following seems to work. >>>> >>>> /opt/zendto/templates/header.tpl >>>> 43,44c43,44 >>>> < grecaptcha.render('google-recaptcha', { >>>> < 'sitekey' : '{$recaptchaSiteKey}' >>>> --- >>>>> grecaptcha.render('cf-turnstile', { >>>>> 'sitekey' : '{$recaptchaSiteKey}' >>>> 51c51,52 >>>> < >>>> --- >>>>> >>>>> >>>> 53c54,55 >>>> < >>>> --- >>>>> >>>>> >>>> /opt/zendto/templates/pickupcheck.tpl >>>> 29c29,30 >>>> <
>>>> --- >>>>> >>>>>
>>>> /opt/zendto/templates/verify.tpl >>>> 155c155,156 >>>> <
>>>> --- >>>>> >>>>>
>>>> /opt/zendto/www/ReCaptcha/RequestMethod/CurlPost.php >>>> 43,44c43,44 >>>> < const SITE_VERIFY_URL = 'https://www.recaptcha.net/recaptcha/api/siteverify'; >>>> < >>>> --- >>>>> // const SITE_VERIFY_URL = 'https://www.recaptcha.net/recaptcha/api/siteverify'; >>>>> const SITE_VERIFY_URL = 'https://challenges.cloudflare.com/turnstile/v0/siteverify'; >>>> >>>> Kris Lou >>>> klou at themusiclink.net >>>> >>>> >>>> On Tue, Aug 13, 2024 at 9:19?AM Ricky Boone via ZendTo wrote: >>>>> My apologies if this has already been covered, however I couldn't find >>>>> anything other than a single email in the list archive that didn't >>>>> appear to be addressed. >>>>> >>>>> The users of the instance of ZendTo that I maintain sometimes have >>>>> issues with reCAPTCHA. In almost all cases, it's either user-oriented >>>>> or an issue with their browser causing them to never get past it, with >>>>> the very rare case of an issue on Google's end. I'd still like some >>>>> reasonable mechanism to perform human verification to reduce the risk >>>>> posed without it, however it looks like the only options available are >>>>> either Google's standard or invisible reCAPTCHA v2 services, with the >>>>> "invisible" option having noted issues since 2018 (at least in the >>>>> config comments). >>>>> >>>>> So I don't start going down a path that is already underway, are there >>>>> any plans to implement support for other CAPTCHA services/libraries, >>>>> such as Cloudflare's Turnstyle or hCaptcha? If not, are there any >>>>> concerns with me taking a stab at it and providing what I come up >>>>> with? I realize that ZendTo is not being tracked on a public source >>>>> code repo like Github or GitLab (at least officially, as far as I can >>>>> tell), but I didn't want to do something that couldn't be contributed >>>>> back in some way. >>>>> >>>>> _______________________________________________ >>>>> ZendTo mailing list >>>>> ZendTo at zend.to >>>>> http://jul.es/mailman/listinfo/zendto >>>> _______________________________________________ >>>> ZendTo mailing list >>>> ZendTo at zend.to >>>> http://jul.es/mailman/listinfo/zendto >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM The current UK shipping forecast: Viking, North Utsire: Southwesterly veering westerly, 6 to gale 8, occasionally severe gale 9 in north, perhaps storm 10 later in north. Rough becoming very rough or high, occasionally very high later in north. Rain then squally wintry showers. Moderate or poor, occasionally good. www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: