DBMgr uses the bigworldLogOnMapping table (for details, see Entity Tables) to check login's validity and which Proxy to load for the user. It contains the following columns:

To determine whether a login is valid and which Proxy entity to load, DBMgr executes the following steps:

For this step to succeed, the Proxy entity must already exist in the database. For information on how to create an entity and write it to the database, see Reading and Writing Entities.

BigWorld currently does not provide an API for manipulating bigworldLogOnMapping, therefore it is usually populated using MySQL tools. For information on how BigWorld under some circumstances automatically populates this table, see Accepting All Users.

<root>
  <_BigWorldInfo>
    <LogOnMapping>
      <item>
        <logOnName>  John      </logOnName>
        <password>   acde1234  </password>
        <type>       Account   </type>
        <entityName> Achilles  </entityName>
      </item>
      <item>
        <logOnName>  Peter     </logOnName>
        <password>   zyxw9876  </password>
        <type>       Avatar    </type>
        <entityName> Hercules  </entityName>
      </item>
    </LogOnMapping>
  </_BigWorldInfo>
...
</root>

During development, it is often convenient to grant all users access to the server, without having to set up a bigworldLogOnMapping table.

This can be achieved by setting bw.xml file's dbMgr/createUnknown^[20] configuration option to true. With this configuration, a default entity is created for the user if there is no row matching the username in bigworldLogOnMapping.

The type of the entity created is controlled by the bw.xml file's dbMgr/entityType option. Additionally, if dbMgr/rememberUnknown is set to true, then the entity created for the unknown user is saved in the database, and an entry is added in bigworldLogOnMapping. This effectively adds a new user into the system, and subsequent logins by the same user will be processed via the normal login process.

The login processing implemented by the DBMgr is often insufficient for games that require interaction with an external billing system. For this reason, the source code is provided.

Alternatively, to avoid having to modify DBMgr code, user authentication, and Proxy selection can be delegated to an account entity. An account entity is just another BigWorld entity that is implemented using Python script. The DBMgr can be configured to bypass its usual login processing and pass control over to the account entity.

Firstly, the bigworldLogOnMapping table (for details, see Entity Tables) must be emptied.

Then, the following configuration options must be set:

A ‐ For details, see the document Server Operations Guide's section Software Configuration with bw.xml → DBMgr configuration options.

With the above configuration, whenever a user logs in, an account Proxy entity with a name matching the username will be loaded. If there is no account entity matching the username then the login will fail.

After a successful login:

There are a couple of approaches to retrieving the user's password:

It is up to the account entity's implementation to verify the user's password. This is usually done by communicating with a third-party billing system. For details on how to communicate with a non-BigWorld process, see Non-Blocking Socket I/O Using Mercury. If the user's password is invalid, then the Proxy entity can destroy itself to disconnect the client.

If the <dbMgr/createUnknown> ^[21] configuration option is set to true, then a default account entity will be created for any unknown user that logs in. This can be useful ‐ even on production servers ‐ to implement a recruitment feature. The account's Proxy entity can write itself into the database by calling its writeToDB method, effectively adding a new user to the game. Alternatively, the Proxy entity can destroy itself without writing to the database, effectively forgetting that the login ever took place. However, this configuration will leave the server more susceptible to denial-of-service attacks since anyone can cause account entities to be created on the server.

One of the advantages of using the bigworldLogOnMapping table for processing login is to be able to reject invalid logins early in the process. When using an account entity, the user's password is not verified until after the account entity has been created. This makes the server more susceptible to denial-of-service attacks.

By setting <dbMgr/loadUnknown> to false, and updating the typeID and recordName columns of the bigworldLogOnMapping table to refer to an account entity, both methods can be combined. The password column can also be set to something other than the user's password. For example, a CD key can be used. Then an account entity will only be created if the user has a valid CD key. Once the account entity is created, the user's password can be verified.