Version 3 (modified by gbastien, 9 years ago)

Added some thoughts on how the api would work

Created by Sylvain Carle, updated by Geneviève Bastien

Wifidog API

This page is used to define what data is exposed from the Auth Server thru and API for the purpose of using an independent CMS for the portal pages available to users.

What

* UserInfo?

* HotSpotInfo?

* NetworkInfo?

How

This is open for discussion and are only thoughts by gbastien

Following on some other discussions on the wiki (doc/developer/WiFiDog_V2 and doc/developer/WiFiDogProtocol_V2)

The data should be requested and passed in standard ways, using a RESTful web service.

The request would be a simple http GET with the query string containing all necessary information to return the data.

Here are the possible parameters

Parameter Possible valuesDescription
actionget,list What kind of action is requested from the service
object_classuser, node, network What kind of data is requested
object_id The object id of the object whose details are being requested
fields The fields to return
f (optional default:json)json,xml The format of the response (only json would be implemented for now)
v (optional default:1.0)1.0 The version of the web service protocol (to be forward compatible, just in case)

A typical request would look like this

/ws/index.php?action=list&object_class=Node&&fields=name,connectedusers&f=json&v=1.0

The response would be in the form of a json string. The advantages of json are discussed at other places on this wiki (). The response would look something like this:

{
    {
        "name":"hotspot1name",
        "connectedusers":
         { 
             "user1": 
             {
                 "name":"user1name"
                 "url":"user1url"
             }
             "user2":
             {
                  "name":"user2name",
                  "url":"user2url"
             }
         }
    },
    {
         "name":"network2name",
         ...
    }
}

Some thoughts to keep in mind

While in the beginning, the purpose of this web service is to expose some data to CMS servers that will make use of it, we must keep in mind that we're opening another door on the auth server. No data must pass through this door that wouldn't be publicly available anyway from the auth server.

As for more sensitive data that would usually require a certain level of permission, since there would be no session with this web service, we'd need a scheme to pass authentication data to the request that cannot be overheard. SSL would be necessary for that, as some personal authentication data like a password or hash would be passed along the way.