RE: rlm_sql: group table changes

> > Hmm... That's a good point. I've updated the rlm_sql=20
> > module in CVS to
> > handle this situation so that it more closely matches the=20
> > users file=20
> > methodology (if there are no check pairs, then the section is=20
> > automatically matched).
>=20
> Thats great! It gives much more flexibility now where it=20
> works like the users file.
>=20
> For rejecting every user that has no matching group profile i=20
> guess my best bet is now to use a DEFAULT profile with=20
> "Auth-Type :=3D Reject" in the db?

I've been reading all related to tables and radcheck, radreply, etc, etc
.... and got to the conclusion that the best and useful way of handling
users and reply atributes is by using stored-procedures, and let the
storedprocedure return a table based on what you want to do. I'm doing
it that way and find it really comfortable and versatile. Do you agree
??

I mean ... you could for example do some scripting with your procedure
and if you want to reject a user, just do your code and "build" a table
and return Auth-Type :=3D Reject. In that way you do not need to have a
table full of reply attributes for each user or eache group.=20

Regards,

Lucas

--=20
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.0 - Release Date: 29/04/2005
=20


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html