Plug-in Question

[Phil Mayers]

On Sun, 2007-07-08 at 10:09 +0100, Arran Cudbard-Bell wrote:
> Phil Mayers wrote:
> >>> Why do this? The ability to log things to sql post-auth is very usefull and I 
> >>> believe fairly widely used. What is the advantage of removing it?
> >>>
> >>>   
> >>>       
> >> Right, so you wanting to authorize people in post-auth using .... then 
> >> theres a conflict. You can't select whether you want to use the logging 
> >> function of rlm_sql or the authorisation function.
> >>     
> >
> > Of course you can:
> >
> > post-auth {
> >   sql # does the logging
> >
> >   if (%{control:Foo-Bar}=="baz") {
> >     update reply {
> >       # does the "authorization"
> >       Baz-Attr = %{sql:select bazattr from ...}
> >     }
> >   }
> > }
> >   
> That doesn't replicate the authorisation capabilities of the SQL module 
> at all ?!

Ok, now I get you.

You are wanting to use the post-auth section to run the radcheck and
radreply queries only once, and only on Access-Accept.

Obviously if the sql module runs them in the "pre-auth" section (nee
"authorize"), you can't do that. If it runs them in the "post-auth",
it'll conflict (or need to be merged) with the logging function.

I can see where you're coming from, but bear this in mind: though you
don't store password hashes in SQL (nor do we) many people do, and
*those* queries will *have* to run in pre-auth.

It's not reasonable to expect that all those users change from:

authorize {
  sql
}

to use unlang:

pre-auth {
  update control {
    Cleartext-Password = %{sql:select ...}
  }
}

How about the sql module acquire a config item:

sql {
  run_queries_in = [pre-auth | post-auth]
}

> SQL XLAT only allows you to write one column and one row to one 
> attribute, it would take hundreds of queries and a few pages of logic to 
> replicate SQL authorisation in unlang..

Indeed.