profxadke
/
captive.whump.shanti-portal
mirror of https://codeberg.org/prof_x_pvt_ltd/captive.whump.shanti-portal
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
56 Commits 3 Branches 0 Tags 630 KiB
Python 76.7%
JavaScript 13%
Smarty 7.8%
PLpgSQL 1.6%
CSS 0.9%
Go to file
Stefan Midjich c91a969b27 Reworked iptables plugin. 
Now trying to use just one command instead, with two possible arguments.
If arguments are missing ensure that empty strings are passed in with
quotes.
 		2016-12-08 14:57:30 +01:00
docs/examples example configurations. 2016-04-18 21:42:29 +02:00
plugins Reworked iptables plugin. 2016-12-08 14:57:30 +01:00
static url handling and nicer button deactivation 2016-12-08 14:25:37 +01:00
views must use all local static files. 2016-12-07 14:08:43 +01:00
.gitignore changed plugin management to simple rq jobs instead of using pkg_resources. 2016-04-15 19:22:16 +02:00
README.md Merge branch 'master' of ssh+git://github.com/stemid/captiveportal 2016-09-13 09:30:47 +02:00
plugins.cfg Reworked iptables plugin. 2016-12-08 14:57:30 +01:00
portal.cfg dynamically specify name of index page. 2016-04-27 17:05:23 +02:00
portal.py fixed error handling for failed plugin import. 2016-12-07 14:52:58 +01:00
requirements.txt confused about how to use requirements.txt along with setup.py dependencies. 2016-04-16 16:49:24 +02:00
setup.py added sh for iptables dependency. 2016-04-16 16:49:39 +02:00

README.md

Captive Portal

Captive portal webpage written with simplicity in mind.

  • Present a webpage to the user
  • User submits a form
  • Plugins are executed with form data
  • User is granted access to whatever treasure the portal is guarding

This is a commonly seen setup in public Wifi networks or hotspots.

This app was specifically written for such a hotspot and as such requires a lot of other configuration around it. This is an ongoing documentation project here.

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

python setup.py install
python portal.py

RQ worker

rq worker -u redis://127.0.0.1:6379/

Deployment

See examples in docs/examples directory.