Changes between Initial Version and Version 1 of Features

Show
Ignore:
Timestamp:
01/05/06 16:28:06 (14 years ago)
Author:
Pascal Leclerc
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Features

    v1 v1  
     1= Wifidog Features List = 
     2 
     3== Realy out of date. To be updated soon ! == 
     4 
     5== Design Goals == 
     6 
     7Wifidog was designed as a replacement to existing captive portal solutions which  
     8we felt didn't fit the needs of next generation community groups. Specifically,  
     9we wanted both personalised and community wide content for each hotspot, no pop  
     10ups, no client software and centralized management. 
     11 
     12=== Features === 
     13 
     14 * Captive portal which lets hotspot owners communicate with their users (custom content management). 
     15 * Wifidog gateway runs on GNU/Linux server and embedded device like the Linksys WRT54G with OpenWRT. 
     16 * Multi-language support : English, French and German. 
     17 * Maintain the connection by checking network activity instead of a javascript window. This allows PDAs and Cellphones to connect. 
     18 * Users are unique and have a valid email address in order to open an account. Their privacy must be respected. You can also use a splash only page and do not ask user to create an account. 
     19 * Users are able to create a working account directly from any hotspot. New users sign on from any hotspot, create their account and are granted access for 15 minutes to confirm an email. If they don't, they are disconnected. 
     20 * Hotspot monitoring by two way heartbeating, so the central server always knows which hotspots are up, regardles of dynamic DNS, firewalls, etc. 
     21 * Firewall has one rule to jump in, one to jump out when a connection is rejected, and one to jump out when a connection is accepted. The gateway must do it's own NAT. All this allows wifidog to be integrated easily into an existing firewall configuration. 
     22 * Statistics : Cumulative bandwidth usage accounting (per connection, per user, per hotspot) 
     23 * Self-identification of the gateways ??? 
     24 
     25Please see roadmap for new features coming out. 
     26 
     27== Detailed features == 
     28 
     29=== Auth server (Current) === 
     30 
     31=== Auth server (Future) === 
     32 
     33=== Gateway (Current) === 
     34 
     35=== Gateway (Future) === 
     36 
     37------ 
     38 
     39The following are the main technical design goals of the project. Detailed feature lists can be found further down. 
     40 
     41=== Implemented === 
     42 
     43Moved on top 
     44 
     45=== Not yet implemented === 
     46 
     47 * User classes 
     48 * Bandwidth limiting per class 
     49 * Bandwidth limiting per router 
     50 * Port blocking per class 
     51 * Apply policies based on time of day  
     52 
     53== Detailed features == 
     54 
     55=== Auth server (Current) === 
     56 
     57 * Node-specific content features. Wifidog-auth has a very cool local content architecture. 
     58   * Every hotspot can have a folder in the local_content directory. This folder can be filed by a single logo, leaving all the rest to be default content, or be completely custom (stylesheet, login page, portal page, header, etc.) 
     59   * Everything in local content is templated with smarty, no problems with web designer wrecking havoc on the auth server. You can edit everything in local_content/default even if you only speak html. 
     60   * RSS feed support (optional, with magpierss), one feed per node (url stored in the database, works great, but no gui to edit it yet) and one network-wide RSS feed.  
     61 * Configuration and integration 
     62   * No need to set any path in the web server config files 
     63   * All paths are editable from the config file 
     64   * Quick setup: the network name, url, default RSS, and similar data are set from the config file, and will be displayed as needed throughout the system. 
     65   * Can import all users and passwords from a ?NoCat passwd file [WWW] More info].  
     66 * Development 
     67   * Demo page to let people to hack on it more easily 
     68   * Database abstraction layer with very nice debugging features (just append true at the end of the call and you'll see the query, the results, the query plan, and the number of affected rows. Porting to another database only requires porting one file. Currently uses Postgres.)  
     69 * User management (end user) 
     70   * Users can create and activate accounts without admin intervention. The user will be granted a 15 minute grace period after signing up in order to retrieve and validate his email. 
     71   * Users can request that the server re-send the validation email 
     72   * Users can change their passwords 
     73   * Users who forget their username can have it mailed to them. 
     74   * Users who lose their password can ask the system to generate a new one and mail it to them. 
     75   * Email must be valid but isn't displayed in order to preserve user privacy. 
     76   * Users can login using either email or username 
     77   * Enforces (politely) that duplicate email addresses are not allowed in the database  
     78 * Logging and monitoring 
     79   * MAC address logging (in case it is a legal requirement in your country) 
     80   * Sends the original url before redirecting to the central server in order to allow linking on the portal page  
     81 
     82=== Auth server (Future) === 
     83 
     84 * (in progress) Internationalization: Most strings are already in gettext calls for easy translation. However language detection and translation work still needs to be done. A French language version should be available soon. 
     85 * (in progress) Script and sql execution time breakdown. Already implemented, just needs to be packaged to be usable by the templates. 
     86 * Merge with the node database project.  
     87 
     88=== Gateway (Current) === 
     89 
     90 * Supports using backup auth servers if the primary one doesn't respond. 
     91 * Runtime query interfac 
     92 * One rule to jump in, one to jump out rejects, one to jump out accepts  
     93 
     94=== Gateway (Future) === 
     95 
     96 * Planned for next release 
     97   * Detect the IP adress of an interface automatically, instead of specifying it separately in the config file. 
     98 
     99=== Sourceforge === 
     100 
     101You can also take a look at Sourceforge [http://sourceforge.net/tracker/?group_id=102646&atid=632427 Feature Requests] page or add your new requests.