From Etienne.Vogt at obspm.fr Tue Sep 1 10:19:58 2020 From: Etienne.Vogt at obspm.fr (Etienne Vogt) Date: Tue, 1 Sep 2020 11:19:58 +0200 (CEST) Subject: [ZendTo] LDAP authentication broken after 6.05-2 upgrade In-Reply-To: References: <8421be91-35bf-9270-a580-b5825e3fd401@Zend.To> Message-ID: On Mon, 31 Aug 2020, Jules wrote: > Hopefully those 2 bugs are squashed in 6.05-4 which I have just released for > you. > > Please can you do another quick update and see if it's actually working now? Apart from that still present php warning, 6.05-4 seems to work fine : [Tue Sep 01 11:09:56.369116 2020] [php7:warn] [pid 25139] [client 147.94.6.149:57385] PHP Warning: Declaration of NSSMultiAuthenticator::authenticate(&$uname, $password, &$response, $errormsg) should be compatible with NSSAuthenticator::authenticate(&$uname, $password, &$response, &$errormessage) in /opt/zendto/lib/NSSMultiAuthenticator.php on line 0 -- Etienne Vogt (Etienne.Vogt at obspm.fr) Observatoire de Paris-Meudon Service Informatique From manty at manty.net Thu Sep 3 10:36:31 2020 From: manty at manty.net (Santiago Garcia Mantinan) Date: Thu, 3 Sep 2020 11:36:31 +0200 Subject: [ZendTo] Patch for recaptcha and tne new_dropoff.js problem (for the beta) In-Reply-To: References: <070812e7-a298-e917-c2ba-97a7510f7c66@Zend.To> Message-ID: Hi! I'd like to make you a new suggestion and also comment on your mail. The suggestion would be this: --- templates/header.tpl 2020-09-03 10:17:32.884356266 +0200 +++ templates/header.tpl~ 2020-09-02 10:06:14.000000000 +0200 @@ -184,7 +184,7 @@ name: 'localeForm', id: 'localeForm', method: 'post', - action: '{call name=hidePHPExt t='changelocale.php'}', + action: '{$zendToURL}{call name=hidePHPExt t='changelocale.php'}', enctype: 'multipart/form-data', style: 'display:none' })); I have tested this change and it works, I'm having the external site redirect you to the internal URL if you are coming from the intranet and without that change I was redirected to the external site again every time i switched locale, with this change I stay inside without any problem. I also have a question on translations, where should one mail updates on them, to the list or to you directly? And about translations... I'm adapting all of our translated templates because the wording that I can get to doesn't make any sense in Spanish or Galician (to which I'm translating) but I've seen similar trouble on other languages I understand, the thing is that maybe we should start a discussion with translators to see if we can get some flexibility with variables for the company stuff, I'll try to illustrate this with an example: I'm using zendto at work, the company should be pretty similar to your setup as I work for the Council of A Coru?a, well, if I setup the variables like this: OrganizationShortName = "A Coru?a" OrganizationShortType = "the Council" Things look a bit odd even in english, but in spanish or similar... they just don't go. Maybe the best solution is to edit the templates like I'm doing it already, but maybe we could come up with something better without needing too much work on code that would allow this, or maybe there is no good way. Some of the problems I find is with that article, "the Council" in spanish is "el Ayuntamiento" which then has contractions if you stick it to "users of", which is "usuarios de", as it would make "usuarios del Ayuntamiento", but if the company has a femenine article it wouldn't make a contraction and so it happens with plural (masculine and femenine) and those adjectives would have to get translations as well, ... so it is basically very difficult, don't know if it really makes sense even to try to make any changes, but maybe we can discuss it a bit and try to get to something :-? Anyway... back to the old email... > Using recaptcha.net instead of recaptcha.google.com is the change recommended by Google so that the reCAPTCHA service works for users in China, who cannot reach 99% of Google services. Because it's on a separate domain name, China allow that 1 Google service through their firewall. Ok then, but you are still using www.google.com on the CurlPost.php, so then... --- p/opt/zendto/www/ReCaptcha/RequestMethod/CurlPost.php 2020-03-04 16:56:42.000000000 +0100 +++ /opt/zendto/www/ReCaptcha/RequestMethod/CurlPost.php 2020-08-17 11:42:15.947472184 +0200 @@ -40,7 +40,7 @@ * URL to which requests are sent via cURL. * @const string */ - const SITE_VERIFY_URL = 'https://www.google.com/recaptcha/api/siteverify'; + const SITE_VERIFY_URL = 'https://www.recaptcha.net/recaptcha/api/siteverify'; /** * Curl connection to the reCAPTCHA service > In the call to include the dropoff_js.tpl file, the {} brackets tell the Smarty template system to read and process the new_dropoff.js.tpl file, which you will find in /opt/zendto/templates. This allows me to substitute Smarty variables in the JS code, while keeping it all in a separate file. I can see that now on my 6.05 setup but it was not like that when I tested it on 6.04, I suppose it was kind of a mess with my setup. Sorry about the noise. Thanks for your work. Regards... -- Manty/BestiaTester -> http://manty.net From manty at manty.net Thu Sep 3 10:38:25 2020 From: manty at manty.net (Santiago Garcia Mantinan) Date: Thu, 3 Sep 2020 11:38:25 +0200 Subject: [ZendTo] Updating translations for the last beta and couple of bugs In-Reply-To: References: <6e10ffbd-12f3-6bcf-8de2-fe5e7dbfd713@Zend.To> Message-ID: > Have you got /usr/bin/lsb_release installed? > If so, I've just found and fixed that one for you. I was mistakenly assuming the version number was "major.minor" and not just "major". You got this right, fix worked ok. Regards. -- Manty/BestiaTester -> http://manty.net From Jules at Zend.To Thu Sep 3 16:26:04 2020 From: Jules at Zend.To (Jules) Date: Thu, 3 Sep 2020 16:26:04 +0100 Subject: [ZendTo] Patch for recaptcha and tne new_dropoff.js problem (for the beta) In-Reply-To: References: <070812e7-a298-e917-c2ba-97a7510f7c66@Zend.To> Message-ID: <3e6fd956-9058-e1a7-f07f-7a2dfc361a84@Zend.To> Manty, On 03/09/2020 10:36, Santiago Garcia Mantinan wrote: > Hi! > > I'd like to make you a new suggestion and also comment on your mail. > The suggestion would be this: > > --- templates/header.tpl 2020-09-03 10:17:32.884356266 +0200 > +++ templates/header.tpl~ 2020-09-02 10:06:14.000000000 +0200 > @@ -184,7 +184,7 @@ > name: 'localeForm', > id: 'localeForm', > method: 'post', > - action: '{call name=hidePHPExt t='changelocale.php'}', > + action: '{$zendToURL}{call name=hidePHPExt t='changelocale.php'}', > enctype: 'multipart/form-data', > style: 'display:none' > })); > > I have tested this change and it works, I'm having the external site > redirect you to the internal URL if you are coming from the intranet > and without that change I was redirected to the external site again > every time i switched locale, with this change I stay inside without > any problem. That change is already done. I think you might be running with an out of date header.tpl. I detest the deb method of handling modified config files in package upgrades. They ask the user, who most likely won't have a clue what the correct answer to the question is. Just put them both in like rpm does, and at least give the packager the power to set the default choice! > > I also have a question on translations, where should one mail updates > on them, to the list or to you directly? Individual text changes, probably just me. But your next topic definitely needs a thread of its own on the mailing list. I openly admit the existing zendto.conf constants could be better. But at the time I didn't know any useful definition of "better", and so did what I did. If between you all, you can come up with a better solution that works for more people and doesn't make it impossible for me (and we need a way to automatically migrate existing sites in the "upgrade" command), then I'm all in favour of it. You guys know far more about this stuff than I do (being a simple English speaker who has never had to worry about genders of words, among other things). > And about translations... I'm adapting all of our translated templates > because the wording that I can get to doesn't make any sense in > Spanish or Galician (to which I'm translating) but I've seen similar > trouble on other languages I understand, the thing is that maybe we > should start a discussion with translators to see if we can get some > flexibility with variables for the company stuff, I'll try to > illustrate this with an example: > > I'm using zendto at work, the company should be pretty similar to your > setup as I work for the Council of A Coru?a, well, if I setup the > variables like this: > > OrganizationShortName = "A Coru?a" > OrganizationShortType = "the Council" > > Things look a bit odd even in english, but in spanish or similar... > they just don't go. > > Maybe the best solution is to edit the templates like I'm doing it > already, but maybe we could come up with something better without > needing too much work on code that would allow this, or maybe there is > no good way. > > Some of the problems I find is with that article, "the Council" in > spanish is "el Ayuntamiento" which then has contractions if you stick > it to "users of", which is "usuarios de", as it would make "usuarios > del Ayuntamiento", but if the company has a femenine article it > wouldn't make a contraction and so it happens with plural (masculine > and femenine) and those adjectives would have to get translations as > well, ... so it is basically very difficult, don't know if it really > makes sense even to try to make any changes, but maybe we can discuss > it a bit and try to get to something :-? > > Anyway... back to the old email... > >> Using recaptcha.net instead of recaptcha.google.com is the change recommended by Google so that the reCAPTCHA service works for users in China, who cannot reach 99% of Google services. Because it's on a separate domain name, China allow that 1 Google service through their firewall. > Ok then, but you are still using www.google.com on the CurlPost.php, so then... > > --- p/opt/zendto/www/ReCaptcha/RequestMethod/CurlPost.php > 2020-03-04 16:56:42.000000000 +0100 > +++ /opt/zendto/www/ReCaptcha/RequestMethod/CurlPost.php 2020-08-17 > 11:42:15.947472184 +0200 > @@ -40,7 +40,7 @@ > * URL to which requests are sent via cURL. > * @const string > */ > - const SITE_VERIFY_URL = 'https://www.google.com/recaptcha/api/siteverify'; > + const SITE_VERIFY_URL = > 'https://www.recaptcha.net/recaptcha/api/siteverify'; > > /** > * Curl connection to the reCAPTCHA service Well spotted! Fixed for the next release. Cheers, Jules. Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Give a man a fish, and you feed him for a day. Teach a man to fish, and he'll sit in a boat and drink beer all day.' - Anon www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From manty at manty.net Fri Sep 4 08:59:45 2020 From: manty at manty.net (Santiago Garcia Mantinan) Date: Fri, 4 Sep 2020 09:59:45 +0200 Subject: [ZendTo] Patch for recaptcha and tne new_dropoff.js problem (for the beta) In-Reply-To: References: <070812e7-a298-e917-c2ba-97a7510f7c66@Zend.To> <3e6fd956-9058-e1a7-f07f-7a2dfc361a84@Zend.To> Message-ID: Hi again! > That change is already done. I think you might be running with an out of date header.tpl. > > I detest the deb method of handling modified config files in package upgrades. They ask the user, who most likely won't have a clue what the correct answer to the question is. Just put them both in like rpm does, and at least give the packager the power to set the default choice! Well, that doesn't seem to be the case... $ dpkg -x zendto_6.05-4.deb z $ grep action: z/opt/zendto/templates/header.tpl action: '{$zendToURL}{call name=hidePHPExt t='changelocale.php'}', > But your next topic definitely needs a thread of its own on the mailing list. I openly admit the existing zendto.conf constants could be better. But at the time I didn't know any useful definition of "better", and so did what I did. > If between you all, you can come up with a better solution that works for more people and doesn't make it impossible for me (and we need a way to automatically migrate existing sites in the "upgrade" command), then I'm all in favour of it. > You guys know far more about this stuff than I do (being a simple English speaker who has never had to worry about genders of words, among other things). I'll try to open a thread and see if people can come to some ideas for this, but I find it very difficult. Regards... -- Manty/BestiaTester -> http://manty.net From manty at manty.net Fri Sep 4 09:28:20 2020 From: manty at manty.net (Santiago Garcia Mantinan) Date: Fri, 4 Sep 2020 10:28:20 +0200 Subject: [ZendTo] Patch for recaptcha and tne new_dropoff.js problem (for the beta) In-Reply-To: References: <070812e7-a298-e917-c2ba-97a7510f7c66@Zend.To> <3e6fd956-9058-e1a7-f07f-7a2dfc361a84@Zend.To> Message-ID: Sorry again... > > That change is already done. I think you might be running with an out of date header.tpl. I just realised that I had posted the diff reversed, what I was suggesting was to remove the {$zendToURL} from the action. At least on my setup it is causing me the troubles I was explaining and without it it works as expected, I fail to see why was the zendToURL added there. Regards. -- Manty/BestiaTester -> http://manty.net From Jules at Zend.To Fri Sep 4 09:53:32 2020 From: Jules at Zend.To (Jules) Date: Fri, 4 Sep 2020 09:53:32 +0100 Subject: [ZendTo] Patch for recaptcha and tne new_dropoff.js problem (for the beta) In-Reply-To: References: <070812e7-a298-e917-c2ba-97a7510f7c66@Zend.To> <3e6fd956-9058-e1a7-f07f-7a2dfc361a84@Zend.To> Message-ID: <8d0548a5-8869-e404-e301-37029f043206@Zend.To> Manty, On 04/09/2020 09:28, Santiago Garcia Mantinan wrote: > Sorry again... > > >>> That change is already done. I think you might be running with an out of date header.tpl. > I just realised that I had posted the diff reversed, what I was > suggesting was to remove the {$zendToURL} from the action. I finally just realised that! :-) > At least on > my setup it is causing me the troubles I was explaining and without it > it works as expected, I fail to see why was the zendToURL added there. Fair point. It just worries me that I put it there for some good reason, so I want to have a think before I take it out. I've got some sites who have ZendTo embedded in an iframe, maybe it was for them? I'll have a think... Cheers, Jules. > > Regards. 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 manty at manty.net Tue Sep 8 08:42:30 2020 From: manty at manty.net (Santiago Garcia Mantinan) Date: Tue, 8 Sep 2020 09:42:30 +0200 Subject: [ZendTo] Patch for recaptcha and tne new_dropoff.js problem (for the beta) In-Reply-To: References: <070812e7-a298-e917-c2ba-97a7510f7c66@Zend.To> <3e6fd956-9058-e1a7-f07f-7a2dfc361a84@Zend.To> <8d0548a5-8869-e404-e301-37029f043206@Zend.To> Message-ID: Hi! Sorry to come over this again, but I've just learned that the full url is being used all over the code, templates are full of $zendToURL uses :-( > I just realised that I had posted the diff reversed, what I was > suggesting was to remove the {$zendToURL} from the action. > > I finally just realised that! :-) > > At least on > my setup it is causing me the troubles I was explaining and without it > it works as expected, I fail to see why was the zendToURL added there. > > Fair point. It just worries me that I put it there for some good reason, so I want to have a think before I take it out. > I've got some sites who have ZendTo embedded in an iframe, maybe it was for them? > > I'll have a think... Like I said, this usage is breaking all that I want to do, as I want to have the external users hit one domain and the internal users a different one (it is the same machine, externals see it through a proxy while internals don't). I never liked web apps to use full urls or absolute ones because when you are trying to proxify things you always get to points where things break, typically this means that the internal address is shown outside, here I have zendToURL set to the external address, so what I find is that the internal guys try to access the external address. I started removing the zendToURL on the case I sent you, but when testing the full setup from inside... I found out that a lot of things were broken, basically everything that sends a post, and it was because of this zendToURL things. I'm wondering if there is some other way to solve this other than removing zendToURL all around the templates and maybe the code as well, I'm still wondering why they are there anyway, as for me (playing with proxies, having the site on a subdirectory, ...) relative paths work ok. So basically I'm a bit stuck here, I didn't want to change all the templates, but I don't see any other alternative right now :-( Any ideas? Regards... -- Manty/BestiaTester -> http://manty.net From zend.to at neilzone.co.uk Tue Sep 8 08:45:36 2020 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Tue, 8 Sep 2020 08:45:36 +0100 Subject: [ZendTo] Patch for recaptcha and tne new_dropoff.js problem (for the beta) In-Reply-To: References: <070812e7-a298-e917-c2ba-97a7510f7c66@Zend.To> <3e6fd956-9058-e1a7-f07f-7a2dfc361a84@Zend.To> <8d0548a5-8869-e404-e301-37029f043206@Zend.To> <00783118-B3AD-4691-9B5C-A0BE6A6EDC64@neilzone.co.uk> Message-ID: > On 8 Sep 2020, at 08:42, Santiago Garcia Mantinan via ZendTo wrote: > > I want > to have the external users hit one domain and the internal users a > different one (it is the same machine, externals see it through a > proxy while internals don't)?. > > So basically I'm a bit stuck here, I didn't want to change all the > templates, but I don't see any other alternative right now Would split horizon DNS for the zendtoURL work? The IP of the proxy for external users, the IP of the machine itself for internal users? Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From manty at manty.net Tue Sep 8 09:56:24 2020 From: manty at manty.net (Santiago Garcia Mantinan) Date: Tue, 8 Sep 2020 10:56:24 +0200 Subject: [ZendTo] Patch for recaptcha and tne new_dropoff.js problem (for the beta) In-Reply-To: <00783118-B3AD-4691-9B5C-A0BE6A6EDC64@neilzone.co.uk> References: <070812e7-a298-e917-c2ba-97a7510f7c66@Zend.To> <3e6fd956-9058-e1a7-f07f-7a2dfc361a84@Zend.To> <8d0548a5-8869-e404-e301-37029f043206@Zend.To> <00783118-B3AD-4691-9B5C-A0BE6A6EDC64@neilzone.co.uk> Message-ID: Hi! > Would split horizon DNS for the zendtoURL work? The IP of the proxy for external users, the IP of the machine itself for internal users? Not really, because the external names go through a proxy (direct proxy, no reverse proxy) so I would also need an exception for the name and the name we typically use is the same for other services, so I would need to move zendto to a new name, ... a mess, really. I'm checking at removing the zendToURL before all "call name" on everything but email and looks ok so far. Still I'm wondering... why did you put all this full urls around? Regards.. -- Manty/BestiaTester -> http://manty.net From zend.to at neilzone.co.uk Tue Sep 8 09:58:03 2020 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Tue, 8 Sep 2020 09:58:03 +0100 Subject: [ZendTo] Patch for recaptcha and tne new_dropoff.js problem (for the beta) In-Reply-To: References: <070812e7-a298-e917-c2ba-97a7510f7c66@Zend.To> <3e6fd956-9058-e1a7-f07f-7a2dfc361a84@Zend.To> <8d0548a5-8869-e404-e301-37029f043206@Zend.To> <00783118-B3AD-4691-9B5C-A0BE6A6EDC64@neilzone.co.uk> Message-ID: > On 8 Sep 2020, at 09:56, Santiago Garcia Mantinan wrote: > > Still I'm wondering... why did you put all this full urls around? For what it?s worth, if Jules did decide to change this, and supported multiple URLs for the same instance of zend.to, I would be interested, because it would make hosting a .onion service version of zend.to easier! Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Wed Sep 9 09:41:34 2020 From: Jules at Zend.To (Jules) Date: Wed, 9 Sep 2020 09:41:34 +0100 Subject: [ZendTo] Patch for recaptcha and tne new_dropoff.js problem (for the beta) In-Reply-To: References: <3e6fd956-9058-e1a7-f07f-7a2dfc361a84@Zend.To> <8d0548a5-8869-e404-e301-37029f043206@Zend.To> Message-ID: <19fe47d7-77cb-2108-4fcc-d81ed9e783e6@Zend.To> Manty, All you should need to do is add ??? {$zendToURL=""} to header.tpl. That should fix it all for you. Cheers, Jules. On 08/09/2020 08:42, Santiago Garcia Mantinan wrote: > Hi! > > Sorry to come over this again, but I've just learned that the full url > is being used all over the code, templates are full of $zendToURL uses > :-( > >> I just realised that I had posted the diff reversed, what I was >> suggesting was to remove the {$zendToURL} from the action. >> >> I finally just realised that! :-) >> >> At least on >> my setup it is causing me the troubles I was explaining and without it >> it works as expected, I fail to see why was the zendToURL added there. >> >> Fair point. It just worries me that I put it there for some good reason, so I want to have a think before I take it out. >> I've got some sites who have ZendTo embedded in an iframe, maybe it was for them? >> >> I'll have a think... > Like I said, this usage is breaking all that I want to do, as I want > to have the external users hit one domain and the internal users a > different one (it is the same machine, externals see it through a > proxy while internals don't). > > I never liked web apps to use full urls or absolute ones because when > you are trying to proxify things you always get to points where things > break, typically this means that the internal address is shown > outside, here I have zendToURL set to the external address, so what I > find is that the internal guys try to access the external address. > > I started removing the zendToURL on the case I sent you, but when > testing the full setup from inside... I found out that a lot of things > were broken, basically everything that sends a post, and it was > because of this zendToURL things. > > I'm wondering if there is some other way to solve this other than > removing zendToURL all around the templates and maybe the code as > well, I'm still wondering why they are there anyway, as for me > (playing with proxies, having the site on a subdirectory, ...) > relative paths work ok. > > So basically I'm a bit stuck here, I didn't want to change all the > templates, but I don't see any other alternative right now :-( > > Any ideas? > > Regards... Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM The current UK shipping forecast: Sole, Lundy, Fastnet: West veering north or northwest, 3 to 5. Slight or moderate. Drizzle and fog patches at first. Moderate, occasionally very poor, becoming good. www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From manty at manty.net Thu Sep 10 08:40:41 2020 From: manty at manty.net (Santiago Garcia Mantinan) Date: Thu, 10 Sep 2020 09:40:41 +0200 Subject: [ZendTo] Patch for recaptcha and tne new_dropoff.js problem (for the beta) In-Reply-To: References: <3e6fd956-9058-e1a7-f07f-7a2dfc361a84@Zend.To> <8d0548a5-8869-e404-e301-37029f043206@Zend.To> <19fe47d7-77cb-2108-4fcc-d81ed9e783e6@Zend.To> Message-ID: Hi! > All you should need to do is add > {$zendToURL=""} > to header.tpl. > > That should fix it all for you. I've reversed my changes and applied this adding it at the beginning and then at the end, it didn't work either way :-( Regards... -- Manty/BestiaTester -> http://manty.net From Jules at Zend.To Thu Sep 10 17:40:46 2020 From: Jules at Zend.To (Jules) Date: Thu, 10 Sep 2020 17:40:46 +0100 Subject: [ZendTo] Patch for recaptcha and tne new_dropoff.js problem (for the beta) In-Reply-To: References: <8d0548a5-8869-e404-e301-37029f043206@Zend.To> <19fe47d7-77cb-2108-4fcc-d81ed9e783e6@Zend.To> Message-ID: Manty, Try putting it in at the start of line 4 of header.tpl. You need to leave the "" tag in lines 1-3 at the very top of the file. But you then want to set it before including the "functions.tpl" file, as that file uses the value. You might also then want to clear the output cache with ??? sudo rm -f /var/zendto/cache/*.php ??? sudo rm -f /var/zendto/templates_c/*.php and then refresh the web page. I've just tried putting in the URL of a totally different site instead of setting it to "", and that did work. The "Home" tab at the top left should take you to the URL. Cheers, Jules. On 10/09/2020 08:40, Santiago Garcia Mantinan wrote: > Hi! > >> All you should need to do is add >> {$zendToURL=""} >> to header.tpl. >> >> That should fix it all for you. > I've reversed my changes and applied this adding it at the beginning > and then at the end, it didn't work either way :-( > > Regards... > -- > Manty/BestiaTester -> http://manty.net Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM The current UK shipping forecast: Fair Isle: Southwest 5 or 6, increasing 7 or gale 8 later. Moderate or rough, becoming rough or very rough later. Occasional rain or showers. Good, occasionally poor. www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From manty at manty.net Fri Sep 11 08:00:53 2020 From: manty at manty.net (Santiago Garcia Mantinan) Date: Fri, 11 Sep 2020 09:00:53 +0200 Subject: [ZendTo] Patch for recaptcha and tne new_dropoff.js problem (for the beta) In-Reply-To: References: <8d0548a5-8869-e404-e301-37029f043206@Zend.To> <19fe47d7-77cb-2108-4fcc-d81ed9e783e6@Zend.To> Message-ID: Hi again! > Try putting it in at the start of line 4 of header.tpl. > You need to leave the "" tag in lines 1-3 at the very top of the file. > But you then want to set it before including the "functions.tpl" file, as that file uses the value. Well... it seems to work... wrongly, now the Home button will point me to wherever I already went, I mean... If I had chosen language, then home would take me to changelocale.php, but if I have entered Inbox, then home will take me to pickup_list.php and if I have entered Outbox then home will take me to dropoff_list.php, so... it doesn't work as we are stuck without an effective home button unless we change the language and then we hit home again. Regards... -- Manty/BestiaTester -> http://manty.net From Jules at Zend.To Fri Sep 11 09:40:53 2020 From: Jules at Zend.To (Jules) Date: Fri, 11 Sep 2020 09:40:53 +0100 Subject: [ZendTo] Patch for recaptcha and tne new_dropoff.js problem (for the beta) In-Reply-To: References: <19fe47d7-77cb-2108-4fcc-d81ed9e783e6@Zend.To> Message-ID: On 11/09/2020 08:00, Santiago Garcia Mantinan wrote: > Hi again! > >> Try putting it in at the start of line 4 of header.tpl. >> You need to leave the "" tag in lines 1-3 at the very top of the file. >> But you then want to set it before including the "functions.tpl" file, as that file uses the value. > Well... it seems to work... wrongly, now the Home button will point me > to wherever I already went, I mean... That button just takes you to $zendToURL with nothing appended. This is set on line 231 of /opt/zendto/templates/header.tpl. You could change it to "{$zendToURL}index" or "${zendToURL}index.php" instead. I didn't add anything, as I always think that have the "index..." on the end of a URL is just untidy and superfluous. People tend to copy and paste that URL into other things, and it looks bad. How about I change it to an "if" statement, so it doesn't add "index..." unless $zendToURL is blank? That way we both win. Change line 231 to say this instead of the current link ??????????????????????? I've just tried it, and it appears to work for me. It will be included in the next release. Cheers, Jules. > > If I had chosen language, then home would take me to changelocale.php, > but if I have entered Inbox, then home will take me to pickup_list.php > and if I have entered Outbox then home will take me to > dropoff_list.php, so... it doesn't work as we are stuck without an > effective home button unless we change the language and then we hit > home again. > > Regards... > -- > Manty/BestiaTester -> http://manty.net Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'It's in Apple's DNA that technology alone is not enough. It's technology married with liberal arts, married with the humanities, that yields us the result that makes our hearts sing.' - Steve Jobs www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From manty at manty.net Fri Sep 11 11:27:19 2020 From: manty at manty.net (Santiago Garcia Mantinan) Date: Fri, 11 Sep 2020 12:27:19 +0200 Subject: [ZendTo] Patch for recaptcha and tne new_dropoff.js problem (for the beta) In-Reply-To: References: <19fe47d7-77cb-2108-4fcc-d81ed9e783e6@Zend.To> Message-ID: Hi! > You could change it to "{$zendToURL}index" or "${zendToURL}index.php" instead. Or even to "${zendToURL}.", as browsers won't display the . you get what you wanted. The problem is that the zendToURL still appears around... I know that I had to change NSSDropoff.php for the download urls to be without it, I had done these changes: - $smarty->assign('downloadURL', $NSSDROPBOX_URL.'download?claimID=' . $this->_claimID . '&claimPasscode=' . $this->_claimPasscode . ($emailAddr?('&emailAddr='.urlencode($emailAddr)):'')); + $smarty->assign('downloadURL', 'download?claimID=' . $this->_claimID . '&claimPasscode=' . $this->_claimPasscode . ($emailAddr?('&emailAddr='.urlencode($emailAddr)):'')); else - $smarty->assign('downloadURL', $NSSDROPBOX_URL.'download.php?claimID=' . $this->_claimID . '&claimPasscode=' . $this->_claimPasscode . ($emailAddr?('&emailAddr='.urlencode($emailAddr)):'')); + $smarty->assign('downloadURL', 'download.php?claimID=' . $this->_claimID . '&claimPasscode=' . $this->_claimPasscode . ($emailAddr?('&emailAddr='.urlencode($emailAddr)):'')); But I'm also getting it on whatever.new_dropoff.tpl.php as seen on my cache, which makes dropoff fails. I don't remember where I had fixed this, I believe it was on the template, but it doesn't work with the zendToURL="" trick :-( Regards... -- Manty/BestiaTester -> http://manty.net From douglagm at gmail.com Fri Sep 11 13:36:05 2020 From: douglagm at gmail.com (Gregg Douglas) Date: Fri, 11 Sep 2020 14:36:05 +0200 Subject: [ZendTo] Request of Drop-off for Unknown Recipients References: Message-ID: Hi, When you follow the process of "Request a Drop-off" it requires a "To" Address. How would one go about if you don't know who is going to use the Drop-off So, in the example of an open Tender, you don't know who will respond to the Tender, thus it is not possible to complete the "To" field. Thanks Gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.v.sangster at abdn.ac.uk Fri Sep 11 13:56:56 2020 From: m.v.sangster at abdn.ac.uk (Sangster, Mark) Date: Fri, 11 Sep 2020 12:56:56 +0000 Subject: [ZendTo] Request of Drop-off for Unknown Recipients In-Reply-To: References: Message-ID: You could send the request to yourself, to upload it into ZendTo. Then in your Outbox look at the blue box information. Sending the claim id/passcode URL to others will grant them access. So publicise that URL somewhere for them to collect it. Cheers Mark From: ZendTo On Behalf Of Gregg Douglas via ZendTo Sent: 11 September 2020 13:36 To: ZendTo Users Cc: Gregg Douglas Subject: [ZendTo] Request of Drop-off for Unknown Recipients CAUTION: External email. Ensure this message is from a trusted source before clicking links/attachments. Hi, When you follow the process of "Request a Drop-off" it requires a "To" Address. How would one go about if you don't know who is going to use the Drop-off So, in the example of an open Tender, you don't know who will respond to the Tender, thus it is not possible to complete the "To" field. Thanks Gregg The University of Aberdeen is a charity registered in Scotland, No SC013683. Tha Oilthigh Obar Dheathain na charthannas cl?raichte ann an Alba, ?ir. SC013683. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Fri Sep 11 14:01:22 2020 From: Jules at Zend.To (Jules) Date: Fri, 11 Sep 2020 14:01:22 +0100 Subject: [ZendTo] Request of Drop-off for Unknown Recipients In-Reply-To: References: Message-ID: <21250ea6-7890-e533-659f-ef37137b2205@Zend.To> Gregg, Usually we only open tenders to a specific list of suppliers, so can send a Request to each one. Beware that each Request can only be used once. If you specify multiple "To" addresses on the form (a pop-up tip tells you how) then it will send a separate unique Request to each recipient. However, people outside your organisation don't need a Request in order to send you files (ie their bid). But doing so saves them having to verify their own email address, and means that your email address and the Subject line are pre-set for them. So getting a Request make their lives a bit easier, but they don't *have* to get one. Hope that helps, Jules. On 11/09/2020 13:36, Gregg Douglas via ZendTo wrote: > Hi, > > When you follow the process of "Request a Drop-off" it requires a "To" > Address. How would one go about if you don't know who is going to use > the Drop-off > > So, in the example of an open Tender, you don't know who will respond > to the Tender, thus it is not possible?to complete the "To" field. > > Thanks > Gregg > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'When I read Shakespeare I am struck with wonder That such trivial people should muse and thunder In such lovely language.' - D.H. Lawrence www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglagm at gmail.com Fri Sep 11 14:13:20 2020 From: douglagm at gmail.com (Gregg Douglas) Date: Fri, 11 Sep 2020 15:13:20 +0200 Subject: [ZendTo] Request of Drop-off for Unknown Recipients In-Reply-To: References: Message-ID: Hi Mark, I have tried that, but the "From" Addresses is not a field that can be changed and thus the Recipient/Sender is always me. Thanks Gregg On Fri, Sep 11, 2020 at 2:57 PM Sangster, Mark via ZendTo wrote: > You could send the request to yourself, to upload it into ZendTo. > > > > Then in your Outbox look at the blue box information. > > > > Sending the claim id/passcode URL to others will grant them access. > > > > So publicise that URL somewhere for them to collect it. > > > > Cheers > > Mark > > > > *From:* ZendTo *On Behalf Of *Gregg Douglas via > ZendTo > *Sent:* 11 September 2020 13:36 > *To:* ZendTo Users > *Cc:* Gregg Douglas > *Subject:* [ZendTo] Request of Drop-off for Unknown Recipients > > > > CAUTION: External email. Ensure this message is from a trusted source > before clicking links/attachments. > > > > Hi, > > > > When you follow the process of "Request a Drop-off" it requires a "To" > Address. How would one go about if you don't know who is going to use the > Drop-off > > > > So, in the example of an open Tender, you don't know who will respond to > the Tender, thus it is not possible to complete the "To" field. > > > > Thanks > > Gregg > > > > > The University of Aberdeen is a charity registered in Scotland, No > SC013683. > Tha Oilthigh Obar Dheathain na charthannas cl?raichte ann an Alba, ?ir. > SC013683. > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Fri Sep 11 14:25:26 2020 From: Jules at Zend.To (Jules) Date: Fri, 11 Sep 2020 14:25:26 +0100 Subject: [ZendTo] Request of Drop-off for Unknown Recipients In-Reply-To: References: Message-ID: <7d516302-3ce9-e155-5b7b-aa599143d7bb@Zend.To> The design is currently such that each Request (i.e. each Request Code number) can only be used once. If you wish to send Requests that appear to come from *other people* (i.e. not you), you can do that via the automation script "autorequest". But otherwise anyone could send a Request appearing to come from anyone, which would be Really Bad. Your CEO could apparently have sent a request for intimate pictures to someone. I don't think any of us want to allow people to trivially simply create that sort of fake request. On 11/09/2020 14:13, Gregg Douglas via ZendTo wrote: > Hi Mark, > > I have tried that, but the "From" Addresses is not a field that can be > changed and thus the Recipient/Sender is always me. > > Thanks > Gregg > > > On Fri, Sep 11, 2020 at 2:57 PM Sangster, Mark via ZendTo > > wrote: > > You could send the request to yourself, to upload it into ZendTo. > > Then in your Outbox look at the blue box information. > > Sending the claim id/passcode URL to others will grant them access. > > So publicise that URL somewhere for them to collect it. > > Cheers > > Mark > > *From:*ZendTo > *On Behalf Of *Gregg Douglas via > ZendTo > *Sent:* 11 September 2020 13:36 > *To:* ZendTo Users > > *Cc:* Gregg Douglas > > *Subject:* [ZendTo] Request of Drop-off for Unknown Recipients > > CAUTION:External email. Ensure this message is from a trusted > source before clicking links/attachments. > > Hi, > > When you follow the process of "Request a Drop-off" it requires a > "To" Address. How would one go about if you don't know who is > going to use the Drop-off > > So, in the example of an open Tender, you don't know who will > respond to the Tender, thus it is not possible?to complete the > "To" field. > > Thanks > > Gregg > > > > The University of Aberdeen is a charity registered in Scotland, No > SC013683. > Tha Oilthigh Obar Dheathain na charthannas cl?raichte ann an Alba, > ?ir. SC013683. > _______________________________________________ > 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 'That is the land of lost content, I see it shining plain, The happy highways where I went, And cannot come again.' - A.E. Houseman www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From klou at themusiclink.net Mon Sep 14 20:56:54 2020 From: klou at themusiclink.net (Kris Lou) Date: Mon, 14 Sep 2020 12:56:54 -0700 Subject: [ZendTo] Troubleshooting Reverse Proxy uploads (cannot drop-off directories) References: Message-ID: All: I have Nginx running as a Reverse Proxy (over SSL, but also terminating a different FQDN SSL) in front of default Apache serving Zendto. I was running into "Note that you cannot drop-off directories, only files." I was able to solve this by setting "client_max_body_size 50M;" in my reverse proxy (to match my uploadChunkSize) configs -- otherwise nginx defaults to 1M uploads. Anyways, the issue is "fixed" for 99% of my use case, but when testing internally - via internal FQDN served directly to Apache/Zendto, I still run into the same error on all uploads. Out of curiosity, any ideas why this might be? My 'serverRoot' points to the external FQDN on the reverse proxy. Thanks, Kris Kris Lou klou at themusiclink.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Tue Sep 15 12:22:52 2020 From: Jules at Zend.To (Jules) Date: Tue, 15 Sep 2020 12:22:52 +0100 Subject: [ZendTo] Troubleshooting Reverse Proxy uploads (cannot drop-off directories) In-Reply-To: References: Message-ID: Kris, This sounds like you have 2 FQDNs for the same website. One way of solving that one is split-horizon DNS. So your internal users see the serverRoot resolve to the directly-connected internal IP address, and external users get the IP of the reverse proxy. And also ask yourself if there is any good reason you aren't just sending internal users through the reverse proxy as well. Also, in your reverse proxy, I would make the client_max_body_size a bit bigger than the limit you've set as the uploadChunkSize in ZendTo. Else you're might get weird things happening due to the proxy rejecting upload blocks that you thought it would allow through to ZendTo. Cheers, Jules. On 14/09/2020 20:56, Kris Lou via ZendTo wrote: > All: > > I have Nginx running as a Reverse Proxy (over SSL, but also > terminating a different FQDN SSL) in front of default Apache serving > Zendto.? I was running into "Note that you cannot drop-off > directories, only files." > > I was able to solve this by setting "client_max_body_size 50M;" in my > reverse proxy (to match my uploadChunkSize) configs -- otherwise nginx > defaults to 1M uploads. > > Anyways, the issue is "fixed" for 99% of my use case, but when testing > internally - via internal FQDN served directly to Apache/Zendto, I > still run into the same error on all uploads.? Out of curiosity, any > ideas why this might be? > > My 'serverRoot' points to the external FQDN on the reverse proxy. > > Thanks, > Kris > > Kris Lou > klou at themusiclink.net > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'There is one thing stronger than all the armies in the world; and that is an idea whose time has come.' www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From klou at themusiclink.net Tue Sep 15 16:44:40 2020 From: klou at themusiclink.net (Kris Lou) Date: Tue, 15 Sep 2020 08:44:40 -0700 Subject: [ZendTo] Troubleshooting Reverse Proxy uploads (cannot drop-off directories) In-Reply-To: References: Message-ID: > > > > This sounds like you have 2 FQDNs for the same website. > > One way of solving that one is split-horizon DNS. So your internal users > see the serverRoot resolve to the directly-connected internal IP address, > and external users get the IP of the reverse proxy. And also ask yourself > if there is any good reason you aren't just sending internal users through > the reverse proxy as well. > > That's right -- I do. I moved Zendto from my DMZ into my internal network (as it connects to AD) and set up a reverse proxy. Ideally, I'm going to send everybody to the new proxied FQDN, but was just wondering why it would still fail to upload when accessed directly, under the old FQDN. > Also, in your reverse proxy, I would make the client_max_body_size a bit > bigger than the limit you've set as the uploadChunkSize in ZendTo. Else > you're might get weird things happening due to the proxy rejecting upload > blocks that you thought it would allow through to ZendTo > This is good to know. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Tue Sep 15 17:12:43 2020 From: Jules at Zend.To (Jules) Date: Tue, 15 Sep 2020 17:12:43 +0100 Subject: [ZendTo] Troubleshooting Reverse Proxy uploads (cannot drop-off directories) In-Reply-To: References: Message-ID: <9ae9b512-aee2-e558-b056-63647cb32c03@Zend.To> On 15/09/2020 16:44, Kris Lou wrote: > > > > This sounds like you have 2 FQDNs for the same website. > > One way of solving that one is split-horizon DNS. So your internal > users see the serverRoot resolve to the directly-connected > internal IP address, and external users get the IP of the reverse > proxy. And also ask yourself if there is any good reason you > aren't just sending internal users through the reverse proxy as well. > > > That's right -- I do.? I moved Zendto from my DMZ into my internal > network (as it connects to AD) and set up a reverse proxy.? Ideally, > I'm going to send everybody to the new proxied FQDN, but was just > wondering why it would still fail to upload when accessed directly, > under the old FQDN. The short answer is that I don't know why it would fail in that situation. But I've never tried it, and never envisioned the service having 2 FQDNs simultaneously, so it doesn't suprise me at all if that doesn't work. ;-) > Also, in your reverse proxy, I would make the client_max_body_size > a bit bigger than the limit you've set as the uploadChunkSize in > ZendTo. Else you're might get weird things happening due to the > proxy rejecting upload blocks that you thought it would allow > through to ZendTo > > > This is good to know.? Thanks. Always good to allow a little leeway to account for the unexpected (HTTP headers perhaps?). 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 liam.gretton at leicester.ac.uk Thu Sep 17 08:26:26 2020 From: liam.gretton at leicester.ac.uk (Gretton, Liam) Date: Thu, 17 Sep 2020 07:26:26 +0000 Subject: [ZendTo] 'Your Organization' field too long for database References: Message-ID: Hi, When someone requests to drop-off a file, one of the fields to complete is 'Your organization'. If the user enters more than 32 characters here (which is not disallowed), then the form fails. The zendto log reports: Error: Failed to add 2a753247dd272bb39c4547da5b44550f to authtable for user at example.com. Error was Data too long for column 'Organization' at row 1 The column in the DB is only 32 characters, but the code is not truncating the data from the form before trying to push it in. I'm currently running 6.03-5, though a check of the release notes of the newer versions doesn't mention a fix for this yet. This has hit us with some collaborators whose organisations really do have long names such as ' Swiss Tropical and Public Health Institute' so my preference would be for the db field to be longer, and to have the code truncate anything that doesn't fit. If I can find time today I'll have a look through the code and try to submit a patch. Thanks, Liam Liam Gretton Systems Specialist IT Services, University of Leicester, University Road, Leicester, LE1 7RH, UK t: +44 (0)116 252 2254 e: liam.gretton at leicester.ac.uk w: www.le.ac.uk [cid:image001.gif at 01D68CCC.2BEA22F0] Follow us on Twitter or visit our Facebook page -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 3340 bytes Desc: image001.gif URL: From jules at zend.to Thu Sep 17 09:55:37 2020 From: jules at zend.to (jules at zend.to) Date: Thu, 17 Sep 2020 09:55:37 +0100 Subject: [ZendTo] 'Your Organization' field too long for database In-Reply-To: References: Message-ID: <8620166d-a208-686a-f129-9085a3ab2541@Zend.To> Liam, Thank you for spotting that! I will work out a fix (and an automatic way of quietly fixing the DB schema to extend this field) and put it in the next release. BTW I assume you're using a MySQL DB back-end, yes? Cheers, Jules. On 17/09/2020 08:26, Gretton, Liam via ZendTo wrote: > > Hi, > > When someone requests to drop-off a file, one of the fields to > complete is 'Your organization'. If the user enters more than 32 > characters here (which is not disallowed), then the form fails. The > zendto log reports: > > Error: Failed to add 2a753247dd272bb39c4547da5b44550f to authtable for > user at example.com. Error was Data too long for column 'Organization' at > row 1 > > The column in the DB is only 32 characters, but the code is not > truncating the data from the form before trying to push it in. > > I'm currently running 6.03-5, though a check of the release notes of > the newer versions doesn't mention a fix for this yet. > > This has hit us with some collaborators whose organisations really do > have long names such as ' Swiss Tropical and Public Health Institute' > so my preference would be for the db field to be longer, and to have > the code truncate anything that doesn't fit. If I can find time today > I'll have a look through the code and try to submit a patch. > > Thanks, > > Liam > > *Liam Gretton > Systems Specialist*** > > ** > > IT Services, > University of Leicester, University Road, Leicester, LE1 7RH, UK > > *t:*+44 (0)116 252 2254 > *e:*liam.gretton at leicester.ac.uk > *w:*www.le.ac.uk _ > _ > Follow us on Twitter or visit our > Facebook page > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'All the art of living lies in a fine mingling of letting go, and holding on.' - Henry Ellis www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 3340 bytes Desc: not available URL: From liam.gretton at leicester.ac.uk Thu Sep 17 10:20:52 2020 From: liam.gretton at leicester.ac.uk (Gretton, Liam) Date: Thu, 17 Sep 2020 09:20:52 +0000 Subject: [ZendTo] 'Your Organization' field too long for database In-Reply-To: References: <8620166d-a208-686a-f129-9085a3ab2541@Zend.To> Message-ID: Hi Jules, Yep, I'm using MySQL (well, MariaDB). Regards, Liam Liam Gretton Systems Specialist IT Services, University of Leicester, University Road, Leicester, LE1 7RH, UK t: +44 (0)116 252 2254 e: liam.gretton at leicester.ac.uk w: www.le.ac.uk [cid:image001.gif at 01D68CDC.37AA4DD0] Follow us on Twitter or visit our Facebook page From: jules at zend.to Sent: 17 September 2020 09:56 To: ZendTo Users Cc: Gretton, Liam Subject: Re: [ZendTo] 'Your Organization' field too long for database Liam, Thank you for spotting that! I will work out a fix (and an automatic way of quietly fixing the DB schema to extend this field) and put it in the next release. BTW I assume you're using a MySQL DB back-end, yes? Cheers, Jules. On 17/09/2020 08:26, Gretton, Liam via ZendTo wrote: Hi, When someone requests to drop-off a file, one of the fields to complete is 'Your organization'. If the user enters more than 32 characters here (which is not disallowed), then the form fails. The zendto log reports: Error: Failed to add 2a753247dd272bb39c4547da5b44550f to authtable for user at example.com. Error was Data too long for column 'Organization' at row 1 The column in the DB is only 32 characters, but the code is not truncating the data from the form before trying to push it in. I'm currently running 6.03-5, though a check of the release notes of the newer versions doesn't mention a fix for this yet. This has hit us with some collaborators whose organisations really do have long names such as ' Swiss Tropical and Public Health Institute' so my preference would be for the db field to be longer, and to have the code truncate anything that doesn't fit. If I can find time today I'll have a look through the code and try to submit a patch. Thanks, Liam Liam Gretton Systems Specialist IT Services, University of Leicester, University Road, Leicester, LE1 7RH, UK t: +44 (0)116 252 2254 e: liam.gretton at leicester.ac.uk w: www.le.ac.uk [cid:image001.gif at 01D68CDC.37AA4DD0] Follow us on Twitter or visit our Facebook page _______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'All the art of living lies in a fine mingling of letting go, and holding on.' - Henry Ellis www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 3340 bytes Desc: image001.gif URL: From Jules at Zend.To Thu Sep 17 10:30:02 2020 From: Jules at Zend.To (Jules) Date: Thu, 17 Sep 2020 10:30:02 +0100 Subject: [ZendTo] 'Your Organization' field too long for database In-Reply-To: References: <8620166d-a208-686a-f129-9085a3ab2541@Zend.To> Message-ID: <55990b32-0132-5914-a277-d910acd39fbf@Zend.To> Thought so. The reason this bug hasn't been spotted before is that SQLite doesn't actually take any notice of field lengths at all, neither in the column definition nor when used. Cheers, Jules. On 17/09/2020 10:20, Gretton, Liam wrote: > > Hi Jules, > > Yep, I'm using MySQL (well, MariaDB). > > Regards, > > > Liam > > *Liam Gretton > Systems Specialist*** > > ** > > IT Services, > University of Leicester, University Road, Leicester, LE1 7RH, UK > > *t:*+44 (0)116 252 2254 > *e:*liam.gretton at leicester.ac.uk > *w:*www.le.ac.uk _ > _ > Follow us on Twitter or visit our > Facebook page > > *From:*jules at zend.to > *Sent:* 17 September 2020 09:56 > *To:* ZendTo Users > *Cc:* Gretton, Liam > *Subject:* Re: [ZendTo] 'Your Organization' field too long for database > > Liam, > > Thank you for spotting that! > > I will work out a fix (and an automatic way of quietly fixing the DB > schema to extend this field) and put it in the next release. > > BTW I assume you're using a MySQL DB back-end, yes? > > Cheers, > Jules. > > On 17/09/2020 08:26, Gretton, Liam via ZendTo wrote: > > Hi, > > When someone requests to drop-off a file, one of the fields to > complete is 'Your organization'. If the user enters more than 32 > characters here (which is not disallowed), then the form fails. > The zendto log reports: > > Error: Failed to add 2a753247dd272bb39c4547da5b44550f to authtable > for user at example.com . Error was Data too > long for column 'Organization' at row 1 > > The column in the DB is only 32 characters, but the code is not > truncating the data from the form before trying to push it in. > > I'm currently running 6.03-5, though a check of the release notes > of the newer versions doesn't mention a fix for this yet. > > This has hit us with some collaborators whose organisations really > do have long names such as ' Swiss Tropical and Public Health > Institute' so my preference would be for the db field to be > longer, and to have the code truncate anything that doesn't fit. > If I can find time today I'll have a look through the code and try > to submit a patch. > > Thanks, > > Liam > > *Liam Gretton > Systems Specialist* > > ** > > IT Services, > University of Leicester, University Road, Leicester, LE1 7RH, UK > > *t:* +44 (0)116 252 2254 > *e:* liam.gretton at leicester.ac.uk > > *w:* www.le.ac.uk > _ > _ > Follow us on Twitter > > or visit our Facebook > > page > > > > _______________________________________________ > > ZendTo mailing list > > ZendTo at zend.to > > http://jul.es/mailman/listinfo/zendto > > > > Jules > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > 'All the art of living lies in a fine mingling of letting go, > and holding on.' - Henry Ellis > www.Zend.To > Twitter: @JulesFM Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Ensanguining the skies How heavily it dies Into the west away; Past touch and sight and sound Not further to be found, How hopeless under ground Falls the remorseful day.' - A.E.Houseman www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 3340 bytes Desc: not available URL: From liam.gretton at leicester.ac.uk Thu Sep 17 10:45:56 2020 From: liam.gretton at leicester.ac.uk (Gretton, Liam) Date: Thu, 17 Sep 2020 09:45:56 +0000 Subject: [ZendTo] 'Your Organization' field too long for database In-Reply-To: References: <8620166d-a208-686a-f129-9085a3ab2541@Zend.To> Message-ID: As a quick fix on our site, I've edited templates/verify.tpl and added maxlength="32" to the senderOrganization input field definition. Liam Gretton Systems Specialist IT Services, University of Leicester, University Road, Leicester, LE1 7RH, UK t: +44 (0)116 252 2254 e: liam.gretton at leicester.ac.uk w: www.le.ac.uk [cid:image001.gif at 01D68CDF.B87E5110] Follow us on Twitter or visit our Facebook page From: jules at zend.to Sent: 17 September 2020 09:56 To: ZendTo Users Cc: Gretton, Liam Subject: Re: [ZendTo] 'Your Organization' field too long for database Liam, Thank you for spotting that! I will work out a fix (and an automatic way of quietly fixing the DB schema to extend this field) and put it in the next release. BTW I assume you're using a MySQL DB back-end, yes? Cheers, Jules. On 17/09/2020 08:26, Gretton, Liam via ZendTo wrote: Hi, When someone requests to drop-off a file, one of the fields to complete is 'Your organization'. If the user enters more than 32 characters here (which is not disallowed), then the form fails. The zendto log reports: Error: Failed to add 2a753247dd272bb39c4547da5b44550f to authtable for user at example.com. Error was Data too long for column 'Organization' at row 1 The column in the DB is only 32 characters, but the code is not truncating the data from the form before trying to push it in. I'm currently running 6.03-5, though a check of the release notes of the newer versions doesn't mention a fix for this yet. This has hit us with some collaborators whose organisations really do have long names such as ' Swiss Tropical and Public Health Institute' so my preference would be for the db field to be longer, and to have the code truncate anything that doesn't fit. If I can find time today I'll have a look through the code and try to submit a patch. Thanks, Liam Liam Gretton Systems Specialist IT Services, University of Leicester, University Road, Leicester, LE1 7RH, UK t: +44 (0)116 252 2254 e: liam.gretton at leicester.ac.uk w: www.le.ac.uk [cid:image001.gif at 01D68CDF.B87E5110] Follow us on Twitter or visit our Facebook page _______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'All the art of living lies in a fine mingling of letting go, and holding on.' - Henry Ellis www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 3340 bytes Desc: image001.gif URL: From orion at nwra.com Thu Sep 17 18:37:36 2020 From: orion at nwra.com (Orion Poplawski) Date: Thu, 17 Sep 2020 11:37:36 -0600 Subject: [ZendTo] RFE - split package References: Message-ID: Hello - I've started installing zendto on a couple machines just for the /opt/zendto/bin/autodropoff script. Unfortunately doing this via rpm (which I'd like to do for updates and the like) brings in a lot of unneeded dependencies. Would you consider creating a zendto-tools (utils/bin/whatever) sub-package to contain these scripts? Thanks! (and thanks for the great software!) Orion -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 https://www.nwra.com/ From jules at zend.to Mon Sep 21 09:40:30 2020 From: jules at zend.to (jules at zend.to) Date: Mon, 21 Sep 2020 09:40:30 +0100 Subject: [ZendTo] RFE - split package In-Reply-To: References: Message-ID: <7d8fd32d-ace9-d1b0-d773-214280948d61@Zend.To> Orion, For this situation, I would advise you download the tarball (.tgz) distribution and just unpack that. Cheers, Jules. On 17/09/2020 18:37, Orion Poplawski via ZendTo wrote: > Hello - > > I've started installing zendto on a couple machines just for the > /opt/zendto/bin/autodropoff script. Unfortunately doing this via rpm (which > I'd like to do for updates and the like) brings in a lot of unneeded > dependencies. Would you consider creating a zendto-tools (utils/bin/whatever) > sub-package to contain these scripts? > > Thanks! (and thanks for the great software!) > > Orion > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'All mushrooms are edible, but some are edible only once.' - Lithuanian proverb about life www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.bozzelli at gci.it Thu Sep 24 13:31:55 2020 From: davide.bozzelli at gci.it (Davide Bozzelli) Date: Thu, 24 Sep 2020 14:31:55 +0200 Subject: [ZendTo] Automation References: <18eed29e-1c20-459e-8254-7b86e60d4c51@gci.it> Message-ID: Hi I'm playing aroung the automation script. Version is "zendto-6.05-4.noarch" centos 7. When i try to run something like: /opt/zendto/bin/autorequest --expirydatetime '2030-10-10 10:10:00' --username 'myuser' --password 'mypass' --sendername 'myname' --senderemail 'me at me.it' --senderorg 'me spa' --subject 'Request for files' --note 'Please send me the log files we discussed' --recipientname 'me ' --recipientemail 'me at gmail.com' https://my.zend.to/ I receive: {"status":"error","error":"request error: The end time you set has already passed. Even if I don't specify the expire time Thx *Davide Bozzelli* IT Architect davide.bozzelli at gci.it +39 02 90092830 www.gci.it General Computer Italia S.p.A. Via Milano 11 (S.P. 105) - 20084 Lacchiarella (MI) -- CONFIDENTIALITY NOTICE Questo messaggio e' destinato alle sole persone indicate e puo' contenereinformazioni riservate. Se ricevuto per errore, si prega di avvisare immediatamente il mittente ecancellare l'originale. Ogni altro uso del messaggio e' vietato! **** This message is for the designated recipient(s) only and may containprivileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete theoriginal message. Any other use of the email by you is prohibited! -- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ghbbggdlddcgnlhj.jpg Type: image/jpeg Size: 6436 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: napdnidbfhfohkad.jpg Type: image/jpeg Size: 3534 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mnfocponpfgkpiig.jpg Type: image/jpeg Size: 1540 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ejjhbglfeemblmfl.jpg Type: image/jpeg Size: 1562 bytes Desc: not available URL: From Jules at Zend.To Thu Sep 24 15:15:32 2020 From: Jules at Zend.To (Jules) Date: Thu, 24 Sep 2020 15:15:32 +0100 Subject: [ZendTo] Automation In-Reply-To: References: <18eed29e-1c20-459e-8254-7b86e60d4c51@gci.it> Message-ID: Davide, This is because, after I re-vamped the "request" page, I forgot to do the relevant bits for the "autorequest" script. I'll get this fixed for you and put out a new beta as soon as I can. It shouldn't take me long. Sorry about that! Cheers, Jules. On 24/09/2020 13:31, Davide Bozzelli via ZendTo wrote: > Hi > > I'm playing aroung the automation script. > Version is "zendto-6.05-4.noarch" centos 7. > > When i try to run something like: > > /opt/zendto/bin/autorequest --expirydatetime '2030-10-10 10:10:00' > --username 'myuser' --password 'mypass' --sendername 'myname' > --senderemail 'me at me.it' --senderorg 'me spa' --subject 'Request for > files' --note 'Please send me the log files we discussed' > --recipientname 'me ' --recipientemail 'me at gmail.com' https://my.zend.to/ > > I receive: {"status":"error","error":"request error: The end time you > set has already passed. > > Even if I don't specify the expire time > > Thx > > > > > *Davide Bozzelli* > IT Architect > davide.bozzelli at gci.it > > +39 02 90092830 > > www.gci.it General Computer Italia S.p.A. Via Milano 11 (S.P. 105) > - 20084 Lacchiarella (MI) > > > > > > > -- > CONFIDENTIALITY NOTICE > > Questo messaggio e' destinato alle sole persone indicate e puo' > contenere informazioni riservate. > Se ricevuto per errore, si prega di avvisare immediatamente il > mittente e cancellare l'originale. > Ogni altro uso del messaggio e' vietato! > **** > This message is for the designated recipient(s) only and may contain > privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender immediately > and delete the original message. > Any other use of the email by you is prohibited! > -- > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Do not go gentle into that good night, Old age should burn and rave at close of day; Rage, rage against the dying of the light. Though wise men at their end know dark is right, Because their words had forked no lightning they Do not go gentle into that good night. Good men, the last wave by, crying how bright Their frail deeds might have danced in a green bay, Rage, rage against the dying of the light. Wild men who caught and sang the sun in flight, And learn, too late, they grieved it on its way, Do not go gentle into that good night. Grave men, near death, who see with blinding sight Blind eyes could blaze like meteors and be gay, Rage, rage against the dying of the light. And you, my father, there on the sad height, Curse, bless, me now with your fierce tears, I pray. Do not go gentle into that good night. Rage, rage against the dying of the light.' - Dylan Thomas www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ghbbggdlddcgnlhj.jpg Type: image/jpeg Size: 6436 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: napdnidbfhfohkad.jpg Type: image/jpeg Size: 3534 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mnfocponpfgkpiig.jpg Type: image/jpeg Size: 1540 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ejjhbglfeemblmfl.jpg Type: image/jpeg Size: 1562 bytes Desc: not available URL: From lievendp at gmail.com Mon Sep 28 14:21:58 2020 From: lievendp at gmail.com (Lieven De Puysseleir) Date: Mon, 28 Sep 2020 15:21:58 +0200 Subject: [ZendTo] upgrade missing sqlite3 schema References: Message-ID: Dear, On one system running zendto 5.17-6 I fail to have the sqlite3 schema updating while upgrading to 6.05-4. to update I use the zendto repository on sles 15 sp2 and then run the script that handles config file changes. after the update, it's impossible to make dropoffs "unable to add a dropoff record to the database". I notice that there are 2 fields missing from the dropoff table: "lifeseconds and subject" So I deleted the file zendto.sqlite, restarted apache2 and zendto created a new one with the correct schema. Next, I did a dump of the old db to file, found the INSERT lines for the dropoff table and added a value for the lifeseconds which (I think) corresponds to the max 14days we put as preference when it's not overridden in the new version dropoff form. Also added a value empty string '' for the subject field. Lastly I did a cat of the (edited) dump file, piped it to sqlite3 into the newly created empty db file. This seemed to work fine, I could see the dropoffs in the interface but couldn't see the files when I opened a dropoff. I verified that for each dropoff line in the database, the claimid corresponded to the name of the folder in /var/zendto where the dropoff directory/files resided and it matched. The logs don't say anything about this. Apache logs indicate that pickup.php is used but again, the php code with the nssdrop class stuff is something I can't seem to understand how it works. (or if it even matters in this case) This worked fine on another system upgrading 5.17-6 to 6.05-4. The update was done with zypper, the upgrade script run and that was it, everything looked fine in the dropoffs. Any ideas what part of the install script I should run to simulate the schema upgrade? I've been looking into cleanup.php but I'm not much of a programmer and can't figure how it actually works by calling some class or something. (I'm probably wrong here) Thanks for your help. -- Lieven -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Mon Sep 28 17:12:08 2020 From: Jules at Zend.To (Jules) Date: Mon, 28 Sep 2020 17:12:08 +0100 Subject: [ZendTo] upgrade missing sqlite3 schema In-Reply-To: References: Message-ID: <545610f8-3c1e-02c7-42d8-1de570b1f60f@Zend.To> To manually run the DB schema update, run ??? /opt/zendto/sbin/cleanup.php as root. The output of that should tell you what it's doing. Cheers, Jules. On 28/09/2020 14:21, Lieven De Puysseleir via ZendTo wrote: > Dear, > On one system running zendto 5.17-6 I fail to have the sqlite3 schema > updating while upgrading to 6.05-4. > to update I use the zendto repository on sles 15 sp2 and then run the > script that handles config file changes. > > after the update, it's impossible to make dropoffs "unable to add a > dropoff record to the database". I notice that there are 2 fields > missing from the dropoff table: "lifeseconds and subject" > > So I deleted the file zendto.sqlite, restarted apache2 and zendto > created a new one with the correct schema. > Next, I did a dump of the old db to file, found the INSERT lines for > the dropoff table and added a value for the lifeseconds which (I > think) corresponds to the max 14days we put as preference when it's > not overridden in the new version dropoff form. Also added a value > empty string '' for the subject field. > Lastly I did a cat of the (edited) dump file, piped it to sqlite3 into > the newly created empty db file. > This seemed to work fine, I could see the dropoffs in the interface > but couldn't see the files when I opened a dropoff. > I verified that for each dropoff line in the database, the claimid > corresponded to the name of the folder in /var/zendto where the > dropoff directory/files resided and it matched. > The logs don't say anything about this. > Apache logs indicate that pickup.php is used but again, the php code > with the nssdrop class stuff is something I can't seem to understand > how it works. (or if it even matters in this case) > > This worked fine on another system upgrading 5.17-6 to 6.05-4. The > update was done with zypper, the upgrade script run and that was it, > everything looked fine in the dropoffs. > > Any ideas what part of the install script I should run to simulate the > schema upgrade? I've been looking into cleanup.php but I'm not much of > a programmer and can't figure how it actually works by calling some > class or something. (I'm probably wrong here) > > Thanks for your help. > > -- > Lieven > > _______________________________________________ > 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: East Forties: Cyclonic becoming northerly 4 or 5. Slight or moderate. Rain, fog patches. Moderate or very poor. www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From lievendp at gmail.com Tue Sep 29 08:09:34 2020 From: lievendp at gmail.com (Lieven De Puysseleir) Date: Tue, 29 Sep 2020 09:09:34 +0200 Subject: [ZendTo] upgrade missing sqlite3 schema In-Reply-To: References: <545610f8-3c1e-02c7-42d8-1de570b1f60f@Zend.To> Message-ID: Hello Jules, Indeed I did find out that the cronjob did just that and I executed it manually. What strikes me a bit odd is the way the schema is printed after the change. On one machine, I got this schema after the cleanup run: sqlite> .schema dropoff CREATE TABLE dropoff ( claimID character varying(16) not null, claimPasscode character varying(16), authorizedUser character varying(16), senderName character varying(32) not null, senderOrganization character varying(32), senderEmail text not null, senderIP character varying(255) not null, confirmDelivery boolean default FALSE, created timestamp with time zone not null, note text , lifeseconds int NOT NULL DEFAULT 0, subject character varying(500) DEFAULT NULL); CREATE INDEX dropoff_claimID_index ON dropoff(claimID); => there seems to be a missing newline and another newline is before the ', lifeseconds". That doesn't seem to hamper with the functionality of zendto in this case => I had another system following the same update version path which didn't have the strange output of the dropoff schema BUT in that case, there was the previously posted error when making a dropoff and that's the system where I ran the manually changed export-import of the sqlite db. This is the output from the cleanup script, nothing is mentioned on the change of the schema however it could be the case that the cronjob of cleanup got there before I ran it manually: #> /usr/bin/php /opt/zendto/sbin/cleanup.php /opt/zendto/config/preferences.php Cleanup of ZendTo for preference file: /opt/zendto/config/preferences.php Updating database schema Gathering expired dropoffs - Removing [] <@> NSSDropbox Warn recipients about dropoffs close to expiry. Purging orphaned dropoffs: No orphans found. Purging old sender verification data: Purging old request data: On Mon, Sep 28, 2020 at 6:12 PM Jules wrote: > To manually run the DB schema update, run > /opt/zendto/sbin/cleanup.php > as root. The output of that should tell you what it's doing. > > Cheers, > Jules. > > On 28/09/2020 14:21, Lieven De Puysseleir via ZendTo wrote: > > Dear, > On one system running zendto 5.17-6 I fail to have the sqlite3 schema > updating while upgrading to 6.05-4. > to update I use the zendto repository on sles 15 sp2 and then run the > script that handles config file changes. > > after the update, it's impossible to make dropoffs "unable to add a > dropoff record to the database". I notice that there are 2 fields missing > from the dropoff table: "lifeseconds and subject" > > So I deleted the file zendto.sqlite, restarted apache2 and zendto created > a new one with the correct schema. > Next, I did a dump of the old db to file, found the INSERT lines for the > dropoff table and added a value for the lifeseconds which (I think) > corresponds to the max 14days we put as preference when it's not overridden > in the new version dropoff form. Also added a value empty string '' for the > subject field. > Lastly I did a cat of the (edited) dump file, piped it to sqlite3 into the > newly created empty db file. > This seemed to work fine, I could see the dropoffs in the interface but > couldn't see the files when I opened a dropoff. > I verified that for each dropoff line in the database, the claimid > corresponded to the name of the folder in /var/zendto where the dropoff > directory/files resided and it matched. > The logs don't say anything about this. > Apache logs indicate that pickup.php is used but again, the php code with > the nssdrop class stuff is something I can't seem to understand how it > works. (or if it even matters in this case) > > This worked fine on another system upgrading 5.17-6 to 6.05-4. The update > was done with zypper, the upgrade script run and that was it, everything > looked fine in the dropoffs. > > Any ideas what part of the install script I should run to simulate the > schema upgrade? I've been looking into cleanup.php but I'm not much of a > programmer and can't figure how it actually works by calling some class or > something. (I'm probably wrong here) > > Thanks for your help. > > -- > Lieven > > _______________________________________________ > ZendTo mailing listZendTo at zend.tohttp://jul.es/mailman/listinfo/zendto > > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > The current UK shipping forecast: > East Forties: Cyclonic becoming northerly 4 or 5. Slight or moderate. Rain, > fog patches. Moderate or very poor. > www.Zend.To > Twitter: @JulesFM > > -- Lieven De Puysseleir -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Tue Sep 29 11:08:55 2020 From: Jules at Zend.To (Jules) Date: Tue, 29 Sep 2020 11:08:55 +0100 Subject: [ZendTo] upgrade missing sqlite3 schema In-Reply-To: References: <545610f8-3c1e-02c7-42d8-1de570b1f60f@Zend.To> Message-ID: <9a94f944-bee3-a667-dfac-0f031e22cdb3@Zend.To> On 29/09/2020 08:09, Lieven De Puysseleir wrote: > Hello Jules, > Indeed I did find out that the cronjob did just that and I executed it > manually. > What strikes me a bit odd is the way the schema is printed after the > change. On one machine, I got this schema after the cleanup run: > > sqlite> .schema dropoff > CREATE TABLE dropoff ( > claimID character varying(16) not null, > claimPasscode character varying(16), > > authorizedUser character varying(16), > > senderName character varying(32) not null, > senderOrganization character varying(32), > senderEmail text not null, > senderIP character varying(255) not null, > confirmDelivery boolean default FALSE, > created timestamp with time zone not null, > note text > , lifeseconds int NOT NULL DEFAULT 0, subject character varying(500) DEFAULT NULL); > CREATE INDEX dropoff_claimID_index ON dropoff(claimID); > > => there seems to be a missing newline and another newline is before the ', lifeseconds". That doesn't seem to hamper with the functionality of zendto in this case > => I had another system following the same update version path which didn't have the strange output of the dropoff schema BUT in that case, there was the previously posted error when making a dropoff and that's the system where I ran the manually changed export-import of the sqlite db. > I think that output is just a quirk of SQLite. I've often seen it myself too, but it appears to have no effects on the operation of the table. It just appears to put the newline before the comma rather than after. > This is the output from the cleanup script, nothing is mentioned on the change of the schema however it could be the case that the cronjob of cleanup got there before I ran it manually: > > #> /usr/bin/php /opt/zendto/sbin/cleanup.php /opt/zendto/config/preferences.php > > Cleanup of ZendTo for preference file: > /opt/zendto/config/preferences.php > > Updating database schema > Gathering expired dropoffs > - Removing [] <@> > > NSSDropbox Warn recipients about dropoffs close to expiry. > Purging orphaned dropoffs: > No orphans found. > > Purging old sender verification data: > Purging old request data: > > On Mon, Sep 28, 2020 at 6:12 PM Jules > wrote: > > To manually run the DB schema update, run > ??? /opt/zendto/sbin/cleanup.php > as root. The output of that should tell you what it's doing. > > Cheers, > Jules. > > On 28/09/2020 14:21, Lieven De Puysseleir via ZendTo wrote: >> Dear, >> On one system running zendto 5.17-6 I fail to have the sqlite3 >> schema updating while upgrading to 6.05-4. >> to update I use the zendto repository on sles 15 sp2 and then run >> the script that handles config file changes. >> >> after the update, it's impossible to make dropoffs "unable to add >> a dropoff record to the database". I notice that there are 2 >> fields missing from the dropoff table: "lifeseconds and subject" >> >> So I deleted the file zendto.sqlite, restarted apache2 and zendto >> created a new one with the correct schema. >> Next, I did a dump of the old db to file, found the INSERT lines >> for the dropoff table and added a value for the lifeseconds which >> (I think) corresponds to the max 14days we put as preference when >> it's not overridden in the new version dropoff form. Also added a >> value empty string '' for the subject field. >> Lastly I did a cat of the (edited) dump file, piped it to sqlite3 >> into the newly created empty db file. >> This seemed to work fine, I could see the dropoffs in the >> interface but couldn't see the files when I opened a dropoff. >> I verified that for each dropoff line in the database, the >> claimid corresponded to the name of the folder in /var/zendto >> where the dropoff directory/files resided and it matched. >> The logs don't say anything about this. >> Apache logs indicate that pickup.php is used but again, the php >> code with the nssdrop class stuff is something I can't seem to >> understand how it works. (or if it even matters in this case) >> >> This worked fine on another system upgrading 5.17-6 to 6.05-4. >> The update was done with zypper, the upgrade script run and that >> was it, everything looked fine in the dropoffs. >> >> Any ideas what part of the install script I should run to >> simulate the schema upgrade? I've been looking into cleanup.php >> but I'm not much of a programmer and can't figure how it actually >> works by calling some class or something. (I'm probably wrong here) >> >> Thanks for your help. >> >> -- >> Lieven >> >> _______________________________________________ >> 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: > East Forties: Cyclonic becoming northerly 4 or 5. Slight or moderate. Rain, > fog patches. Moderate or very poor. > > www.Zend.To > Twitter: @JulesFM > > > > -- > Lieven De Puysseleir Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'A committee is a group of the unwilling, chosen from the unfit, to do the unnecessary.' - Anon www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Wed Sep 30 16:47:55 2020 From: Jules at Zend.To (Jules) Date: Wed, 30 Sep 2020 16:47:55 +0100 Subject: [ZendTo] Automation In-Reply-To: References: <18eed29e-1c20-459e-8254-7b86e60d4c51@gci.it> Message-ID: Davide, I have just released a new beta release 6.06-1 which should fix all the autorequest problems you were having. You can now also set the --startdatetime. And you can --sendemail too (which by default it doesn't as you probably want to do that in some other software; the link you need to send is in the JSON output). Please can you give it a try and let me know how you get on. Cheers, Jules. On 24/09/2020 13:31, Davide Bozzelli via ZendTo wrote: > Hi > > I'm playing aroung the automation script. > Version is "zendto-6.05-4.noarch" centos 7. > > When i try to run something like: > > /opt/zendto/bin/autorequest --expirydatetime '2030-10-10 10:10:00' > --username 'myuser' --password 'mypass' --sendername 'myname' > --senderemail 'me at me.it' --senderorg 'me spa' --subject 'Request for > files' --note 'Please send me the log files we discussed' > --recipientname 'me ' --recipientemail 'me at gmail.com' https://my.zend.to/ > > I receive: {"status":"error","error":"request error: The end time you > set has already passed. > > Even if I don't specify the expire time > > Thx > > > > > *Davide Bozzelli* > IT Architect > davide.bozzelli at gci.it > > +39 02 90092830 > > www.gci.it General Computer Italia S.p.A. Via Milano 11 (S.P. 105) > - 20084 Lacchiarella (MI) > > > > > > > -- > CONFIDENTIALITY NOTICE > > Questo messaggio e' destinato alle sole persone indicate e puo' > contenere informazioni riservate. > Se ricevuto per errore, si prega di avvisare immediatamente il > mittente e cancellare l'originale. > Ogni altro uso del messaggio e' vietato! > **** > This message is for the designated recipient(s) only and may contain > privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender immediately > and delete the original message. > Any other use of the email by you is prohibited! > -- > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'There is always one moment in childhood when the door opens and lets the future in.' - Graham Greene www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ghbbggdlddcgnlhj.jpg Type: image/jpeg Size: 6436 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: napdnidbfhfohkad.jpg Type: image/jpeg Size: 3534 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mnfocponpfgkpiig.jpg Type: image/jpeg Size: 1540 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ejjhbglfeemblmfl.jpg Type: image/jpeg Size: 1562 bytes Desc: not available URL: From Jules at Zend.To Wed Sep 30 16:51:55 2020 From: Jules at Zend.To (Jules) Date: Wed, 30 Sep 2020 16:51:55 +0100 Subject: [ZendTo] 'Your Organization' field too long for database In-Reply-To: References: <8620166d-a208-686a-f129-9085a3ab2541@Zend.To> Message-ID: <82adddf8-d20a-40a5-cc11-90f828f6094f@Zend.To> Liam, I have just released a new beta for you, 6.06-1. Sorry it's taken quite so long. Something called "term time" seems to be very nearly upon us! Teaching starts Monday, in all its Covid-19-secure features. There are a few daft 1-way systems on campus right now! It should auto-update your DB schema to make all the fields that contain organization names (there are 3 I think) 255 characters long instead of 32. I've also added your suggestion of a "maxlength" attribute, and I've changed the code so that even if somehow you exceed that, the code won't break (but it might well truncate the org name to 255 characters instead). Please can you give it a try and let me know how you get on? I'll be particularly interested to know if the auto-schema-update works correctly or not. Cheers, Jules. On 17/09/2020 10:45, Gretton, Liam via ZendTo wrote: > > As a quick fix on our site, I've edited templates/verify.tpl and added > maxlength="32" to the senderOrganization input field definition. > > *Liam Gretton > Systems Specialist*** > > ** > > IT Services, > University of Leicester, University Road, Leicester, LE1 7RH, UK > > *t:*+44 (0)116 252 2254 > *e:*liam.gretton at leicester.ac.uk > *w:*www.le.ac.uk _ > _ > Follow us on Twitter or visit our > Facebook page > > *From:*jules at zend.to > *Sent:* 17 September 2020 09:56 > *To:* ZendTo Users > *Cc:* Gretton, Liam > *Subject:* Re: [ZendTo] 'Your Organization' field too long for database > > Liam, > > Thank you for spotting that! > > I will work out a fix (and an automatic way of quietly fixing the DB > schema to extend this field) and put it in the next release. > > BTW I assume you're using a MySQL DB back-end, yes? > > Cheers, > Jules. > > On 17/09/2020 08:26, Gretton, Liam via ZendTo wrote: > > Hi, > > When someone requests to drop-off a file, one of the fields to > complete is 'Your organization'. If the user enters more than 32 > characters here (which is not disallowed), then the form fails. > The zendto log reports: > > Error: Failed to add 2a753247dd272bb39c4547da5b44550f to authtable > for user at example.com . Error was Data too > long for column 'Organization' at row 1 > > The column in the DB is only 32 characters, but the code is not > truncating the data from the form before trying to push it in. > > I'm currently running 6.03-5, though a check of the release notes > of the newer versions doesn't mention a fix for this yet. > > This has hit us with some collaborators whose organisations really > do have long names such as ' Swiss Tropical and Public Health > Institute' so my preference would be for the db field to be > longer, and to have the code truncate anything that doesn't fit. > If I can find time today I'll have a look through the code and try > to submit a patch. > > Thanks, > > Liam > > *Liam Gretton > Systems Specialist* > > ** > > IT Services, > University of Leicester, University Road, Leicester, LE1 7RH, UK > > *t:* +44 (0)116 252 2254 > *e:* liam.gretton at leicester.ac.uk > > *w:* www.le.ac.uk > _ > _ > Follow us on Twitter > > or visit our Facebook > > page > > > > _______________________________________________ > > ZendTo mailing list > > ZendTo at zend.to > > http://jul.es/mailman/listinfo/zendto > > > > Jules > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > 'All the art of living lies in a fine mingling of letting go, > and holding on.' - Henry Ellis > www.Zend.To > Twitter: @JulesFM > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'There is always one moment in childhood when the door opens and lets the future in.' - Graham Greene www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 3340 bytes Desc: not available URL: From davide.bozzelli at gci.it Wed Sep 30 17:19:59 2020 From: davide.bozzelli at gci.it (Davide Bozzelli) Date: Wed, 30 Sep 2020 18:19:59 +0200 Subject: [ZendTo] Automation In-Reply-To: References: <18eed29e-1c20-459e-8254-7b86e60d4c51@gci.it> <9f7f9581-487c-a0a4-f256-9517bea7ca42@gci.it> Message-ID: Thx Jules I'm usually use the rpm repo: does the beta lives in it ? Thx *Davide Bozzelli* IT Architect davide.bozzelli at gci.it +39 02 90092830 www.gci.it General Computer Italia S.p.A. Via Milano 11 (S.P. 105) - 20084 Lacchiarella (MI) Il 30/09/20 17:47, Jules ha scritto: > Davide, > > I have just released a new beta release 6.06-1 which should fix all > the autorequest problems you were having. > You can now also set the --startdatetime. > And you can --sendemail too (which by default it doesn't as you > probably want to do that in some other software; the link you need to > send is in the JSON output). > > Please can you give it a try and let me know how you get on. > > Cheers, > Jules. > > On 24/09/2020 13:31, Davide Bozzelli via ZendTo wrote: >> Hi >> >> I'm playing aroung the automation script. >> Version is "zendto-6.05-4.noarch" centos 7. >> >> When i try to run something like: >> >> /opt/zendto/bin/autorequest --expirydatetime '2030-10-10 10:10:00' >> --username 'myuser' --password 'mypass' --sendername 'myname' >> --senderemail 'me at me.it' --senderorg 'me spa' --subject 'Request for >> files' --note 'Please send me the log files we discussed' >> --recipientname 'me ' --recipientemail 'me at gmail.com' https://my.zend.to/ >> >> I receive: {"status":"error","error":"request error: The end time you >> set has already passed. >> >> Even if I don't specify the expire time >> >> Thx >> >> >> >> >> *Davide Bozzelli* >> IT Architect >> davide.bozzelli at gci.it >> >> +39 02 90092830 >> >> www.gci.it General Computer Italia S.p.A. Via Milano 11 (S.P. >> 105) - 20084 Lacchiarella (MI) >> >> >> >> >> >> >> -- >> CONFIDENTIALITY NOTICE >> >> Questo messaggio e' destinato alle sole persone indicate e puo' >> contenere informazioni riservate. >> Se ricevuto per errore, si prega di avvisare immediatamente il >> mittente e cancellare l'originale. >> Ogni altro uso del messaggio e' vietato! >> **** >> This message is for the designated recipient(s) only and may contain >> privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original message. >> Any other use of the email by you is prohibited! >> -- >> >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > 'There is always one moment in childhood when the door opens and > lets the future in.' - Graham Greene > > www.Zend.To > Twitter: @JulesFM -- CONFIDENTIALITY NOTICE Questo messaggio e' destinato alle sole persone indicate e puo' contenereinformazioni riservate. Se ricevuto per errore, si prega di avvisare immediatamente il mittente ecancellare l'originale. Ogni altro uso del messaggio e' vietato! **** This message is for the designated recipient(s) only and may containprivileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete theoriginal message. Any other use of the email by you is prohibited! -- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pnahmlinmbbfdnif.jpg Type: image/jpeg Size: 6436 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: aamnpmkjhnannehb.jpg Type: image/jpeg Size: 3534 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ececegaanpagnmgh.jpg Type: image/jpeg Size: 1540 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mdbhjpdmdmcklimm.jpg Type: image/jpeg Size: 1562 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ghbbggdlddcgnlhj.jpg Type: image/jpeg Size: 6436 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: napdnidbfhfohkad.jpg Type: image/jpeg Size: 3534 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mnfocponpfgkpiig.jpg Type: image/jpeg Size: 1540 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ejjhbglfeemblmfl.jpg Type: image/jpeg Size: 1562 bytes Desc: not available URL: