Re: Lua Auth

[Aki Tuomi]

> On December 22, 2017 at 9:16 PM Mark Moseley  wrote:
> 
> 
> On Fri, Dec 22, 2017 at 5:18 AM,  wrote:
> 
> >
> > > On December 22, 2017 at 8:20 AM Mark Moseley 
> > wrote:
> > >
> > >
> > > On Thu, Dec 21, 2017 at 9:51 PM, Aki Tuomi  wrote:
> > >
> > > >
> > > > > On December 22, 2017 at 6:43 AM Mark Moseley 
> > > > 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(te...@test.com,10.20.103.32,):
> > > > > 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' ] = 'te...@test.com'
> > >
> > > return dovecot.auth.PASSDB_RESULT_OK, passdb_table
> > > end
> > >
> > > and still get:
> > >
> > > Dec 22 01:17:17 auth-worker(9711): Info:
> > > lua(te...@test.com,10.20.103.32,):
> > > No password returned (and no nopassword)
> > >
> > > Replacing that return statement with this:
> > >
> > > return dovecot.auth.PASSDB_RESULT_OK, 'password=test user=te...@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

Re: Lua Auth

[Mark Moseley]

On Fri, Dec 22, 2017 at 5:18 AM,  wrote:

>
> > On December 22, 2017 at 8:20 AM Mark Moseley 
> wrote:
> >
> >
> > On Thu, Dec 21, 2017 at 9:51 PM, Aki Tuomi  wrote:
> >
> > >
> > > > On December 22, 2017 at 6:43 AM Mark Moseley 
> > > 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(te...@test.com,10.20.103.32,):
> > > > 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' ] = 'te...@test.com'
> >
> > return dovecot.auth.PASSDB_RESULT_OK, passdb_table
> > end
> >
> > and still get:
> >
> > Dec 22 01:17:17 auth-worker(9711): Info:
> > lua(te...@test.com,10.20.103.32,):
> > No password returned (and no nopassword)
> >
> > Replacing that return statement with this:
> >
> > return dovecot.auth.PASSDB_RESULT_OK, 'password=test user=te...@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.

Re: Lua Auth

[aki . tuomi]

> On December 22, 2017 at 8:20 AM Mark Moseley  wrote:
> 
> 
> On Thu, Dec 21, 2017 at 9:51 PM, Aki Tuomi  wrote:
> 
> >
> > > On December 22, 2017 at 6:43 AM Mark Moseley 
> > 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(te...@test.com,10.20.103.32,):
> > > 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' ] = 'te...@test.com'
> 
> return dovecot.auth.PASSDB_RESULT_OK, passdb_table
> end
> 
> and still get:
> 
> Dec 22 01:17:17 auth-worker(9711): Info:
> lua(te...@test.com,10.20.103.32,):
> No password returned (and no nopassword)
> 
> Replacing that return statement with this:
> 
> return dovecot.auth.PASSDB_RESULT_OK, 'password=test user=te...@test.com'
> 
> authenticates successfully.

Fixed in 
https://github.com/dovecot/core/commit/e5fb6b3b7d4e79475b451823ea6c0a02955ba06b

Aki

Re: Lua Auth

[Mark Moseley]

On Thu, Dec 21, 2017 at 9:51 PM, Aki Tuomi  wrote:

>
> > On December 22, 2017 at 6:43 AM Mark Moseley 
> 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(te...@test.com,10.20.103.32,):
> > 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' ] = 'te...@test.com'

return dovecot.auth.PASSDB_RESULT_OK, passdb_table
end

and still get:

Dec 22 01:17:17 auth-worker(9711): Info:
lua(te...@test.com,10.20.103.32,):
No password returned (and no nopassword)

Replacing that return statement with this:

return dovecot.auth.PASSDB_RESULT_OK, 'password=test user=te...@test.com'

authenticates successfully.

Re: Lua Auth

[Aki Tuomi]

> On December 22, 2017 at 6:43 AM Mark Moseley  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(te...@test.com,10.20.103.32,):
> 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/c86575ac9776d0995355d03719c82e7ceac802e6#diff-83374eeaee91d90e848390ba3c7b264a

