[freeside] Radius Check Items

[ivan]

On Wed, Jul 05, 2000 at 06:49:53AM -0500, Kenny Elliott wrote:
> 
> 
> > >   I need to add the ability to add radius check items to a service
> > > definition. Currently if I add additional radius items to
> > the svc_acct
> > > and part_svc (I don't need to add them anywhere else
> > right) they will
> > > be treated as Radius reply items only. Adding check items
> > allows me to
> > > support NAS-Port-Type and ICRadius' Simultaneous-Login.
> > The best I've
> > > come up with so far is to add 'radiuscheck_' fields to
> > the database
> > > and supporting scripts. Do you see any problems with this?
> >
> > That should work for now - though I'd ask that you use
> > something no longer
> > than `radius_' - maybe `rcheck_' ?  The problem is the
> > resultant fields
> > in part_svc:
> >
> > svc_acct__radius_Attribute_flag
> >
> > which already overflow PostgreSQL default of 31 characters
> > for some RADIUS
> > attributes.  Come to think of it, it might be better to use
> > something as
> > short as possible - `rc_' ?
> 
> Any prefix would work really. I would suggest though that the radius_
> fields be renamed to follow along with the new fields. rr_ and rc_
> perhaps
> or maybe radrep_ and radchk_.

Ok, I needed this for a current customer so I went ahead and added it.
The new RADIUS check fields are prefixed with `rc_' but I left the reply
fields as `radius_' for now (you're welcome to submit a patch to change
them too).

> 
> > > Are there
> > > any reasons  you would not like to do it this way and
> > perhaps do it
> > > another.
> >
> > Longer-term, I need to do something about the length of the
> > column names -
> > The SQL1992 standard defines 18 character column names,
> > which would be a
> > reasonable goal.
> 
> Maybe the thing to do would be to separate these out to separate
> tables.
> then we could simply use something like id, attrib_name, attrib_value
> to
> store all of the radius values.

Hmm, no, that's not quite right.  You don't want to store the actual
strings in the records for each account.  Probably need a table that
corresponds to the RADIUS dictionary file, with a list of attributes and
attribute id's, then reference the attribute by id and not name.

The more difficult bit is handling the service definitions correctly -
part_svc and it's effects.

> It could be two separate tables or one
> with
> a field to indicate weather it's a check or reply field.

-- 
meow
_ivan