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