Aki

Re: Lua Auth

[Mark Moseley]

>
>
>
>
> 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(te...@test.com,10.20.103.32,):
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!




> 3) response_from_template expands a key=value string into table by var
> expanding values.
>
>
> var_expand can be used to interpolation for any purposes. it returns a
> string. see https://wiki.dovecot.org/Variables for details on how to use
> it.
>
>
> Individual variable access is more efficient to do directly.
>
>
> ---
> Aki Tuomi
>

Re: Lua Auth

[Aki Tuomi]

 Original message From: Mark Moseley <moseleym...@gmail.com> 
Date: 02/12/2017  02:34  (GMT+02:00) To:  Cc: Dovecot Mailing List 
<dovecot@dovecot.org> Subject: Re: Lua Auth 
On Thu, Nov 30, 2017 at 5:26 AM, Stephan Bosch <s.bo...@ox.io> wrote:

>
>
> Op 29-11-2017 om 6:17 schreef Aki Tuomi:
>
>> On November 29, 2017 at 4:37 AM Mark Moseley <moseleym...@gmail.com>
>>> wrote:
>>>
>>>
>>> Just happened to be surfing the docs and saw this. This is beyond
>>> awesome:
>>>
>>> https://wiki2.dovecot.org/AuthDatabase/Lua
>>>
>>> Any words of wisdom on using it? I'd be putting a bunch of mysql logic in
>>> it. Any horrible gotchas there? When it says 'blocking', should I assume
>>> that means that a auth worker process will *not* accept any new auth
>>> lookups until both auth_passdb_lookup() and auth_userdb_lookup() have
>>> completed (in which I'd be doing several mysql calls)? If that's the
>>> case,
>>> I assume that the number of auth workers should be bumped up.
>>>
>>> And is a 2.3 release fairly imminent?
>>>
>> Hi!
>>
>> This feature was added very recently, and there is very little
>> operational experience on it. As the docs should say, blocking=yes means
>> that an auth worker is used, and yes, it will block each auth worker during
>> authentication, but what we tried, it should perform rather nicely.
>>
>> The most important gotcha is to always test your lua code rigorously,
>> because there is not much we can do to save you.
>>
>> It should be present in master branch, so if someone feels like trying it
>> out, please let us know if you find any bugs or strangeness. It's not
>> present in nightlies yet.
>>
>> We are planning on releasing 2.3.0 this year.
>>
>
> The Xi package builder has this feature enabled since yesterday. It is
> available in the dovecot-lua package; the first Xi package that doesn't
> have an official Debian equivalent (yet anyway).
>
>
>
I've been playing with Lua auth and so far no issues. I was previously
putting together a very ugly MySQL stored procedure. Using Lua would be a
lot easier (esp when it comes to returning an arbitrary number of columns).

I'd love to see any test Lua code that the dovecot team has been playing
around with (and realize it's not remotely production-ready, so don't worry
about caveats

I did have a couple of questions though:

1) Is the data returned by Lua auth not cacheable? I've got the following
settings (and I'm just using Lua in the userdb lookup, not passdb -- passdb
is doing a lightweight SQL lookup for username/password):

auth_cache_negative_ttl = 1 mins
auth_cache_size = 10 M
auth_cache_ttl = 10 mins

but I notice that every time I auth, it'll redo all the queries in my Lua
code. I'd have expected that data to be served out of cache till the 10min
TTL is up


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.


3) Can you elaborate on the "auth_request#response_from_template(template)"
and "auth_request#var_expand(template)" functions? Specifically how to use
them. I'm guessing that I could've used one of them to work around #2 (that
it would have done the escaping for me)


Thanks!

-

1) I'll have to check this.
  

  2) Instead of string, return a key value table. you can have spaces in values.
  

  3) response_from_template expands a key=value string into table by var 
expanding values. 
  

  var_expand can be used to interpolation for any purposes. it returns a 
string. see https://wiki.dovecot.org/Variables for details on how to use it. 
  

  Individual variable access is more efficient to do directly.
  

  ---
Aki Tuomi

Re: Lua Auth

