Hi again - Or use a variation of the session database to store whatever you need locally.
regards Hugh > On 28 Nov 2017, at 18:19, Christian Kratzer <[email protected]> wrote: > > Hi, > > On Mon, 27 Nov 2017, Robert Blayzor wrote: >> Hugh, thanks for that example. I suppose that might work, but that kind of >> gets ugly from our standpoint. I?d really like to not have to parse up Class >> as we?re using that in several places now. If we change it, it?s going to >> require a bunch of code changes and parsing. >> >> Maybe an easier way, if one is known is how we can use/find which AuthBy is >> the one that?s accepted? >> >> <AuthBy GROUP> >> Identifier GROUP_1 >> AuthByPolicy ContinueUntilAccept >> AuthBy X_BLACKHOLE >> AuthBy X_AUTH1 >> AuthBy X_DEFAULT >> </AuthBy> >> >> >> I?m looking for a way to identify users with successful login on X_DEFAULT >> only. (default). The first two AuthBy?s in the group can log normally, only >> logging failure. >> >> FOr AuthBy X_DEFAULT it would be nice to log on Success and Failure. >> >> If that?s not possible, I?m looking for something (other than class) that I >> could flag in authentication request so that when accounting records come >> in, they are flagged. I appreciate your Class tags, but at this point, >> that?s last resort changing Class. >> >> >> I simply need to find a way where we can identify in either log or in >> accounting those users successfully (and only successfully) getting accepted >> in X_DEFAULT. > > have you considered storing the full request in a memory database like redis > or memcache and just putting the key into the class attribute. > > It's a bit more work but would propably scale to much more flexibility. > > Greetings > Christian > > -- > Christian Kratzer CK Software GmbH > Email: [email protected] Wildberger Weg 24/2 > Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden > Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart > Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer > Web: http://www.cksoft.de/ -- Hugh Irvine [email protected] Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER, SIM, etc. Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list [email protected] http://lists.open.com.au/mailman/listinfo/radiator
