MozillaWiki

User:Bhearsum/Balrog/Administration: Difference between revisions

User page Discussion

User:Bhearsum/Balrog/Administration (view source)

Revision as of 19:31, 29 February 2012

3,633 bytes added ,  29 February 2012
m
moved User:Bhearsum/AUS3/Administration to User:Bhearsum/Balrog/Administration
 
(12 intermediate revisions by the same user not shown)
Line 31: Line 31:
* Add, modify, or delete a custom rule
* Add, modify, or delete a custom rule
* Add, modify, or delete a release
* Add, modify, or delete a release
* Add, modify, or delete a permission for a known or unknown user
* View history of changes to rules, releases or permissions
* Rollback to previous versions of a rule, release or permission.


=== UI ===
=== UI ===
TBD
==== Permissions ====
===== permissions.html =====
permissions.html is the entry point for managing user permissions. It...
* Contains a list of all known users (which is to say, all unique usernames in the permissions table), with links to user_permissions.html for each of them.
* Has a form that a new username can be entered into, which redirects to user_permissions.html for the new user upon submission.
 
Because AUS doesn't perform authentication, no details besides username are needed when "creating" a new username.
 
===== user_permissions.html =====
user_permissions.html allows for creation, editing, and deletion of permissions for a specific user. It...
* Lists existing permissions, and allows for deletion or editing of their options.
** Only known options for the permission are listed.
* Allows new permissions to be given to the user
** Only known permissions are listed


= Logging & Rollback =
= Logging & Rollback =
Line 61: Line 77:
* Should the application have write access to this table? If so, how do we prevent accidental (or intentional) removal of history?
* Should the application have write access to this table? If so, how do we prevent accidental (or intentional) removal of history?
* How long should we keep shadow table entries for? A month? A year? Forever? This largely depends on whether we care about having long term history or just the ability to roll back quickly.
* How long should we keep shadow table entries for? A month? A year? Forever? This largely depends on whether we care about having long term history or just the ability to roll back quickly.
= Authentication/Accounts =
<p>Authentication through LDAP will be handled by the web server and passed onto AUS3. AUS3 will maintain a database of usernames and permissions. Permissions will be granted through ACLs. There will be one entry in the ACL for every URL in the API that supports PUT, POST, or DELETE, as well as an entry to allow/disallow user management.</p>
<p>Most humans who use AUS3 will likely have permissions for everything except user management.</p>
<p>Build machines will also have an account they must use, and will only be allowed to make changes to a limited set of things:</p>
* /releases/[name]
** For creating new nightly or release builds
* /releases/[name]/builds/[platform]/[locale] PUT
** For adding details of builds and repacks
** This method can implicitly create required intermediaries, should we grant those too, for clarity?
* /rules/[id] POST
** For updating test channel rules during a release.


