Badges

Badges are used to prove to a destination platform that you have reached some objectives in another plaform. This typically allows you to get a specific extra-access to a protected ressource on the destination platform. It is used across many apps, using the “login-module” or not.

Sample workflow

(1) user compete
(1) user compete
(3) login
(3) login
(5) enter "bebras"
participation code
(5) enter "bebras"...
Student
Stude...
(2) participation code:
ABC234
(2) participation code:...
(8) infoXYZ (firstname, lastname,
...)
(8) infoXYZ (firstname, lastname,...
Bebras
Platform
Bebras...
(4) show "login-module" dialog
(4) show "login-module" dialog
Algorea
Algorea
(7) to urlW:
info about code "ABC234"
(7) to urlW:...
login module
login module
(6) login-module knows that "bebras" code are accepted and can be check on urlW (config)
(6) login-module knows that "be...
(9) store ABC234, urlW, infoXYZ
(9) store ABC234, urlW, infoXYZ
(10) callback login:
secret, ABC234 + urlW +
infoXYZ
(10) callback login:...
(11) create user,
store ABC234,
urlW, infoXYZ

(11) create user,...
(12) interprets infoXYZ, as
"add user to group 42"
(12) interprets infoXYZ, as...
Viewer does not support full SVG 1.1

Badge processing by the backend

In practice, for the backend, badges are just interpreted as group memberships, which may give some specific permissions using the usual permission mechanism on the backend. The badges are transmitted from the login-module to the backend via the update of the profile. The aBadges attribute of the profile is an array of badges in the following format:

{
  url: string, // unique identifier of the badge
  badge_info: {
    name: string, // display name of the badge, also used as group name
    group_path: [
      // hierarchy of parent groups with their name, a unique url for each, and whether the user should be manager of those groups as well
      // goes from highest ancestor to direct parent
      { url: string, name: string, manager: bool },
      ...
    ]
  },
  manager: bool, // whether the user should be manager of the group of owners of that badge
  last_update: string, // time (ISO8701 format) of the latest change on this badget
  code: string, // ignored by backend, probably won't be sent anymore
  data: any // ignored by backend, can be anything
}

Each time the profile is updated, the backend must check, for every badge which has changed since the last profile update, if the user belongs to the group specified in the badge. Groups are identified by their url with are stored in groups.text_id. So, for each group:

  • if the group exists, and the user is already member (or manager is manager is true) of it : do nothing
  • if the group exists, and the user is not already member (or manager is manager is true) of it : make him member of the group
  • if the group does not exist, create a group with badge_info.name as name and type “Other”, add it to the group identified by url of the last element from badge_info.group_path. If this later group does not exist, create it (with the given name, and current user managership) and put it the previous group from badge_info.group_path, etc.