Re: rlm_realm module, Realm attr value
On Mon, Jan 24, 2011 at 03:15:46PM +, Phil Mayers wrote:
If the configured realm value is DEFAULT, the realm as entered
by the user could be used to feed the Realm attribute value.
I don't think this is a good change.
For example:
authorize {
suffix
if (Realm == DEFAULT) {
# not a local realm; do some stuff
attr_filter.eduroam
}
}
...if you change the value of the Realm variable, it's never possible
to compare against it. We rely on this in a number of places.
Thanks for your comments. Beeing able to differentiate a path
the request is about to take is a real need. I've had an impression
%{control:Proxy-To-Realm} can be referenced to get this particular
information. Please, correct me in case I need to pick up on the
intended attribute content and its use.
Since as you point out, you can already accomplish this with unlang or
regexp realms, I don't think it's necessary to change the behaviour of
the existing module.
I admit, the ability to do comparisons against the matched proxy realm
value is a feature I'd like to keep.
Martin
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_realm module, Realm attr value
Hello,
Thanks for your comments. Beeing able to differentiate a path
the request is about to take is a real need. I've had an impression
%{control:Proxy-To-Realm} can be referenced to get this particular
information. Please, correct me in case I need to pick up on the
intended attribute content and its use.
Seems like the term Realm is used in an overloaded manner: on the one
hand, it's the user-supplied character string, on the other hand it's a
named instance of the realm module.
Looks like up until 2.1.8, the AVP Realm was always created with
Realm-the-character-string as it came from the request, but with 2.1.9,
this changed to Realm-the-instance-name.
Problem is, both of these can be valuable somehow, and need to be
addressable. In a rlm_linelog, I care about logging the actual input; at
other places, I may want to check which path the packet will take.
In short, I think there should be two attributes: one to contain the
instance name, one with the string. Using unlang is of course possible,
but clumsy - it worked without before.
Greetings,
Stefan Winter
--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la
Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
Tel: +352 424409 1
Fax: +352 422473
signature.asc
Description: OpenPGP digital signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_realm module, Realm attr value
On 01/25/2011 08:36 AM, Martin Stanislav wrote:
Thanks for your comments. Beeing able to differentiate a path
the request is about to take is a real need. I've had an impression
%{control:Proxy-To-Realm} can be referenced to get this particular
information. Please, correct me in case I need to pick up on the
intended attribute content and its use.
That's a good point.
It's up to others (Alan) really if he wants to change the behaviour. I
suspect it would be best to wait for 2.2 for a behaviour change, if so.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_realm module, Realm attr value
Stefan Winter wrote: Seems like the term Realm is used in an overloaded manner: on the one hand, it's the user-supplied character string, on the other hand it's a named instance of the realm module. Not quite... a user-supplied character string, and a named realm in the proxy.conf file. The named realms are used by the realms module to find a matching name. Looks like up until 2.1.8, the AVP Realm was always created with Realm-the-character-string as it came from the request, but with 2.1.9, this changed to Realm-the-instance-name. Hmm... I think it's the other way around. In 2.1.9, a regex realm results in Realm = match, instead of Realm = regex. Problem is, both of these can be valuable somehow, and need to be addressable. In a rlm_linelog, I care about logging the actual input; at other places, I may want to check which path the packet will take. In short, I think there should be two attributes: one to contain the instance name, one with the string. Using unlang is of course possible, but clumsy - it worked without before. There's utility creating two attributes, I think. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_realm module, Realm attr value
On Tue, Jan 25, 2011 at 01:52:21PM +0100, Alan DeKok wrote: The named realms are used by the realms module to find a matching name. Looks like up until 2.1.8, the AVP Realm was always created with Realm-the-character-string as it came from the request, but with 2.1.9, this changed to Realm-the-instance-name. Hmm... I think it's the other way around. In 2.1.9, a regex realm results in Realm = match, instead of Realm = regex. Correct. Problem is, both of these can be valuable somehow, and need to be addressable. In a rlm_linelog, I care about logging the actual input; at other places, I may want to check which path the packet will take. In short, I think there should be two attributes: one to contain the instance name, one with the string. Using unlang is of course possible, but clumsy - it worked without before. There's utility creating two attributes, I think. CPU cycles are burned within the rlm_realm to extract both, the realm as entered by the user and the matched proxy.conf realm entry. The Proxy-To-Realm attribute holds the latter value (realm_authorize realm_preacct function calls). The Realm attribute is set to the same value except holding a regex. It's set to the former value in such a case. In other words, DEFAULT proxy.conf entry is the only case, when the Realm attribute doesn't exactly match (string, case insensitive) the realm as entered by the user. Martin - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_realm module, Realm attr value
G'day,
FreeRADIUS rlm_realm module feeds the Realm attribute with a configured
value that matched the realm as entered by the user. There is one exception.
If the matched configured value is a regex, the realm as entered by the user
is used to feed the Realm attribute value.
There is one more case that could get this exception like treatment.
If the configured realm value is DEFAULT, the realm as entered
by the user could be used to feed the Realm attribute value.
Attached diff file describes the code change.
Alternatively, unlang can be employed to get the details into the Realm
attribute. If placed within the authorize section after the realm module
instance call (the suffix instance and delimiter = '@' is assumed to be
in use in this case):
if (Realm == DEFAULT User-Name =~ /@(.*)$/) {
update request {
Realm := %{1}
}
}
Kind regards,
Martin
diff --git a/src/modules/rlm_realm/rlm_realm.c
b/src/modules/rlm_realm/rlm_realm.c
index 6006769..2da7211 100644
--- a/src/modules/rlm_realm/rlm_realm.c
+++ b/src/modules/rlm_realm/rlm_realm.c
@@ -197,13 +197,16 @@ static int check_for_realm(void *instance, REQUEST
*request, REALM **returnrealm
/*
* Add the realm name to the request.
-* If the realm is a regex, the use the realm as entered
-* by the user. Otherwise, use the configured realm name,
-* as realm name comparison is case insensitive. We want
-* to use the configured name, rather than what the user
+* If the realm is a regex or DEFAULT, then use the realm
+* as entered by the user. Otherwise, use the configured
+* realm name, as realm name comparison is case insensitive.
+* We want to use the configured name, rather than what the user
* entered.
*/
- if (realm-name[0] != '~') realmname = realm-name;
+ if (realm-name[0] != '~') {
+ if (strcmp(realm-name, DEFAULT) != 0)
+ realmname = realm-name;
+ }
pairadd(request-packet-vps, pairmake(Realm, realmname,
T_OP_EQ));
RDEBUG2(Adding Realm = \%s\, realmname);
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_realm module, Realm attr value
On 01/24/2011 02:32 PM, Martin Stanislav wrote:
There is one more case that could get this exception like treatment.
If the configured realm value is DEFAULT, the realm as entered
by the user could be used to feed the Realm attribute value.
Attached diff file describes the code change.
I don't think this is a good change.
For example:
authorize {
suffix
if (Realm == DEFAULT) {
# not a local realm; do some stuff
attr_filter.eduroam
}
}
...if you change the value of the Realm variable, it's never possible
to compare against it. We rely on this in a number of places.
Since as you point out, you can already accomplish this with unlang or
regexp realms, I don't think it's necessary to change the behaviour of
the existing module.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