= API =
= API =
Line 69: Line 99:
! Method
! Method
! Arguments
! Arguments
! width=40% | Description
! width=30% | Description
! Response status
! Response status
! Response body
! Response body
Line 112: Line 142:
| 200 - Release deleted
| 200 - Release deleted
|
|
|-
| 404 - Release does not exist
| errmsg
|-
|-
| rowspan=2 | /releases/[name]/rollback
| rowspan=2 | /releases/[name]/rollback
Line 121: Line 154:
|-
|-
| 400 - releases_log_id doesn't exist or release name doesn't match
| 400 - releases_log_id doesn't exist or release name doesn't match
| errmsg
|-
| 404 - Release does not exist
| errmsg
| errmsg
|-
|-
Line 151: Line 181:
| rowspan=3 |/releases/[name]/builds/[platform]/[locale]
| rowspan=3 |/releases/[name]/builds/[platform]/[locale]
| rowspan=3 | PUT
| rowspan=3 | PUT
| rowspan=3 | details - the JSON blob associated with this build
| details - the JSON blob associated with this build
| rowspan=3 | Update the build with the supplied JSON data. If any of the named release, platform, or locale don't exist, they will be created. If the specific build already exists, it will be overwritten with the supplied information.
| rowspan=3 | Update the build with the supplied JSON data. If any of the named release, platform, or locale don't exist, they will be created. If the specific build already exists, it will be overwritten with the supplied information.
| 200 - Build modified
| 200 - Build modified
|
|
|-
|-
| product
| 201 - Build created
| 201 - Build created
|
|
|-
|-
| version
| 400 - The details value is malformed or NULL.
| 400 - The details value is malformed or NULL.
| errmsg
| errmsg
Line 234: Line 266:
|-
|-
| 204 - No rules
| 204 - No rules
|
|-
| rowspan=2 | /rules/[id]
| rowspan=2 | GET
| rowspan=2 |
| rowspan=2 | Retrieve the rule
| 200 - Rule returned
| Same as a single entry in /rules GET.
|-
| 404 - Rule does not exist
|
|
|-
|-
Line 246: Line 288:
| errmsg
| errmsg
|-
|-
| rowspan=2 | /rules/[id]
| rowspan=3 | /rules/[id]
| rowspan=2 | POST
| rowspan=3 | POST
| rowspan=2 | Same as /rules POST
| rowspan=3 | Same as /rules POST
| rowspan=2 | Update the rule with any arguments passed. Any missing arguments will not be changed.
| rowspan=3 | Update the rule with any arguments passed. Any missing arguments will not be changed.
| 200 - Rule modified
| 200 - Rule modified
|
|
Line 255: Line 297:
| 400 - One or more of the arguments is invalid
| 400 - One or more of the arguments is invalid
| errmsg
| errmsg
|-
| 404 - Rule does not exist
|
|-
|-
| rowspan=2 | /rules/[id]
| rowspan=2 | /rules/[id]
Line 288: Line 333:
|-
|-
| enddate - Only retrieve rules older than this date/time
| enddate - Only retrieve rules older than this date/time
|-
| rowspan=2 | /users
| rowspan=2 | GET
| rowspan=2 |
| rowspan=2 | Retrieve all users referenced in the Permissions table
| 200 - Usernames returned
| List of usernames in the permission table, in JSON format
|-
| 204 - No usernames found
|
|-
| rowspan=2 | /users/[username]/permissions
| rowspan=2 | GET
| rowspan=2 |
| rowspan=2 | Retrieve all permissions that the named user has.
| 200 - Permissions returned
| List of permissions for the named user, in JSON format.
|-
| 204 - No permissions found
|
|-
| rowspan=2 | /users/[username]/permissions/[permission]
| rowspan=2 | GET
| rowspan=2 |
| rowspan=2 | Retrieve the options for a specific perimssion
| 200 - Options returned
| JSON object whose keys are option names and values are option values.
|-
| 404 - Permission does not exist
|
|-
| rowspan=3 | /users/[username]/permissions/[permission]
| rowspan=3 | PUT
| rowspan=3 | options - a JSON object whose keys are option names and values are option values
| rowspan=3 | Update the permission with the supplied arguments. If it does not exist, it will be created
| 200 - Permission modified
|
|-
| 201 - Permission created
|
|-
| 400 - Options argument is invalid
| errmsg
|-
| rowspan=2 | /users/[username]/permissions/[permission]
| rowspan=2 | DELETE
| rowspan=2 |
| rowspan=2 | Delete the permission
| 200 - Permission deleted
|
|-
| 404 - Permission does not exist
|
|}
|}


= Footnotes =
= Footnotes =
<span id="note1">1. $product-$channel-latest only works in a world where no channel names overlap, which we should be in once 1.9.2 is dead. Doing it this way ensures that we nightly updates work after version bumps happen *and* we don't need to maintain a branch name <-> version mapping a la existing AUS.</span>
<span id="note1">1. $product-$channel-latest only works in a world where no channel names overlap, which we should be in once 1.9.2 is dead. Doing it this way ensures that we nightly updates work after version bumps happen *and* we don't need to maintain a branch name <-> version mapping a la existing AUS.</span>
Bhearsum
canmove, Confirmed users
6,441

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/337152...402581"