Changes between Initial Version and Version 1 of doc/developer/WiFiDogProtocol_V1

06/25/07 14:20:50 (15 years ago)

Merge wifidog protocol v1 docs in a single page


  • doc/developer/WiFiDogProtocol_V1

    v1 v1  
     2Main contributors: Benoit Grégoire, datamile. 
     3Last modified: 2007-06-25 
     4= Gateway heardbeating (Ping Protocol) = 
     6Wifidog uses the ping protocol as a heartbeat mechanism to send current status information to the auth server. This enables central logging of the status for each node at the auth server. 
     8The wifidog client uses a setting in the conf file to periodically start a thread ( ping_thread.c ) to send a status message via http to the auth server. The message format is 
     20With the data gathered via system calls on the wifidog client. 
     25"User-Agent: WiFiDog %s\r\n"  
     26"Host: %s\r\n"  
     30A typical HTTP request would be: 
     32GET /ping/?gw_id=001217DA42D2&sys_uptime=742725&sys_memfree=2604&sys_load=0.03&wifidog_uptime=3861 HTTP/1.0 
     33User-Agent: WiFiDog 1.1.3_beta6 
     37To this the auth server is expected to respond with an http message containing the word "Pong". 
     39= Auth server authentication protocol = 
     41This page describes the messaging between the wifidog gateway and auth server to validade a user, and ongoing once the user is validated and permitted access to the internet.  
     43Periodically the wifidog client will start a thread to report the status of each user connection. Currently this is used to reporting incoming/outgoing counters for each user, to show that the user is still connected, and to allow the auth server to trigger disconnects of users the should no longuer have access. 
     45The following message is sent for each connected user 
     56Note:  stage= counters or login, depending if this is a new client or not. 
     58In response the auth server will respond with a valid status, and a new user message, or an auth server error. 
     60The format of the response should be: 
     63Auth: <number from user status list> 
     66The new user status can be: 
     690 - AUTH_DENIED - User firewall users are deleted and the user removed. 
     706 - AUTH_VALIDATION_FAILED - User email validation timeout has occured and user/firewall is deleted 
     711 - AUTH_ALLOWED - User was valid, add firewall rules if not present 
     725 - AUTH_VALIDATION - Permit user access to email to get validation email under default rules 
     73-1 - AUTH_ERROR - An error occurred during the validation process 
     77Note:  auth server errors do not currently change firewall or user status. 
     79Typical URLs would be:   
     81GET /auth/?stage=counters&ip= HTTP/1.0 
     82User-Agent: WiFiDog 1.1.3_beta6 
     86= Browser redirects by the gateway = 
     87The client browser is going to be redirected to another page in different circumstances: 
     88== On the initial request: == 
     89Upon capture, the client will be redirected to the following URL by the gateway: 
     90 * login?gw_address=%s&gw_port=%d&gw_id=%s&url=%s 
     91== After the initial request == 
     92Once the login request is processed and client has been redirected to the gateway (stage=login) 
     94If server returned AUTH_DENIED: 
     95Note that you will normally never see that one in the standard auth server.  The client won't be redirected back to the gateway. 
     96 * gw_message.php?message=denied 
     98If server returned AUTH_VALIDATION: 
     99 * gw_message.php?message=activate 
     101If server returned AUTH_ALLOWED: 
     102This is the portal redirect 
     103 * portal/?gw_id=%s 
     105If server returned AUTH_VALIDATION_FAILED: 
     106Note that you will normally never see that one in the standard auth server.  The client won't be redirected back to the gateway. 
     107 * gw_message.php?message=failed_validation