Can we re-order the authorization queries in the SQL module?
We have a case that needs to prioritize the group reply attributes more than the user reply attributes in the same attribute. However, I found a fixed order for the authorization queries in the source code as below. radcheck -> radreply -> radgroupcheck -> radgroupreply If I change the orders in queries.conf, the query order is not changed while authorizing. So I wonder if we can re-order the authorization queries by any configuration to make higher priority for the group reply? Thanks.
Sorry, there is a mistake in the question. It should be: Can we re-order the authorization queries by any configuration to make a higher priority for the user reply in the same attribute? Thanks. On Wed, Nov 22, 2023 at 1:57 PM James Fan <polysorb@gmail.com> wrote:
We have a case that needs to prioritize the group reply attributes more than the user reply attributes in the same attribute. However, I found a fixed order for the authorization queries in the source code as below. radcheck -> radreply -> radgroupcheck -> radgroupreply If I change the orders in queries.conf, the query order is not changed while authorizing. So I wonder if we can re-order the authorization queries by any configuration to make higher priority for the group reply? Thanks.
On 22.11.23 07:48, James Fan wrote:
Sorry, there is a mistake in the question. It should be:
Hmm. You do know that there are lot of more "mistakes" in your question that just that. Starting with the simple things like which version you are running or what exactly you are doing. Alan almost each time points out to the welcome message of this list and what's needed. Guessing from the lack of information you have provided, your issue seems to be in the use of the operating in your reply. It's unlang. You have used the operator to replace a value if there is already one. You want to use the operator which sets the value only if it's not already there. I think that should do it. But again, I am only guessing about what you are doing... Cheers, Gerald
Can we re-order the authorization queries by any configuration to make a higher priority for the user reply in the same attribute? Thanks.
On Wed, Nov 22, 2023 at 1:57 PM James Fan <polysorb@gmail.com> wrote:
We have a case that needs to prioritize the group reply attributes more than the user reply attributes in the same attribute. However, I found a fixed order for the authorization queries in the source code as below. radcheck -> radreply -> radgroupcheck -> radgroupreply If I change the orders in queries.conf, the query order is not changed while authorizing. So I wonder if we can re-order the authorization queries by any configuration to make higher priority for the group reply? Thanks.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Nov 22, 2023, at 12:57 AM, James Fan <polysorb@gmail.com> wrote:
We have a case that needs to prioritize the group reply attributes more than the user reply attributes in the same attribute. However, I found a fixed order for the authorization queries in the source code as below. radcheck -> radreply -> radgroupcheck -> radgroupreply If I change the orders in queries.conf, the query order is not changed while authorizing.
Yes... the order of the queries is controlled by the source code, not by their location in the files.
So I wonder if we can re-order the authorization queries by any configuration to make higher priority for the group reply? Thanks.
Why not use the operators? Make the group replies use ":=", and it will over-ride whatever is set in the user profile. Or, describe the problem in more detail. What would you like to do, and why does the current behavior not work? Don't say "I need to change the order of the queries". That's a solution. Describe what you want the server to do at a high level. We can then offer a solution which doesn't involve changing query order or source code. i.e. "I need to make my car waterproof" is a solution. The real problem might be "I want to fill the pool with water". The real solution is a garden hose, not transporting water in the car. The same thing applies here. Alan DeKok.
Hi Alan and Gerald, Thanks for your answer. My problem was if I set a user attribute name "vlan_id" which is stored in the radreply table and the radgroupreply table. But they have different values. The client will receive the value for the "vlan_id" in the radgroupreply. But we want to make the radreply attributes a higher priority to overwrite the radgroupreply values for the same attribute. After studying the SQL module, I found a solution that uses multiple instances to separate the queries like below: sql sql-group { # Do group reply queries } sql sql-user-reply { # Do user reply queries } So we can run these modules using this order: sql-group-reply.authorize sql-user-reply.authorize That makes the user attributes overwrite the group attributes and resolves our problem. I wonder if that is the best solution or if you have any good ideas. Thanks. On Wed, Nov 22, 2023 at 9:21 PM Alan DeKok <aland@deployingradius.com> wrote:
On Nov 22, 2023, at 12:57 AM, James Fan <polysorb@gmail.com> wrote:
We have a case that needs to prioritize the group reply attributes more than the user reply attributes in the same attribute. However, I found a fixed order for the authorization queries in the source code as below. radcheck -> radreply -> radgroupcheck -> radgroupreply If I change the orders in queries.conf, the query order is not changed while authorizing.
Yes... the order of the queries is controlled by the source code, not by their location in the files.
So I wonder if we can re-order the authorization queries by any configuration to make higher priority for the group reply? Thanks.
Why not use the operators? Make the group replies use ":=", and it will over-ride whatever is set in the user profile.
Or, describe the problem in more detail. What would you like to do, and why does the current behavior not work?
Don't say "I need to change the order of the queries". That's a solution. Describe what you want the server to do at a high level.
We can then offer a solution which doesn't involve changing query order or source code.
i.e. "I need to make my car waterproof" is a solution. The real problem might be "I want to fill the pool with water".
The real solution is a garden hose, not transporting water in the car. The same thing applies here.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 23/11/2023 02:40, James Fan wrote:
Hi Alan and Gerald, Thanks for your answer. My problem was if I set a user attribute name "vlan_id" which is stored in the radreply table and the radgroupreply table. But they have different values. The client will receive the value for the "vlan_id" in the radgroupreply. But we want to make the radreply attributes a higher priority to overwrite the radgroupreply values for the same attribute. After studying the SQL module, I found a solution that uses multiple instances to separate the queries like below:
sql sql-group { # Do group reply queries } sql sql-user-reply { # Do user reply queries }
So we can run these modules using this order: sql-group-reply.authorize sql-user-reply.authorize
That makes the user attributes overwrite the group attributes and resolves our problem. I wonder if that is the best solution or if you have any good ideas. Thanks.
That is an over complicated solution. As per Alan's previous comments, correct use of the operators in the data will do what you need. Use := when setting VLAN attributes in radreply and use = when setting in radgroupreply. := - set the attribute, removing any other instances. = - set the attribute, only if no existing instance exists. Nick -- Nick Porter
On Nov 22, 2023, at 9:40 PM, James Fan <polysorb@gmail.com> wrote:
My problem was if I set a user attribute name "vlan_id" which is stored in the radreply table and the radgroupreply table. But they have different values. The client will receive the value for the "vlan_id" in the radgroupreply. But we want to make the radreply attributes a higher priority to overwrite the radgroupreply values for the same attribute.
See the wiki. The behavior of the SQL module is extensively documented,
After studying the SQL module,
... or documentation? As Nick said, this is what the operators are for. This is all clearly documented. Alan DeKok.
participants (4)
-
Alan DeKok -
Gerald Vogt -
James Fan -
Nick Porter