Section 3.52. <AuthBy PORTLIMITCHECK>

3.52. <AuthBy PORTLIMITCHECK>

<AuthBy PORTLIMITCHECK> can apply usage limits for arbitrary groups of users. It is implemented in AuthPORTLIMITCHECK.pm. It requires that you have a <SessionDatabase SQL> defined in your Radiator configuration.

This module allows you to specify for example that up to 20 ports can be used by a customer with a certain DNIS, or 10 ports in one POP and 20 ports in another. Users can be grouped by any attribute stored in your SQL Session Database.

Furthermore, you can arrange to set the Class attribute for the session depending on bands of port usage. This could allow you to charge different amounts for the first 10 and the second 10 ports, for example, or to have a premium price for excessive port occupancy. (The Class attribute set this way will be sent back by the NAS in all accounting requests for that session. You could then use the value of the Class attribute to tell your billing system how much to charge for the session. The ability to actually charge differently depends on the functions of your billing system.)

This module must be used in conjunction with some other module that actually performs the authentication of the user. PORTLIMITCHECK should be considered as a pre-check to make sure that the login would be within the port occupancy limits you have specified.

<AuthBy PORTLIMITCHECK> understands also the same parameters as <AuthBy xxxxxx>. For more information, see Section 3.32. <AuthBy xxxxxx>.

3.52.1. CountQuery

This parameter specifies an SQL query that will be used to count the users currently online according to the SQL Session Database. Defaults to “select COUNT(*) from RADONLINE where DNIS=’%{Called-Station-Id}’”. AuthBy PORTLIMITCHECK will compare the results of this query with SessionLimit in order to determine whether the user will be permitted to log in at all.

Tip

You must have a <SessionDatabase SQL> configured into Radiator. The Session Database must be configured to save the columns that you plan to use to group users in your CountQuery. So, if you are using the default CountQuery, your SQL Session Database must be configured to save the Called-Station-Id attribute to the DNIS column, with something like:

<SessionDatabase SQL>
      # We want to save the DNIS as well as the usual things.
      # Requires a different schema to the example RADONLINE provided
      AddQueryinsert into RADONLINE (USERNAME,\
      NASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP,\
      FRAMEDIPADDRESS, NASPORTTYPE, SERVICETYPE, DNIS) \
      values (%0, '%N',\
      %{NAS-Port}, '%{Acct-Session-Id}', %{Timestamp},\
      '%{Framed-IP-Address}', '%{NAS-Port-Type}', \
      '%{Service-Type}', '%{Called-Station-Id}')
</SessionDatabase>

3.52.2. SessionLimit

This parameter specifies the absolute upper limit to the number of current logins permitted to this group of users. Defaults to 0. For example if SessionLimit is set to 10, then up to 10 concurrent sessions are permitted. If an 11th user attempts to log in through this AuthBy, they will be rejected. If LimitQuery is defined, and if it successfully gets an integer from the database, then the result of the query will be used instead of Session- Limit. SessionLimit may contain special formatting characters.

# They have paid for 20 ports
SessionLimit20

3.52.3. ClassForSessionLimit

This optional parameter allows you to set up different charging bands for different levels of port occupancy in this group of users. You can have one or more ClassForSession- Limit lines. If the current level of port usage is below a ClassForSessionLimit, then the class name will be applied as a Class attribute to that session. Your NAS will then tag all accounting records for that session with the Class attribute. If your billing system records and uses the Class attribute in accounting records, then you could use this to charge differently for different levels of port occupancy.

# The first 2 users will be tagged with a Class of "normal"
# the next 2 with "overflow". No more than 4 concurrent users
# permitted
SessionLimit 4
ClassForSessionLimit normal,2
ClassForSessionLimit overflow,4

3.52.4. LimitQuery

This optional parameter can be used to override the fixed session limit defined by SessionLimit. LimitQuery is an SQL query that is expected to return an integer that will be used as the limit instead of SessionLimit. If LimitQuery fails to execute, or if it does not return any rows, then SessionLimit will be used as the limit instead.

LimitQuery select maxsessions from customers where\ 
            dnis=%{Called-Station-Id}

3.52. <AuthBy PORTLIMITCHECK>

3.52.1. CountQuery

Tip

3.52.2. SessionLimit

3.52.3. ClassForSessionLimit

3.52.4. LimitQuery

3.52.5. IgnoreErrors