[Feature] Disabled Users in API about django-freeradius

[cappe87]

In my production freeradius I use the same "solution".
We can decide to use this adding is_active and valid_until to RadiusCheck table or try to use a standard solution with radgroupcheck. What do you think about this?

[peppelinux]

Hi Cappe, I developed an is_active and a valid_until attribute in RadiusCheck.
You can find my code in this PR:
#64

We could code the same behaviour for the groups.

ps = I also update the Documentation to let the user modify the behaviour of sql freeradius radcheck query. If valid_until threshold is exceeded or is_valid is false the query will ignore disabled accounts.

[peppelinux]

is_active and valid_until is going to be merged soon, I think (I hope), in radiucheck schema.
I think that is_active and valid_until could be also used in radgroupcheck.

[peppelinux]

Merge done, master branches aligned
we could start creating a new task for CGI if you agree, the focus should be how to disable or expire a group of radcheck entries using radgroupcheck

[nemesifier]

BTW: the best way for the classical users of OpenWISP is to do this is via the RESTful API since they don't have to mess with radius checks and can manage users directly from the users management page.
This will become especially important when multitenancy is added to the mix.

Adding this to the RESTful API is just a matter of few lines of code and we can turn this into a GCI task or let @AlessiaVe handle it if she wants.

[nemesifier]

There: https://github.com/openwisp/django-freeradius/blob/master/django_freeradius/api/views.py#L21

Possible path forward (TDD style):

• write a test that creates a disabled user and tries authenticating it, expecting the authentication to fail, the test will fail because it doesn't seem implemented this way
• just add is_active=True to the queryset
• ensure the test passes
• done!

[peppelinux]

Two cents:

• Shall we consider the opportunity to make some unit test running as freeradius client too? This means that the RadiusServer server should accept the radrequest as client (in client.conf) and should forge a radtest session to the server. This can introduce another feature, the possibility to test a user auth via Django-freeradius admin backed/api/other (django-freeradius->freeradius via auth_backend). I wrote a stupid (very stupid) pure python radius client here:
  https://github.com/peppelinux/pyRadtest

but I think that this is better:
https://github.com/wichert/pyrad

This could also introduce the opportunity to let the user auth via backend throuh radius (django auth_backend)

• BUT the most important thing NOW is to filter all the radiuscheck belonging to a radiusgroupcheck, we can to this with a backend admin custom action -> disable them massively selecting by group. If we decide how to massively disable all the user belonging to a group we can create the GCI task.

[peppelinux]

This issue could reborn with radgroupcheck mass disable feature