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.