Plug-in Question

[George Beitis]

Post auth seems like the best place to place authorization decisions,
given that post auth stands for post authentication.  It should take
place after proxying is done and should allow the option for setting 2
different possibilities, one for non proxied cases and one for proxied. 
Then again this might not be necessary as these 2 cases can be dealt by
the authorization engine given that the right information is passed to it.

logging should be possible right before authorization and after.

This is how i see things configured, what do u think?

Arran Cudbard-Bell wrote:
> Peter Nixon wrote:
>   
>> On Sat 07 Jul 2007, Arran Cudbard-Bell wrote:
>>   
>>     
>>> Phil Mayers wrote:
>>>     
>>>       
>>>> On Fri, 2007-07-06 at 11:49 +0200, Alan DeKok wrote:
>>>>       
>>>>         
>>>>> Stefan Winter wrote:
>>>>>         
>>>>>           
>>>>>> It's a long shot, but: wouldn't it make sense to clear the wording for
>>>>>> 2.0? I know, it would break all existing configs out there, but
>>>>>> manually working through the config is needed anyways...
>>>>>> I know that this wording startled me quite a bit when I was new
>>>>>> here...
>>>>>>           
>>>>>>             
>>>>>   It's worth doing.
>>>>>
>>>>>   The problem is we can't call the post-authentication step
>>>>> "authorize", because that will confuse everyone upgrading from 1.x.
>>>>>
>>>>>   I think the default configuration should be "pre-auth", "auth", and
>>>>> "post-auth".  We can still accept "authorize" as a synonym for
>>>>> "pre-auth" in the short term.
>>>>>         
>>>>>           
>>>> +1 - excellent idea
>>>>       
>>>>         
>>> +1 - Makes more sense...
>>>
>>> So proxying logic is done in pre-auth , authentication in auth , and
>>> reply formulation in post-auth...
>>>
>>> Yeah far better :) No more reply formulation for users who are going to
>>> be rejected ....
>>>
>>> + Remove post auth query from SQL module ... functionality can be
>>> replicated in unlang with minimum of fuss.
>>>     
>>>       
>> 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.
> - 
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
>
>