Web Services: Player Portal - Revision history

Zehra: Zehra moved page Web Services/Player Portal to Web Services: Player Portal: standardize a layout for pages and content

2025-12-15T04:59:42Z

Zehra moved page Web Services/Player Portal to Web Services: Player Portal: standardize a layout for pages and content

← Older revision		Revision as of 04:59, 15 December 2025
(No difference)

Zehra: /* Server Key Management */ wiki link

2016-12-05T20:21:38Z

Server Key Management: wiki link

← Older revision		Revision as of 20:21, 5 December 2016
Line 55:		Line 55:
	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) 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 [[~~ServerAuthentication~~]] wiki page.		There is more information on the [[Server authentication]] wiki page.

	==Planned Milestones==		==Planned Milestones==

Blast at 22:34, 23 January 2013

2013-01-23T22:34:34Z

← Older revision		Revision as of 22:34, 23 January 2013
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 ~~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.		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 ~~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 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 ~~created~~, it ~~cannot~~ be ~~disabled~~. If the user profile is updated, any associated data in the enabled web services ~~should~~ 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 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.		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. ~~But generally, they~~ are ~~just collections of players. They may be usable~~ by various web services when checking a token generated from weblogin.		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.		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: ~~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~~.		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 ~~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.		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]].		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), ~~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.		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 [[ServerAuthentication]] wiki page.		There is more information on the [[ServerAuthentication]] 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.

	~~This player portal will~~ be ~~used~~ to ~~contain various types~~ of data. It should be ~~determined what data specifically~~, and		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~~ 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~~.		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).

	~~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~~.		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.

	~~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===		===Milestone 2 - Weblogin and Server Authentication===

Blast: /* Design Overview */

2010-08-12T17:30:22Z

Design Overview

← Older revision		Revision as of 17:30, 12 August 2010
Line 11:		Line 11:
	*** Registration		*** Registration
	*** User profile		*** User profile
	*** Enable various other services (forum, wiki, API~~) (?~~)		*** Enable various other services (forum, wiki, API)
	** Weblogin System		** Weblogin System
	** Group management		** Group management

Blast: /* Design Overview */

2010-08-12T17:29:00Z

Design Overview

← Older revision		Revision as of 17:29, 12 August 2010
Line 12:		Line 12:
	*** User profile		*** User profile
	*** Enable various other services (forum, wiki, API) (?)		*** Enable various other services (forum, wiki, API) (?)
			** Weblogin System
	** Group management		** Group management
	*** Create/modify/remove groups		*** Create/modify/remove groups

Blast at 17:24, 12 August 2010

2010-08-12T17:24:50Z

@@ Line 29: / Line 29: @@
 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.
 ===Group Management===
@@ Line 47: / Line 49: @@
 This may differ slightly from the original plan for the [[Group Management System]].
 ===Server Key Management===
@@ Line 54: / Line 55: @@
 There is more information on the [[ServerAuthentication]] wiki page.

Blast: /* Server Key Management */

2010-08-12T16:33:02Z

Server Key Management

← Older revision		Revision as of 16:33, 12 August 2010
Line 51:		Line 51:
	===Server Key Management===		===Server Key Management===

	...		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 [[ServerAuthentication]] wiki page.

Blast: New page: {{DesignDocument}} ==Overview== 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 ...

2010-08-12T13:15:50Z

New page: {{DesignDocument}} ==Overview== 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 ...

New page

{{DesignDocument}}

==Overview==

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.

==Design Overview==

* Player portal
** User management
*** Registration
*** User profile
*** Enable various other services (forum, wiki, API) (?)
** Group management
*** Create/modify/remove groups
*** View where groups are being used (?)
*** View group membership
** Server key management

==Detailed Objective==

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.

===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 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 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 created, it cannot be disabled. If the user profile is updated, any associated data in the enabled web services should be updated as well.

===Group Management===

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.

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: 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 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]].

===Server Key Management===

...