mirror of
https://codeberg.org/prof_x_pvt_ltd/captive.whump.shanti-portal
synced 2024-08-14 22:46:42 +00:00
clarifications
This commit is contained in:
parent
735d8a2dac
commit
2ebdc37eae
2 changed files with 35 additions and 17 deletions
48
README.md
48
README.md
|
@ -4,8 +4,7 @@ A basic captive portal stack aiming to do the following.
|
|||
|
||||
- Present a webpage to the user
|
||||
- User submits a form
|
||||
- Plugins are executed with form data
|
||||
- Plugins can deny a user access
|
||||
- Backend evaluates client
|
||||
- User is granted access to whatever treasure the portal is guarding
|
||||
|
||||
This is a commonly seen setup in public Wifi networks or hotspots.
|
||||
|
@ -18,28 +17,52 @@ I've moved all examples from the [old wiki-page](https://wiki.sydit.se/teknik:gu
|
|||
|
||||
# Get started
|
||||
|
||||
Quick steps will setup a locally hosted dev server which will only run the sample_log plugin and log a line to captiveportal.log.
|
||||
|
||||
## Dependencies
|
||||
|
||||
* Requires Python3 for a Postgres data type
|
||||
* Depends on iptables and conntrack
|
||||
* PostgreSQL for keeping track of clients
|
||||
* redis as backend for rq
|
||||
* rq for executing plugins (making firewall rules)
|
||||
|
||||
## Run dev server
|
||||
## Install
|
||||
|
||||
python setup.py install
|
||||
python portal.py
|
||||
|
||||
## Run RQ worker in foreground
|
||||
|
||||
rq worker -u redis://127.0.0.1:6379/
|
||||
|
||||
## Run dev server
|
||||
|
||||
python portal.py
|
||||
|
||||
Now visit the URL shown in the output and you'll be able to submit the portal form, wait for the background job to finish and be redirected to the default website (google.com).
|
||||
|
||||
By default only sample_log plugin is executed which logs a line to captiveportal.log when rq finishes running.
|
||||
|
||||
# Deployment
|
||||
|
||||
See examples in docs/examples directory.
|
||||
See examples in docs/examples directory, along with all the cfg examples in the repo.
|
||||
|
||||
# Technical details
|
||||
|
||||
## Portal server
|
||||
|
||||
First and foremost all traffic in a network must be routed through the server running this software stack.
|
||||
|
||||
* IPtables
|
||||
* Captiveportal portal web app
|
||||
* Associated tools must be setup here
|
||||
|
||||
## Portal web app
|
||||
|
||||
All this is of course triggered by the portal application written in Python using Bottle.
|
||||
|
||||
1. A clients redirected HTTP traffic puts them in the portal webpage.
|
||||
2. They send a POST form to the /approve url. This can be with user info, personal info, or simply an approve button for a EULA.
|
||||
3. The portal executes its plugins in the order that their config section appears in plugins.cfg.
|
||||
4. Each plugin is passed the request object from Bottle which contains form values among other things.
|
||||
|
||||
## IPtables
|
||||
|
||||
At the heart is iptables doing the following.
|
||||
|
@ -50,15 +73,6 @@ At the heart is iptables doing the following.
|
|||
4. Authenticated clients are jumped out of the mangle table before being labeled, using the RETURN target.
|
||||
5. Authenticated clients are also deleted from conntrack after having their exception rules created in the mangle table.
|
||||
|
||||
## Portal
|
||||
|
||||
All this is of course triggered by the portal application written in Python using Bottle.
|
||||
|
||||
1. A clients redirected HTTP traffic puts them in the portal webpage.
|
||||
2. They send a POST form to the /approve url. This can be with user info, personal info, or simply an approve button for a EULA.
|
||||
3. The portal executes its plugins in the order that their config section appears in plugins.cfg.
|
||||
4. Each plugin is passed the request object from Bottle which contains form values among other things.
|
||||
|
||||
## 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.
|
||||
|
|
|
@ -3,3 +3,7 @@
|
|||
These tools deal with clients in IPtables backed by a PostgreSQL database.
|
||||
|
||||
A class is defined in client.py that handles creating and looking up clients.
|
||||
|
||||
## Examples
|
||||
|
||||
See the cfg files for more examples.
|
Loading…
Reference in a new issue