Users accounts API initially inspired by Stormpath.
See http://docs.stormpath.com/rest/product-guide/#application-accounts when in doubt about a parameter.
All users data used to be stored in Stormpath a while back. With Stormpath rolling out after being acquired, we migrated our user accounts to ganomede-directory (our own solution). During the migration period, there were users in both user directories, the server includes some logic to make this possible.
With the stormpath API being discontinued, we removed the code that makes use of it. As a side effect, the server still allows multiple user accounts backends to be used, but effectively it only supports a single one: ganomede-directory.
Link with the ganomede-directory service:
DIRECTORY_PORT_8000_TCP_[ADDR|PORT|PROTOCOL]
- IP|port|protocol of the directory serviceLink with a central and local usermeta services. Note that central metadata are shared across multiple apps, while local metadata are only used by this game server.
CENTRAL_USERMETA_PORT_8000_TCP_[ADDR|PORT|PROTOCOL]
- IP|port|protocol of the central usermeta serviceLOCAL_USERMETA_PORT_8000_TCP_[ADDR|PORT|PROTOCOL]
- IP|port|protocol of the local usermeta serviceLink with the events service, used to send notification when a user logs in, registers a new account, changes their profile or block another user.
EVENTS_PORT_8000_TCP_[ADDR|PORT|PROTOCOL]
- IP|port|protocol of the events serviceLink with the facebook API.
FACEBOOK_APP_ID
- Id of the Facebook applicationFACEBOOK_APP_SECRET
- Secret of the Facebook applicationLink with apple (for Sign In with Apple).
IOS_BUNDLE_ID
- The bundle identifier of the ios application.Config:
LEGACY_ERROR_CODES
- Use stormpath compatible error codes.LOG_LEVEL
- See bunyan levels (default: info)AUDIT_REQUESTS
- Set to force
to audit all requests.Mailer options
ADMIN_EMAIL
- Email to send user deletion requests toMAILER_SEND_FROM
- Sender of emailsMAILER_SEND_SUBJECT
- Subject of password reset emailMAILER_SEND_TEXT
- Plain text of password reset emailMAILER_SEND_HTML
- HTML text of password reset emailENABLE_OTP_CONFIRMATION
- Set tot true
to enable OTP confirmation emailsMAILER_SEND_CONFIRMATION_SUBJECT
- Subject of email address OTP confirmation emailMAILER_SEND_CONFIRMATION_TEXT
- Plain text of email address OTP confirmation emailMAILER_SEND_CONFIRMATION_HTML
- HTML text of email address OTP confirmation emailMAILER_PORT
- the port to connect to (defaults to 25 or 465)MAILER_HOST
- the hostname or IP address to connect to (defaults to 'localhost')MAILER_SECURE
- connection should use SSL (if true
) or not (if false
)MAILER_AUTH_USER
- username to use when connecting to smtp serverMAILER_AUTH_PASS
- password to use when connecting to smtp serverMAILER_IGNORE_TLS
- turns off STARTTLS support if trueMAILER_NAME
- optional hostname of the client, used for identifying to the serverMAILER_LOCAL_ADDRESS
- the local interface to bind to for network connectionsMAILER_CONNECTION_TIMEOUT
- how many milliseconds to wait for the connection to establishMAILER_GREETING_TIMEOUT
- how many milliseconds to wait for the greeting after connection is establishedMAILER_SOCKET_TIMEOUT
- how many milliseconds of inactivity to allowMAILER_DEBUG
- set to true, then logs SMTP traffic, otherwise logs only transaction eventsMAILER_AUTH_METHOD
- defines preferred authentication method, eg. 'PLAIN'NO_EMAIL_DOMAIN
- fake domain to use for users without an email address (default "email-not-provided.local")GUEST_EMAIL_DOMAIN
- domain used for guest users email address (default none)CONFIRM_EMAIL_FOR_APP_VERSION
- only require email confirmation for app version satisfying the given condition (app should sent it with the X-App-Version header). Example ">=1.0.0" (see https://github.com/npm/node-semver)Statsd options (used for monitoring).
STATSD_HOST
- host that runs the statsd serverSTATSD_PORT
- port to connect to statsd serverSTATSD_PREFIX
- prefix for data stored in stats (default to ganomede.users.
)Create a user account.
If the email address isn't a guest email address, an email message containing the email confirmation OTP will be sent to the user. However, if the environment variable CONFIRM_EMAIL_FOR_APP_VERSION
is defined, the server will only send this email if the client version is greater than the defined value. The client is expected to send its version in the X-App-Version
header. When no version is defined by the user, no confirmation email is sent.
{
"username": "tk421",
"email": "tk421@stormpath.com",
"password": "Changeme1",
"metadata": {
"newsletter": "false",
"location": "Dublin, Ireland",
"country": "fr",
"birth": "1991"
}
}
{
token: 'rAnDoM'
}
{
"facebookToken": "AccessTokenFromFacebook",
"username": "tk421"
}
{
"token": "rAnDoM"
}
{
"username": "tk421"
}
Create an authentication token.
{
"username": "tk421",
"password": "0000"
}
Note, tag instead of username also work (this allows mispellings).
{
"facebookToken": "AccessTokenFromFacebook"
}
{
"appleId": "123132.312312.312",
"appleIdentityToken": "Base64Encoded IdentityToken from Apple",
"appleAuthorizationCode": "Authorization Code from Apple"
}
Optionally, you can also include the user email
, givenName
and surname
. An username
and password
to use
if the user doesn't exists, so it can be registered automatically.
{
"token": "0123456789abcdef012345"
}
username
will also be included in the response for Facebook and Apple login.
Custom data associated with users.
Additionnally to the custom metadata you can define, ganomede-users also exposes some predefined virtual metadata:
username
- unique and constant identifier for the username
- unique display name, that might changetag
- tagized(name), see the ganomede tagizeremail
- (only through /auth/*
requests)Users' protected custom data.
{
"key": "some-key",
"value": "..."
}
Change users' custom data.
{
"value": "..."
}
(limited to 200 bytes)
{
"ok": true,
"needEmailConfirmation": false
}
NOTE: When using this endpoint with the email
field, the response will include the needEmailConfirmation
field. This field will be true
if an email has been sent to the user with an OTP
code to confirm their email address. See /users/v1/auth/:authToken/otp/submit
. The same policy is used as with the "POST /account" endpoint, so that only app client newer than a given version will require the confirmation emails (see "Email Confirmation with OTP").
Users' custom data, retrieved using the users tag
.
Searching by tag will match any username
, name
(or similar looking name) the user ever had.
{
"key": "some-key",
"value": "..."
}
List of friends
Retrieve the list of friends
[ "jeko", "sousou", "willy" ]
Add friends to the list.
{"ok":true}
[ "jeko", "sousou", "willy", "harry", "potter" ]
Remove friends from the list.
{"ok":true}
/users/v1/banned-users/
/users/v1/banned-users/:tag [GET]
Returns BanInfo
object describing account standing of :tag
.
{ "username": "alice", // Username
"exists": true, // true if banned, false otherwise
"createdAt": 1476531925454 // timestamp of ban creation, 0 if no ban.
}
/users/v1/banned-users/ [POST]
Ban a user from using the game.
Create an event that indicates that the user has been banned in the "blocked-users" channel.
"USER_REVIEW"
data.action = "BAN"
{
"username": "who-to-ban",
"apiSecret": "process.env.API_SECRET"
}
Ban created successfully.
Invalid or missing API secret.
/users/v1/banned-users/:tag [DELETE]
{ "apiSecret": "process.env.API_SECRET" }
Ban removed successfully or does not exist.
Invalid or missing API secret.
/users/v1/auth/:token/blocked-users
A list of blocked users for user identified by the authentication token :token
.
The list will be stored in the central usermeta, with key $blocked-users
. The value will be an array of strings containing the usernames of blocked users.
For administration purposes, blocked user will also be stored in a ganomede-events
channel (users/v1/blocked-users
). This way, it becomes possible to analyze recently blocked users and generate daily reports.
/users/v1/auth/:token/blocked-users [GET]
Returns the list of blocked users.
[ "bob", "marc" ]
/users/v1/auth/:token/blocked-users [POST]
Adds a user to the "blocked-users" list.
{ "username": "who-to-block" }
Blocked user added successfully, returns the new list of blocked users.
[ "who-to-block", "bob", "marc" ]
User already blocked.
Invalid authentication token.
/users/v1/auth/:token/blocked-users/:tag [DELETE]
Empty.
Blocked user removed successfully or does not exist.
Invalid authentication token.
/users/v1/auth/:token/reported-users
/users/v1/auth/:token/reported-users [POST]
Block the user exactly like the POST blocked-users
endpoint. (cf /users/v1/auth/:token/blocked-users
endpoint above). However, it adds it to the events stream with type set to REPORTED
instead of BLOCKED
.
/users/v1/admin/:api-secret/blocked-users
Endpoint used by administrators to find annoying users.
/users/v1/admin/:api-secret/blocked-users
[GET]You can add a number of filters:
parameter | type | description |
---|---|---|
username |
string[] | comma separated list of users you're interested in |
since |
timestamp | only return users blocked since the provided timestamp |
{
"blocked": [{
"username": "alice",
"total": 2,
"by": [{
"username": "bob",
"createdAt": 1476531925454
}, {
"username": "marco",
"createdAt": 1576531925454
}],
}, {
"username": "bob",
"total": 1,
"by": [{
"username": "harry",
"createdAt": 1376531925454
}],
}]
}
/users/v1/admin/reported-users
A list of the most reported users.
[GET]
Returns the list of recently reported users.
parameter | type | description |
---|---|---|
secret |
string | API_SECRET , passed as ?secret=xxxx |
[
{ target: 'user1', total: 10 },
{ target: 'user2', total: 8 }
]
/users/v1/admin/blocks
/users/v1/admin/blocks/:username
[GET]username
is the ID of the user we're interested in.
parameter | type | description |
---|---|---|
secret |
string | Passed as ?secret=xxxx |
{
"blockedBy": [{
"username": "bob",
"on": 1476531925454
}, {
"username": "marco",
"on": 1576531925454
}],
"reportedBy": [{
"username": "harry",
"on": 1376531925457
}],
"reports": [{
"username": "polo",
"on": 1526531925451
}],
"blocks": [{
"username": "roger",
"on": 1546531925452
}, {
"username": "albert",
"on": 1146531925453
}]
}
blockedBy
: the BLOCKED
events targeting this user.reportedBy
: the REPORTED
events targeting this user.blocks
: the BLOCKED
events from this user.reports
: the REPORTED
events from this user.Users' protected custom data. :keys
is a comma separated list of keys to retrieve.
[{
"key": "some-key",
"value": "..."
}, {
"key": "some-other-key",
"value": "..."
}]
Retrieve multiple users' custom data, using the users userId
.
Retrieve publicly available metadata. Both, :userIds
and :keys
are comma-separated list. Attach secret query string param to retrieve fields up to internal.
Missing or unknown keys, and those you are not allowed to read will be omitted (as opposed to returning an HTTP error).
[{
"username": "alice",
"key": "location",
"value": "..."
}, {
"username": "bob",
"key": "lastseen",
"value": "..."
}]
If the key doesn't exist or cannot be accessed, it will be omitted from the result.
A confirmation email is sent:
The email contains a TOTP access code that can be submitted to this endpoint for validation.
A user metadata with key $confirmedemails
contains the confirmation time of each email confirmed, like this:
{"alice@test.com",12334235492,"alice2@test.com":12343424242}
{
"accessCode": "234354"
}
The system was able to verify the access code (successfully or not).
{
"ok": true,
"isValid": false
}
ok
is true when the system was able to process the request, however you need to check isValid
to see if the access code was actually a valid one.
If the access code is valid, the email address will be added to $confirmedemails
usermeta.
A user requests an otp to confirm his/her email.
The server sends him/her an email with the otp.
The system replies whether it was able to send the email to the user.
{
"ok": true,
"sent": false
}
ok
is true when the system was able to process the request. Otherwise, ok
is false.
sent
is false when the email wasn't sent for some reason.
Create an event that indicates that the user has been reviewed in the "blocked-users" channel.
"USER_REVIEW"
data.action = "CLEAN"
{
"username": "user1"
}
The system replies whether it was able to send the email to the user.
{
"ok": true
}
ok
is true when the system was able to process the request. Otherwise, ok
is false.