> On December 22, 2017 at 8:20 AM Mark Moseley <moseleymark at gmail.com> wrote: > > > On Thu, Dec 21, 2017 at 9:51 PM, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: > > > > > > On December 22, 2017 at 6:43 AM Mark Moseley <moseleymark at gmail.com> > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > 2) Is there an appropriate way to return data with spaces in it (or > > > > presumably other non-alphanum chars. My quota name had a space in it, > > > > which > > > > somehow got interpreted as 'yes' , i.e.: > > > > > > > > imap: Error: Failed to initialize quota: Invalid quota root quota: > > Unknown > > > > quota backend: yes > > > > > > > > I simply changed the space to an underscore as a workaround, but I'm > > > > curious if there's a better way. I tried various quoting without > > success. > > > > Didn't try escaping yet. > > > > > > > > > > > > 2) Instead of string, return a key value table. you can have spaces in > > > > values. > > > > > > > > > > > > > > > Does this work for auth_passdb_lookup too, or just auth_userdb_lookup? > > I've > > > been returning a table with auth_userdb_lookup just fine. But when I try > > > using it with passdb (and despite being very very sure that a 'password' > > > key exists in the table I'm returning from auth_passdb_lookup() -- I'm > > > logging it one line above the return), the passdb auth fails with this > > log > > > entry: > > > > > > Dec 21 23:29:22 auth-worker(7779): Info: > > > lua(test1 at test.com,10.20.103.32,<dSvLQuZg+uIKFGcg>): > > > No password returned (and no nopassword) > > > > > > I guess it's not seeing the password key in the table I'm returning. If I > > > return a concat'd string ("password=... user=...") from > > > auth_passdb_lookup(), it works just fine. > > > > > > I was also curious if there's a way to pass info between > > auth_userdb_lookup > > > and auth_passdb_lookup. I was trying to use a table with > > > auth_passdb_lookup() so I could take advantage of prefetch and thought > > that > > > if auth_passdb_lookup didn't take a table, I could stash data away and > > then > > > un-stash it in auth_userdb_lookup > > > > > > Thanks! > > > > > > > > > > Yeah, this is a bug we have fixed =) > > > > https://github.com/dovecot/core/commit/c86575ac9776d0995355d03719c82e > > 7ceac802e6#diff-83374eeaee91d90e848390ba3c7b264a > > > > > > I'm on rc1, so I appear to already have that git commit (as part of rc1). > > # /usr/sbin/dovecot --version > 2.3.0.rc1 (12aba5948) > > For testing this, I tried replacing my passdb lookup with this: > > function auth_passdb_lookup(req) > passdb_table = {} > passdb_table[ 'password' ] = 'test' > passdb_table[ 'user' ] = 'test1 at test.com' > > return dovecot.auth.PASSDB_RESULT_OK, passdb_table > end > > and still get: > > Dec 22 01:17:17 auth-worker(9711): Info: > lua(test1 at test.com,10.20.103.32,<f2O5xOdgFoYKFGcg>): > No password returned (and no nopassword) > > Replacing that return statement with this: > > return dovecot.auth.PASSDB_RESULT_OK, 'password=test user=test1 at test.com' > > authenticates successfully.Fixed in https://github.com/dovecot/core/commit/e5fb6b3b7d4e79475b451823ea6c0a02955ba06b Aki
On Fri, Dec 22, 2017 at 5:18 AM, <aki.tuomi at dovecot.fi> wrote:> > > On December 22, 2017 at 8:20 AM Mark Moseley <moseleymark at gmail.com> > wrote: > > > > > > On Thu, Dec 21, 2017 at 9:51 PM, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: > > > > > > > > > On December 22, 2017 at 6:43 AM Mark Moseley <moseleymark at gmail.com> > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) Is there an appropriate way to return data with spaces in it (or > > > > > presumably other non-alphanum chars. My quota name had a space in > it, > > > > > which > > > > > somehow got interpreted as 'yes' , i.e.: > > > > > > > > > > imap: Error: Failed to initialize quota: Invalid quota root quota: > > > Unknown > > > > > quota backend: yes > > > > > > > > > > I simply changed the space to an underscore as a workaround, but > I'm > > > > > curious if there's a better way. I tried various quoting without > > > success. > > > > > Didn't try escaping yet. > > > > > > > > > > > > > > > 2) Instead of string, return a key value table. you can have > spaces in > > > > > values. > > > > > > > > > > > > > > > > > > > Does this work for auth_passdb_lookup too, or just > auth_userdb_lookup? > > > I've > > > > been returning a table with auth_userdb_lookup just fine. But when I > try > > > > using it with passdb (and despite being very very sure that a > 'password' > > > > key exists in the table I'm returning from auth_passdb_lookup() -- > I'm > > > > logging it one line above the return), the passdb auth fails with > this > > > log > > > > entry: > > > > > > > > Dec 21 23:29:22 auth-worker(7779): Info: > > > > lua(test1 at test.com,10.20.103.32,<dSvLQuZg+uIKFGcg>): > > > > No password returned (and no nopassword) > > > > > > > > I guess it's not seeing the password key in the table I'm returning. > If I > > > > return a concat'd string ("password=... user=...") from > > > > auth_passdb_lookup(), it works just fine. > > > > > > > > I was also curious if there's a way to pass info between > > > auth_userdb_lookup > > > > and auth_passdb_lookup. I was trying to use a table with > > > > auth_passdb_lookup() so I could take advantage of prefetch and > thought > > > that > > > > if auth_passdb_lookup didn't take a table, I could stash data away > and > > > then > > > > un-stash it in auth_userdb_lookup > > > > > > > > Thanks! > > > > > > > > > > > > > > Yeah, this is a bug we have fixed =) > > > > > > https://github.com/dovecot/core/commit/c86575ac9776d0995355d03719c82e > > > 7ceac802e6#diff-83374eeaee91d90e848390ba3c7b264a > > > > > > > > > > I'm on rc1, so I appear to already have that git commit (as part of rc1). > > > > # /usr/sbin/dovecot --version > > 2.3.0.rc1 (12aba5948) > > > > For testing this, I tried replacing my passdb lookup with this: > > > > function auth_passdb_lookup(req) > > passdb_table = {} > > passdb_table[ 'password' ] = 'test' > > passdb_table[ 'user' ] = 'test1 at test.com' > > > > return dovecot.auth.PASSDB_RESULT_OK, passdb_table > > end > > > > and still get: > > > > Dec 22 01:17:17 auth-worker(9711): Info: > > lua(test1 at test.com,10.20.103.32,<f2O5xOdgFoYKFGcg>): > > No password returned (and no nopassword) > > > > Replacing that return statement with this: > > > > return dovecot.auth.PASSDB_RESULT_OK, 'password=test user=test1 at test.com > ' > > > > authenticates successfully. > > Fixed in https://github.com/dovecot/core/commit/ > e5fb6b3b7d4e79475b451823ea6c0a02955ba06b > > >Works like a charm now, thanks! As a matter of 'best practices', in my current iteration of Lua auth, I moved all my lookups to passdb (thus yesterday's emails to the list), so that it could be used with prefetch. Belatedly realizing that LMTP doesn't touch passdb, I rewrote the userdb lookup to call the same passdb lookup (which only happens for non-passdb/prefetch things) and then it copies the return table (but strips the 'userdb_' prefix). It's all working currently. BUT, does that sound sane? Or is there some gotcha I'm heading towards (yes, I realize the question is a bit vague -- just looking for very general "No, don't do that"). I'm curious too if I can set vars in the passdb lookup and then access then in userdb. Or is it random which auth-worker will handle the userdb lookup, relative to which one handled the passdb lookup? I tried dropping things in the req.userdb table in the passdb phase, but it was unset during the userdb phase.
> On December 22, 2017 at 9:16 PM Mark Moseley <moseleymark at gmail.com> wrote: > > > On Fri, Dec 22, 2017 at 5:18 AM, <aki.tuomi at dovecot.fi> wrote: > > > > > > On December 22, 2017 at 8:20 AM Mark Moseley <moseleymark at gmail.com> > > wrote: > > > > > > > > > On Thu, Dec 21, 2017 at 9:51 PM, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: > > > > > > > > > > > > On December 22, 2017 at 6:43 AM Mark Moseley <moseleymark at gmail.com> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) Is there an appropriate way to return data with spaces in it (or > > > > > > presumably other non-alphanum chars. My quota name had a space in > > it, > > > > > > which > > > > > > somehow got interpreted as 'yes' , i.e.: > > > > > > > > > > > > imap: Error: Failed to initialize quota: Invalid quota root quota: > > > > Unknown > > > > > > quota backend: yes > > > > > > > > > > > > I simply changed the space to an underscore as a workaround, but > > I'm > > > > > > curious if there's a better way. I tried various quoting without > > > > success. > > > > > > Didn't try escaping yet. > > > > > > > > > > > > > > > > > > 2) Instead of string, return a key value table. you can have > > spaces in > > > > > > values. > > > > > > > > > > > > > > > > > > > > > > > Does this work for auth_passdb_lookup too, or just > > auth_userdb_lookup? > > > > I've > > > > > been returning a table with auth_userdb_lookup just fine. But when I > > try > > > > > using it with passdb (and despite being very very sure that a > > 'password' > > > > > key exists in the table I'm returning from auth_passdb_lookup() -- > > I'm > > > > > logging it one line above the return), the passdb auth fails with > > this > > > > log > > > > > entry: > > > > > > > > > > Dec 21 23:29:22 auth-worker(7779): Info: > > > > > lua(test1 at test.com,10.20.103.32,<dSvLQuZg+uIKFGcg>): > > > > > No password returned (and no nopassword) > > > > > > > > > > I guess it's not seeing the password key in the table I'm returning. > > If I > > > > > return a concat'd string ("password=... user=...") from > > > > > auth_passdb_lookup(), it works just fine. > > > > > > > > > > I was also curious if there's a way to pass info between > > > > auth_userdb_lookup > > > > > and auth_passdb_lookup. I was trying to use a table with > > > > > auth_passdb_lookup() so I could take advantage of prefetch and > > thought > > > > that > > > > > if auth_passdb_lookup didn't take a table, I could stash data away > > and > > > > then > > > > > un-stash it in auth_userdb_lookup > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > Yeah, this is a bug we have fixed =) > > > > > > > > https://github.com/dovecot/core/commit/c86575ac9776d0995355d03719c82e > > > > 7ceac802e6#diff-83374eeaee91d90e848390ba3c7b264a > > > > > > > > > > > > > > I'm on rc1, so I appear to already have that git commit (as part of rc1). > > > > > > # /usr/sbin/dovecot --version > > > 2.3.0.rc1 (12aba5948) > > > > > > For testing this, I tried replacing my passdb lookup with this: > > > > > > function auth_passdb_lookup(req) > > > passdb_table = {} > > > passdb_table[ 'password' ] = 'test' > > > passdb_table[ 'user' ] = 'test1 at test.com' > > > > > > return dovecot.auth.PASSDB_RESULT_OK, passdb_table > > > end > > > > > > and still get: > > > > > > Dec 22 01:17:17 auth-worker(9711): Info: > > > lua(test1 at test.com,10.20.103.32,<f2O5xOdgFoYKFGcg>): > > > No password returned (and no nopassword) > > > > > > Replacing that return statement with this: > > > > > > return dovecot.auth.PASSDB_RESULT_OK, 'password=test user=test1 at test.com > > ' > > > > > > authenticates successfully. > > > > Fixed in https://github.com/dovecot/core/commit/ > > e5fb6b3b7d4e79475b451823ea6c0a02955ba06b > > > > > > > Works like a charm now, thanks! > > As a matter of 'best practices', in my current iteration of Lua auth, I > moved all my lookups to passdb (thus yesterday's emails to the list), so > that it could be used with prefetch. Belatedly realizing that LMTP doesn't > touch passdb, I rewrote the userdb lookup to call the same passdb lookup > (which only happens for non-passdb/prefetch things) and then it copies the > return table (but strips the 'userdb_' prefix). It's all working currently. > BUT, does that sound sane? Or is there some gotcha I'm heading towards > (yes, I realize the question is a bit vague -- just looking for very > general "No, don't do that"). >Sounds ok to me.> I'm curious too if I can set vars in the passdb lookup and then access then > in userdb. Or is it random which auth-worker will handle the userdb lookup, > relative to which one handled the passdb lookup? I tried dropping things in > the req.userdb table in the passdb phase, but it was unset during the > userdb phase.The best way is to export userdb_variables from passdb lookup. The userdb table itself is currently read-only, but yeah, it might be a good idea actually to support writing like this at some point. Aki