This wiki is archived and useful information is being migrated to the main bzflag.org website

Editing Web Services/Player Portal

Jump to: navigation, search

Warning: The database has been locked for maintenance, so you will not be able to save your edits right now. You may wish to copy and paste your text into a text file and save it for later.

The administrator who locked it offered this explanation: Archived wiki

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 25: Line 25:
 
===User Management===
 
===User Management===
  
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.
+
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 callsign, a password, an email address, and it needs to handle COPPA. Registration will be protected via at least one anti-spam system, such as reCAPTCHA or a question.
  
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 be possible to update the user's callsign, password, email and additional information such as IM contacts, website URL from the user profile. 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.
+
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 created, it cannot be disabled. If the user profile is updated, any associated data in the enabled web services should 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.
 
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.
Line 35: Line 35:
 
===Group Management===
 
===Group Management===
  
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.
+
Groups are used primarily for assigning user rights to specific users in-game. But generally, they are just collections of players. They may be usable 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.
 
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.
Line 45: Line 45:
 
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.
 
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.
+
For the visibility setting, there will be two options: private, and public. If the group is public, anyone can see the group and view the members. If the group is private, only members can see the group and other members.
  
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.
+
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 remove the group themself without any interaction from the organization founders or the group managers. The request group allows users to request to be added to a group, but they can remove themself or their request at any time. The founders or managers can approve or deny the user's request. The last type 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]].
 
This may differ slightly from the original plan for the [[Group Management System]].
Line 53: Line 53:
 
===Server Key Management===
 
===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.
+
Starting with BZFlag 3.0.0 (technically, with 2.99.x), in order to host a server on the official server list, a key is required. 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.
 
There is more information on the [[Server authentication]] wiki page.
Line 69: Line 69:
 
* Determine the kind of queries that will be run and plan indexes and other optimizations as needed.
 
* 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.
+
This player portal will be used to contain various types of data. It should be determined what data specifically, and  
  
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).
+
This is the time to plan ahead to the future. For instance, ensure that IPv4 and IPv6 addresses can be stored in any area that tracks IP addresses. 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.
  
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.
+
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.
  
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.
+
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.
  
 
===Milestone 2 - Weblogin and Server Authentication===
 
===Milestone 2 - Weblogin and Server Authentication===

Please note that all contributions to BZFlagWiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see BZFlagWiki:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel | Editing help (opens in new window)

Template used on this page: