Re: [RADIATOR] Radiator's database handle

2012-02-21 Thread Alby
Hi Michael,
thank you for your response. Now I agree with you. It seems that doing a
new Auth clause is the best way to solve my problems, although it is not
the easier one.
I'm working on it hard!
Bye
Alberto

Il giorno 16 febbraio 2012 21:45, Michael  ha scritto:

> 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.
>
>
> 
># auth policy set to continue only if the auth fails.
>AuthByPolicyContinueWhileReject
>
>AuthLog NORMAL_ATUH_LOG
>
># a normal username/password test
>
>...
>
>
># due to policy, this is only done if previous failed.
>
># policy changed
>AuthByPolicyContinueWhileAccept
>
># authby to check a DEFAULT account and check password only.
>
>...
>
>   AuthSelect  SELECT username, crypt, ... FROM
> table WHERE BINARY username='DEFAULT'
>
>AuthColumnDef   1, Encrypted-Password, check
>AuthColumnDef   2, ...
>...
>
>
># due to AuthByPolicy only pass to another handler if
> previous auth passes.
>
>HandlerId "call another 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>> ri...@vianet.ca>>  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  , 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, a SuccessQuery, and
>>> "LogSuccess  1".
>>> if you want to write something when stop packets come in, use>> 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

[RADIATOR] Authenticating Devices...

2012-02-21 Thread Shay Smith
Hello,

I've got a working config that authenticates users connecting via Wifi.
Their credentials are compared against our LDAP database. I'm having
trouble figuring out how to get a non-login device to have access over the
same AP. I would like to know how to get a network device on the network
without requiring a login. I'd really like to compare it's MAC address or
IP address against a list in MySQL.

-- 
Shay Smith


Gmail Evangelist
David Douglas School District
503-261-8235

www.ddouglas.k12.or.us

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Authenticating Devices...

2012-02-21 Thread Mike Puchol
Shay, 

You should be able to configure your hotspot to perform MAC-based 
authentication by default upon stations associating. What this results is in an 
access-request with the username set to the MAC of the connecting device. You 
can keep these in your normal subscribers database.

Cheers,

Mike 


On Wednesday, February 22, 2012 at 12:56 AM, Shay Smith wrote:

> Hello,
> 
> I've got a working config that authenticates users connecting via Wifi. Their 
> credentials are compared against our LDAP database. I'm having trouble 
> figuring out how to get a non-login device to have access over the same AP. I 
> would like to know how to get a network device on the network without 
> requiring a login. I'd really like to compare it's MAC address or IP address 
> against a list in MySQL.
> 
> -- 
> Shay Smith
> 
> 
> 
> Gmail Evangelist
> David Douglas School District
> 503-261-8235 
> 
> www.ddouglas.k12.or.us (http://www.ddouglas.k12.or.us)
> 
> 
> ___
> radiator mailing list
> radiator@open.com.au (mailto:radiator@open.com.au)
> http://www.open.com.au/mailman/listinfo/radiator
> 
> 


___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator