(RADIATOR) multiple AuthBy SQL clauses and temporary tables

[Brown, Randy]

Hugh: You wrote:

> From: Hugh Irvine [mailto:hugh at open.com.au]
> Sent: Friday, January 23, 2004 10:16 PM
> To: Brown, Randy
> Cc: radiator at open.com.au
> Subject: Re: (RADIATOR) multiple AuthBy SQL clauses and 
> temporary tables
> 
> Radiator tries to keep the database connection open all the time, and 
> all AuthBy clauses refering to the same database will share the one 
> connection. If the connection drops for any reason Radiator will 
> re-connect automatically.

I will include "AuthSQLStatement create temporary table if not exist ..." in each subsequent AuthBy SQL clause. It sounds like the table will almost always exist so the statement will just be cheap insurance.

> BTW - a much handier way of passing this sort of information around 
> is to add it to the current request, where subsequent AuthBy clauses 
> can access it. [snip]

I'm already doing this in several places with single-valued attributes, but I also need a multiple-row, multiple-attribute temporary table against which I do a different select for each succeeding AuthBy SQL.

> Also note that you can do *lots* of useful things with hooks - see 
> "goodies/hooks.txt".

I'm trying to keep things as simple as possible for later folks, most of whom are not likely to know perl very well. I am using a PreHandlerHook in ClientListSQL in order to stuff two attributes into the request already, and I _know_ that will be a mystery to some of my successors. It's kind of odd that <Client xxx> has (StripFrom|AddTo)Request and ClientListSQL does not, but the hook solves the problem. 

> Hope that helps.

It does indeed, relieving my fears that what works in tests might fail in production. Thank you. .... rb

> On 24 Jan 2004, at 13:13, Brown, Randy wrote:
> 
> > I am using AuthBy SQL with mysql 3.23. (Yes, it's old, but I don't 
> > have the option to change now.) I need several AuthBy SQL 
> clauses to 
> > check for different authentication types, all querying the same 
> > database. In order to simplify the specific AuthBy queries, 
> I'd like 
> > to create a temporary table in the first AuthBy SQL clause, 
> and refer 
> > to it in subsequent AuthBy SQL clauses. So, I have a question about 
> > the lifetime of the connections, as the temporary table 
> will disappear 
> > when the connection is closed.
> >
> > When are database connections closed? Is it safe to refer to a 
> > temporary table created in an early AuthBy SQL clause 
> invoked for the 
> > same request? Do I need to define an AuthSQLStatement "create 
> > temporary table if not exist..." in each subsequent clause?
> >
> > ---
> > Randy Brown
> > Principal Security Engineer
> > Cable & Wireless
> > www.cw.com
> >
> > email     randy.brown at cw.com
> > telephone +1-510-749-7035
> > ===
> > Archive at http://www.open.com.au/archives/radiator/
> > Announcements on radiator-announce at open.com.au
> > To unsubscribe, email 'majordomo at open.com.au' with
> > 'unsubscribe radiator' in the body of the message.
> >
> >
> 
> NB: have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
> 
> -- 
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.
> -
> CATool: Private Certificate Authority for Unix and Unix-like systems.
> 
> 
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.