Web Services/Player Portal
- 1 Overview
- 2 Design Overview
- 3 Detailed Objective
- 4 Planned Milestones
The Player Portal will consist of user management, group management, and server key management. It will also contain the weblogin page. It may or may not be secured via SSL.
- Player portal
- User management
- User profile
- Enable various other services (forum, wiki, API)
- Weblogin System
- Group management
- Create/modify/remove groups
- View where groups are being used (?)
- View group membership
- Server key management
- User management
This section will detail the expected final product in the ideal implementation. This may, of course, need to change in the future to accommodate limitations.
From this area, new users will be able to register global accounts for use in the game and with the various web services. The registration will require a unique email address, a password, and the first game callsign. Additionally, it needs to handle COPPA for users under the age of 13. Registration will be protected via at least one anti-spam system, such as KeyCAPTCHA, a question, and DNSBLs.
It will be possible to update the user's email, password, and callsigns using the user portal. Some operations, such as changing the email address, will require that the user confirm the request before it will be applied. In the case of changing the email, this will make it less likely that a user will change their email incorrectly and lose access to their account.
It will also be possible to enable other services and have them be tied to this global account. For instance, the user could enable a forum or wiki account. Once an additional service is enabled, it would not be possible to disable. If the user profile is updated, any associated data in the enabled web services will be updated as well.
This area will also contain the weblogin system. Currently we allow users to enable automatic logins for a specific host. However, we do not provide a way to remove this automatic login. Users currently have to manually delete the cookie that we create. In this player portal, the user should be able to control automatic logins and remove them if they wish.
Groups are used primarily for assigning user rights to specific users in-game. They are also used by various web services when checking a token generated from weblogin.
Group names consist of two parts. The format is ORGANIZATION.GROUP with the period separating the two parts. There will be two or three reserved organizations. The DEVELOPERS organization is reserved for official BZFlag developers. The LOCAL organization is reserved for local groups on individual servers. This organization cannot be managed through the web interface. The last one that may be reserved is the BZFLAG organization. However, there is already several groups that are using that namespace, so that would have to be worked out with the owner of those groups.
The organization will be registered first and will then be reserved for use by that user. The user that registers a organization will be the founder of that organization. They can add additional co-founders or even transfer the founder right to another user.
Once an organization is registered, groups can be created within the organization. These will be created by the founder or co-founders. Once created, each group can be assigned one or more managers that will be able to add or remove users from the groups.
There will be various options for each group which the founders can modify. The founders can rename the group, add a description, and delete a group. There will also be a visibility setting and a setting to control how users can join the group.
For the visibility setting, there will be two options: public, protected, and private. If the group is public, anyone can see the group and the member list. If the group is protected, anyone can see the group, but only members can see the member list. If the group is private, only members can see the group and the member list.
There will also be settings to control how users can be added to or removed from the group. For this, there will be three modes: open, request, and closed. If the group is set to open, users can join or leave the group without any interaction from the organization founders or the group managers. The request mode requires users to request to be added to a group, but they can leave or cancel their request at any time. The founders or managers can approve or deny the user's request. The last mode is closed, which allows only the founders or managers to add or remove users from the group.
This may differ slightly from the original plan for the Group Management System.
Server Key Management
Starting with BZFlag 3.0.0 (technically, with 2.99.x) and 2.4.x, a list server key is required to host a server on the official server list. Typically, the owner of the server will generate this key. Keys are tied to a hostname or an IP address. The website will provide management for these keys. A registered user can create new keys and delete existing keys.
There is more information on the Server authentication wiki page.
In order to complete this section of the web services, a number of things need to happen. It is infeasible to complete them all at once, so a gradual process is expected. These milestones will be fleshed out a bit more later.
Milestone 1 - Planning and Design
- Determine the data that will be stored
- Describe any specific restrictions or limitations that should be in place
- Create a complete set of database schema for all areas of the portal
- Determine the kind of queries that will be run and plan indexes and other optimizations as needed.
It should be determined what data needs to be stored, how it references other data, and what kind of data is necessary to integrate with systems such as MediaWiki and phpBB3. There should be some planning for the future to reduce the likelihood/necessity of major database structure changes later. For instance, we should ensure that IPv4 and IPv6 addresses can be stored in any area that tracks IP addresses. PostgreSQL supports storing network addresses, so that may be something to look into. We should also have any restrictions (such as limiting the characters and length of callsigns) clearly defined. This will enable us to create a consistent experience across all web services and in the game itself.
The schema we generate should be database agnostic as it is not yet known what data will be stored in what database. It may be MySQL, OpenLDAP, a mix of the two, or some other database that we have not tried yet (such as PostgreSQL).
We should also determine the types of queries that will be run in order to determine ways to optimize performance. For instance, we will be looking up a specific user by callsign quite often. So it would make sense to have an index on the callsign.
Of course, it's not possible to think of everything right away, so it's inevitable that we will have to make some changes later.
Milestone 2 - Weblogin and Server Authentication
- Migrate the server authentication key system
- Migrate the weblogin system
The easiest thing to migrate over is the server key management system and weblogin. These items are not tied in to many other areas like groups and registration are.
The server key management code is currently in SVN under /trunk/web/listkeymgr. Parts of this code could be adapted or used with the player portal. This will still need to integrate with the existing list server (or vice versa) until the list server is heavily updated or rewritten.
The weblogin system will just be the current weblogin.php script. This may retain the same visual look or we may integrate the look into the rest of the website. A long term goal is to have all our web services have the same visual look.
Milestone 3 - Group Management
- Create the group management system
- Migrate the organizations/groups from the forum into the new group management system
Milestone 4 - Registration
- Create the registration system
- Allow users to modify their profile from the player portal
- Enable activation of a forum account
Milestone 5 - ...