maybe this may help spark some ideas:
- check normal auth.
- if pass, done and accept.
- if fail, continue to a second auth that checks only a password.
- if fail, done and reject.
- but if password only passes, send to another handler which does something.
<Handler ...>
# auth policy set to continue only if the auth fails.
AuthByPolicy ContinueWhileReject
AuthLog NORMAL_ATUH_LOG
# a normal username/password test
<AuthBy SQL>
...
</AuthBy>
# due to policy, this is only done if previous failed.
<AuthBy GROUP>
# policy changed
AuthByPolicy ContinueWhileAccept
# authby to check a DEFAULT account and check password only.
<AuthBy SQL>
...
AuthSelect SELECT username, crypt, ... FROM table
WHERE BINARY username='DEFAULT'
AuthColumnDef 1, Encrypted-Password, check
AuthColumnDef 2, ...
...
</AuthBy>
# due to AuthByPolicy only pass to another handler if previous
auth passes.
<AuthBy HANDLER>
HandlerId "call another handler"
</AuthBy>
</AuthBy>
</Handler>
On 12-02-16 02:38 PM, Michael wrote:
> sounds like you may be trying to do something that is pretty complex. maybe
> you should be thinking about creating your own custom Auth Clause. section
> 17.0 in the Radiator manual. For example, i've created my own Auth Clause
> (AuthUNIX_UID) to support the UID value from unix password files as it was
> required for my purpose. The normal AuthUNIX doesn't do anything with UIDs.
>
>
>
> On 12-02-16 09:55 AM, Alby wrote:
>> Hi Michael,
>> thank you for your answer!
>> I agree with you, if you can do what you need with Radiator's configuration,
>> of course it is a better way to operate. But I need to implement a sort of
>> Self-Provisioning procedure. When a new user tries to authenticate, I first
>> let Radiator rejects the request (because the user does not have an account
>> on the system). But then I check if the user satisfies with some
>> prerequisites (e.g. a special password used and some more). If so, I create
>> an account for the new user (and write the SQL database from my
>> PostAuthHook) and then notify it of the account creation, for example by
>> mail. Up to now, I use a PostAuthHook script to do that. It works very well,
>> the only matter is about the performance when writing to the database
>> because I connect and disconnect each time. I've tried to do it in other
>> ways, but without any success, since up to now this seems to be the best
>> solution.
>> Cheers,
>> Alberto
>>
>> Il giorno 16 febbraio 2012 15:32,
>> Michael<[email protected]<mailto:[email protected]>> ha scritto:
>>
>> I hate to answer a question with another question, but what, why and/or
>> when are you writing data to the sql? I write data to sql but I do it
>> through any combination of<AuthBy SQL> <AuthLog SQL>, and sometimes an
>> AuthBy SessionDB. Works much better for me. I try to avoid custom hooks if
>> at all possible. The ability for hooks is great to have, but if Radiator
>> can already do a task just through config, i try to do it that way instead
>> of a hook.
>>
>> So, if you want to write something to a table for example ever time a
>> user authenticates, use an<AuthBy AuthLog>, a SuccessQuery, and "LogSuccess
>> 1".
>> if you want to write something when stop packets come in, use<AuthBy
>> SQL>, with "HandleAcctStatusTypes Stop", and a AcctSQLStatement.
>>
>> depends on what you need to do.
>>
>>
>>
>> On 12-02-16 09:17 AM, Alby wrote:
>>
>> Hi all,
>> I'm using radiator with a SQL database that stores the users' data.
>> I've also a PostAuthHook that writes some data on the SQL database. Up to
>> now my Hook connects to the database, writes the data and then disconnects.
>> I suspect that connecting and disconnecting each time I write to the
>> database is not a really good idea (expecially for the performance). I've
>> noticed that Radiator opens the connection to the database only the first
>> time, then reuses it (this is of course a better way than mine). Since the
>> database that I write is the same that I use on Radiator (same name, same
>> user and same password), is there a way to reuse the Radiator's DB handle
>> instead of creating a new one and destroying it each time?
>> At at first glance, my idea was to open the database connection
>> with a StartUpHook and then close with a ShutdownHook, but there is the
>> problem on how to share the DB handle between the three Hooks. This should
>> be made securely, because if an attacker is able to obtain the handler, it
>> will be able to read and write the database without performing
>> authentication first, I think. In my opinion reusing the Radiator DB handle
>> is the best solution if it can be implemented.
>> Thank you very much in advance for your help and for your attention
>> Alberto
>>
>>
>> _________________________________________________
>> radiator mailing list
>> [email protected]<mailto:[email protected]>
>>
>> http://www.open.com.au/__mailman/listinfo/radiator<http://www.open.com.au/mailman/listinfo/radiator>
>>
>>
> _______________________________________________
> radiator mailing list
> [email protected]
> http://www.open.com.au/mailman/listinfo/radiator
>
>
_______________________________________________
radiator mailing list
[email protected]
http://www.open.com.au/mailman/listinfo/radiator
