On 11 Jan 2013, at 20:49, Phil Mayers <[email protected]> wrote:
> On 01/11/2013 08:32 PM, Arran Cudbard-Bell wrote:
>
>> Have you added nostrip for all the realms? The only way I can see it
>> clobbering username is if stripping is enabled.
>
> Isn't the problem the special request->username attribute?
It is, request->username appears to be pointing to the original User-Name pair
instead of the new perl one.
> AFAICT the pairmove code handles this specially ("fixup") but I'm not sure
> rlm_perl does the same?
Yes, unfortunately. That would have been a nice simple fix.
https://github.com/FreeRADIUS/freeradius-server/blob/v2.x.x/src/modules/rlm_perl/rlm_perl.c
@leggett
If you don't mind rebuilding the server, could you change:
https://github.com/FreeRADIUS/freeradius-server/blob/v2.x.x/src/main/modcall.c#L686
And add:
RDEBUG("Cached username is \"%s\", list username is \"%s\"",
request->username->vp_strvalue, pairfind(request->packet->vps,
PW_USER_NAME)->vp_strvalue);
Just after modcall_single()
Run it in debug mode and you'll see exactly where the username isn't being
updated. List username and cached username should always be in sync up until
the call to suffix, at which point the cached username should be stripped of
the realm.
>
> If that is the case, OP may find that putting the new username in an interim
> / temp variable then forcing update via unlang works:
>
> authorize {
> ...
> myperl
> update request {
> User-Name := "%{The-Var}"
> }
> ...
> }
Yeah it should do. That calls radius_pairmove which has the magic update cache
logic in it too.
-Arran
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
