Re: Lua Auth

older
ot: how to block persistent same...

Mark Moseley

22 Dec 2017 22 Dec '17

6:43 a.m.

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.

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@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!

...

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

Show replies by date

Aki Tuomi

22 Dec 22 Dec

7:51 a.m.

New subject: Lua Auth

...

On December 22, 2017 at 6:43 AM Mark Moseley moseleymark@gmail.com wrote:

...

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.

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@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/c86575ac9776d0995355d03719c82e7ceac80...

Aki

Mark Moseley

8:20 a.m.

New subject: Lua Auth

On Thu, Dec 21, 2017 at 9:51 PM, Aki Tuomi aki.tuomi@dovecot.fi wrote:

...

...
On December 22, 2017 at 6:43 AM Mark Moseley moseleymark@gmail.com wrote:

...

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.

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@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' ] = 'test1@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@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@test.com'

authenticates successfully.

aki.tuomi＠dovecot.fi

3:18 p.m.

New subject: Lua Auth

...

On December 22, 2017 at 8:20 AM Mark Moseley moseleymark@gmail.com wrote:

On Thu, Dec 21, 2017 at 9:51 PM, Aki Tuomi aki.tuomi@dovecot.fi wrote:

...
...
On December 22, 2017 at 6:43 AM Mark Moseley moseleymark@gmail.com wrote:

...

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.

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@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' ] = 'test1@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@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@test.com'

authenticates successfully.

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

Aki

Mark Moseley

9:16 p.m.

New subject: Lua Auth

On Fri, Dec 22, 2017 at 5:18 AM, aki.tuomi@dovecot.fi wrote:

...

...
On December 22, 2017 at 8:20 AM Mark Moseley moseleymark@gmail.com wrote:

On Thu, Dec 21, 2017 at 9:51 PM, Aki Tuomi aki.tuomi@dovecot.fi wrote:

...
...
On December 22, 2017 at 6:43 AM Mark Moseley moseleymark@gmail.com wrote:

...

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

...
...
...
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.

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

...
...
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

...
log

...
entry:

Dec 21 23:29:22 auth-worker(7779): Info: lua(test1@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

it, try this thought

...
...
if auth_passdb_lookup didn't take a table, I could stash data away and

that 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@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@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@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.

Aki Tuomi

23 Dec 23 Dec

10:53 a.m.

New subject: Lua Auth

...

On December 22, 2017 at 9:16 PM Mark Moseley moseleymark@gmail.com wrote:

On Fri, Dec 22, 2017 at 5:18 AM, aki.tuomi@dovecot.fi wrote:

...
...
On December 22, 2017 at 8:20 AM Mark Moseley moseleymark@gmail.com wrote:

On Thu, Dec 21, 2017 at 9:51 PM, Aki Tuomi aki.tuomi@dovecot.fi wrote:

...
...
On December 22, 2017 at 6:43 AM Mark Moseley moseleymark@gmail.com wrote:

...

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

...
...
...
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.

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

...
...
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

...
log

...
entry:

Dec 21 23:29:22 auth-worker(7779): Info: lua(test1@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

it, try this thought

...
...
if auth_passdb_lookup didn't take a table, I could stash data away and

that 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@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@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@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

2528

Age (days ago)

2529

Last active (days ago)

List overview

5 comments

3 participants

participants (3)

Aki Tuomi
aki.tuomi＠dovecot.fi
Mark Moseley

Re: Lua Auth

Mark Moseley

Aki Tuomi

Mark Moseley

aki.tuomi＠dovecot.fi

Mark Moseley

Aki Tuomi

tags

participants (3)