profxadke/captive.whump.shanti-portal
1
0
Fork 0
mirror of https://codeberg.org/prof_x_pvt_ltd/captive.whump.shanti-portal synced 2024-08-14 22:46:42 +00:00
Code Issues Projects Releases Packages Wiki Activity

clarification

Browse source
This commit is contained in:
Stefan Midjich 2017-09-29 16:41:58 +02:00
parent fd8e97c673
commit 33150eed6f
1 changed files with 29 additions and 20 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

49
README.md
View file

@ -15,30 +15,21 @@ This app was specifically written for such a hotspot and as such requires a lot
I've moved all examples from the [aforementioned wiki-page](https://wiki.sydit.se/teknik:guider:networking:captive_portal_med_iptables) to the docs/examples directory.
# Plugins
Plugins are executed when the user clicks through the captive portal form, whether they submit data or just approve an EULA these plugins are executed.
Plugins accept data from the request of the user, as of writing this is only wsgi environ data.
Result of the plugins decide whether the user gets accepted into the portal or not. As such plugins have the potential to do anything from check the users IP against a whitelist to authenticate against a RADIUS server or Active Directory.
Sample plugins prefixed with sample\_ are a good starting point for understanding the plugins.
Plugins can be made mandatory, or skipped by being disabled, see plugins.cfg for more configuration.
## Why plugins, why job queue?
My primary use case for this portal would be with tens of thousands of users so already I imagined that creating firewall rules would be a blocking action.
Also with plugins there are options to connect other authentication methods like LDAP or RADIUS, and even other actions to the portal. All of which are possibly blocking. So plugins and job queues felt like a necessary technology to use. Otherwise this type of portal could be a very simple CGI script that runs a system() command.
# Get started
## Dependencies
* Requires Python3 for a Postgres data type
* Depends on iptables and conntrack
* PostgreSQL for keeping track of clients
* rq for executing plugins (making firewall rules)
## Run dev server
python setup.py install
python portal.py
## RQ worker
## Run RQ worker in foreground
rq worker -u redis://127.0.0.1:6379/
@ -69,11 +60,29 @@ All this is of course triggered by the portal application written in Python usin
## Plugins
Plugins are executed when the user clicks through the captive portal form, whether they submit data or just approve an EULA these plugins are executed.
Plugins accept data from the request of the user, as of writing this is only wsgi environ data.
Result of the plugins decide whether the user gets accepted into the portal or not. As such plugins have the potential to do anything from check the users IP against a whitelist to authenticate against a RADIUS server or Active Directory.
Sample plugins prefixed with sample\_ are a good starting point for understanding the plugins.
Plugins can be made mandatory, or skipped by being disabled, see plugins.cfg for more configuration.
### Why plugins, why job queue?
My primary use case for this portal would be with tens of thousands of users so already I imagined that creating firewall rules would be a blocking action.
Also with plugins there are options to connect other authentication methods like LDAP or RADIUS, and even other actions to the portal. All of which are possibly blocking. So plugins and job queues felt like a necessary technology to use. Otherwise this type of portal could be a very simple CGI script that runs a system() command.
### Available Plugins
There's only one relevant plugin right now, iptables. But the idea is that you could add RADIUS plugins or other services. The mandatory flag in plugins.cfg decides if a plugin must pass before a client is authenticated. So you can string several plugins together for several actions that must be performed.
Each plugin responds with JSON.
### iptables plugin
#### iptables plugin
1. Executes the ``iptables_cmd`` defined in plugins.cfg, with arguments being the client IP and potentially the client MAC address.
2. Ensures the exit code of ``iptables_cmd`` is 0, if not 0 it sets a failed flag in its JSON response.