[Mark Moseley]

On Thu, Nov 30, 2017 at 5:26 AM, Stephan Bosch  wrote:

>
>
> Op 29-11-2017 om 6:17 schreef Aki Tuomi:
>
>> On November 29, 2017 at 4:37 AM Mark Moseley 
>>> wrote:
>>>
>>>
>>> Just happened to be surfing the docs and saw this. This is beyond
>>> awesome:
>>>
>>> https://wiki2.dovecot.org/AuthDatabase/Lua
>>>
>>> Any words of wisdom on using it? I'd be putting a bunch of mysql logic in
>>> it. Any horrible gotchas there? When it says 'blocking', should I assume
>>> that means that a auth worker process will *not* accept any new auth
>>> lookups until both auth_passdb_lookup() and auth_userdb_lookup() have
>>> completed (in which I'd be doing several mysql calls)? If that's the
>>> case,
>>> I assume that the number of auth workers should be bumped up.
>>>
>>> And is a 2.3 release fairly imminent?
>>>
>> Hi!
>>
>> This feature was added very recently, and there is very little
>> operational experience on it. As the docs should say, blocking=yes means
>> that an auth worker is used, and yes, it will block each auth worker during
>> authentication, but what we tried, it should perform rather nicely.
>>
>> The most important gotcha is to always test your lua code rigorously,
>> because there is not much we can do to save you.
>>
>> It should be present in master branch, so if someone feels like trying it
>> out, please let us know if you find any bugs or strangeness. It's not
>> present in nightlies yet.
>>
>> We are planning on releasing 2.3.0 this year.
>>
>
> The Xi package builder has this feature enabled since yesterday. It is
> available in the dovecot-lua package; the first Xi package that doesn't
> have an official Debian equivalent (yet anyway).
>
>
>
I've been playing with Lua auth and so far no issues. I was previously
putting together a very ugly MySQL stored procedure. Using Lua would be a
lot easier (esp when it comes to returning an arbitrary number of columns).

I'd love to see any test Lua code that the dovecot team has been playing
around with (and realize it's not remotely production-ready, so don't worry
about caveats

I did have a couple of questions though:

1) Is the data returned by Lua auth not cacheable? I've got the following
settings (and I'm just using Lua in the userdb lookup, not passdb -- passdb
is doing a lightweight SQL lookup for username/password):

auth_cache_negative_ttl = 1 mins
auth_cache_size = 10 M
auth_cache_ttl = 10 mins

but I notice that every time I auth, it'll redo all the queries in my Lua
code. I'd have expected that data to be served out of cache till the 10min
TTL is up


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.


3) Can you elaborate on the "auth_request#response_from_template(template)"
and "auth_request#var_expand(template)" functions? Specifically how to use
them. I'm guessing that I could've used one of them to work around #2 (that
it would have done the escaping for me)


Thanks!

Re: Lua Auth

[Aki Tuomi]

> On November 29, 2017 at 4:37 AM Mark Moseley  wrote:
> 
> 
> Just happened to be surfing the docs and saw this. This is beyond awesome:
> 
> https://wiki2.dovecot.org/AuthDatabase/Lua
> 
> Any words of wisdom on using it? I'd be putting a bunch of mysql logic in
> it. Any horrible gotchas there? When it says 'blocking', should I assume
> that means that a auth worker process will *not* accept any new auth
> lookups until both auth_passdb_lookup() and auth_userdb_lookup() have
> completed (in which I'd be doing several mysql calls)? If that's the case,
> I assume that the number of auth workers should be bumped up.
> 
> And is a 2.3 release fairly imminent?

Hi!

This feature was added very recently, and there is very little operational 
experience on it. As the docs should say, blocking=yes means that an auth 
worker is used, and yes, it will block each auth worker during authentication, 
but what we tried, it should perform rather nicely.

The most important gotcha is to always test your lua code rigorously, because 
there is not much we can do to save you.

It should be present in master branch, so if someone feels like trying it out, 
please let us know if you find any bugs or strangeness. It's not present in 
nightlies yet.

We are planning on releasing 2.3.0 this year.

Aki