### Expected behavior
To comply with the [User Agent policy](https://meta.wikimedia.org/wiki/User-Agent_policy), clients that cannot set the User-Agent header are "encouraged" to set the Api-User-Agent header. To support this, I would like to include the Api-User-Agent header in the JavaScript examples in the API Portal. For example:
```
let response = await fetch( 'https://api.wikimedia.org/core/v1/wikipedia/en/page/Earth',
{
headers: {
'Api-User-Agent': 'APP_NAME (EMAIL_OR_CONTACT_PAGE)',
'Authorization': 'Bearer ACCESS_TOKEN'
}
}
);
response.json()
.then(console.log).catch(console.error)
```
### Observed behavior
The example above gives the error `blocked by CORS policy: Request header field api-user-agent is not allowed by Access-Control-Allow-Headers in preflight response.` This happens with both the `core` and `feed` namespaces.
When I try the example above with the MediaWiki Core REST API, I get the same error. However, when I try with a RESTBase API endpoint (`https://en.wikipedia.org/api/rest_v1/page/title/Earth`), the Api-User-Agent is allowed and the example works.
### Proposal
Allow the Api-User-Agent header in API Gateway requests, similar to {T76340}
Validate the following uses cases for the API Gateway:
#### Using OAuth clients created via Meta
- Owner-only clients (access token only)
- [x] Read
- [x] Write
- OAuth 2.0 client credentials workflow (two-step authentication)
- [x] Read (Works only after admin approval)
- [x] Write
- OAuth 2.0 authorization code workflow (three-step authentication)
- [x] Read (Works with only the creators account prior to approval)
- [x] Write
- [x] Refresh
#### Using OAuth clients created via API Portal
Unblocked following deployment of {T269880} on 1/20
- Owner-only clients (access token only)
- [x] Read
- [x] Write
- OAuth 2.0 client credentials workflow (two-step authentication)
- [x] Read
- [x] Write
- OAuth 2.0 authorization code workflow (three-step authentication)
- [x] Read
- [x] Write
- [x] Refresh
Determine the permissions applied when using the OAuth 2.0 client credentials workflow with the API Gateway using the following test.
### Test
With an OAuth 2.0 client with the client_credentials grant type and the ability to edit pages, created within the past month, edit a page and see what is listed as the editor.
```
curl -X POST-F 'grant_type=client_credentials' -F 'client_id=MY_CLIENT_ID' -F 'client_secret=MY_CLIENT_SECRET' https://meta.wikimedia.org/w/rest.php/oauth2/access_token
curl -X PUT https://api.wikimedia.org/core/v1/mediawiki/page/User%3AAPaskulin_%28WMF%29%2FSandbox%2Ftest -H "Content-Type: application/json" -H "Authorization: Bearer MY_ACCESS_TOKEN" --data '{"source": "Hello, world!", "comment": "Testing out OAuth client credentials flow for docs", "latest": { "id": LATEST_REVISION_ID }}'
```
### Expected behavior
This command works when using an access token from an owner-only OAuth client created before the implementation of the API Gateway.
```
$ curl -X PUT https://www.mediawiki.org/w/rest.php/v1/page/User%3AAPaskulin_%28WMF%29%2FSandbox%2Ftest -H "Content-Type: application/json" -H "Authorization: Bearer TOKEN_FROM_OLD_CLIENT" --data '{"source": "Hello, world!", "comment": "Testing out OAuth client credentials flow for docs", "latest": { "id": LATEST_REVISION_ID }}'
{"id":1007752,"title":"User:APaskulin (WMF)/Sandbox/test","key":"User:APaskulin_(WMF)/Sandbox/test","latest":{"id":4238318,"timestamp":"2020-11-17T02:15:24Z"},"license":{"url":"//creativecommons.org/licenses/by-sa/3.0/","title":"Creative Commons Attribution-Share Alike 3.0"},"content_model":"wikitext","source":"Hello, world!"}
```
### Observed behavior
With an access token from an owner-only client created following the implementation of the API Gateway, I get this error, both on the Core REST API and the API Gateway. Since this is an owner-only client tied to my Wikimedia account, it would make sense for MediaWiki to consider the request as belonging to the Users group, as it does in the expected example. However, this could also be the intended behavior based on the policy. Please advise!
```
$ curl -X PUT https://www.mediawiki.org/w/rest.php/v1/page/User%3AAPaskulin_%28WMF%29%2FSandbox%2Ftest -H "Content-Type: application/json" -H "Authorization: Bearer TOKEN_FROM_NEW_CLIENT" --data '{"source": "Hello, world!", "comment": "Testing out OAuth client credentials flow for docs", "latest": { "id": LATEST_REVISION_ID }}'
{"actionModuleErrorCode":"permissiondenied","messageTranslations":{"en":"The action you have requested is limited to users in one of the groups: *, [[Project:Users|Users]]."},"httpCode":400,"httpReason":"Bad Request"}
$ curl -X PUT https://api.wikimedia.org/core/v1/mediawiki/page/User%3AAPaskulin_%28WMF%29%2FSandbox%2Ftest -H "Content-Type: application/json" -H "Authorization: Bearer TOKEN_FROM_NEW_CLIENT" --data '{"source": "Hello, world!", "comment": "Testing out OAuth client credentials flow for docs", "latest": { "id": LATEST_REVISION_ID }}'
{"actionModuleErrorCode":"permissiondenied","messageTranslations":{"en":"The action you have requested is limited to users in one of the groups: *, [[Project:Users|Users]]."},"httpCode":400,"httpReason":"Bad Request"}
```
### Expected behavior
1. Clients created via the experimental create client endpoint do not share client secrets.
2. Resetting the client secret changes the value.
### Observed behavior
1. At least four of clients I created via the endpoint have the same client secret.
2. Resetting the secret does not change the value.
### Expected behavior
After creating an owner-only client ("Bot account") or after resetting the secret for an owner-only client, the confirmation dialog includes the client ID, client secret, and "Access token"
### Observed behavior
Access token is missing from confirmation dialog
{F32370409}
Code: https://github.com/wikimedia/mediawiki-extensions-OAuth/blob/master/src/Rest/Handler/RequestClient.php#L87-L95
To do: Have the parameter validation accept an array of values
#### To do
* [ ] Create and style an [endpoint reference page](https://api.wikimedia.org/wiki/API_reference/Core_API/Search/Search_pages), get feedback on styles, and iterate
* [ ] Create and style an [object reference page](https://api.wikimedia.org/wiki/API_reference/Core_API/Search/Search_result_object), get feedback on styles, and iterate
* [ ] Address any issues
* [ ] Use on-wiki templates and styles to simplify the implementation of these styles across all reference docs
#### Issues to address
* In the Responses table, expanding the example causes the columns widths to re-size very slightly. It's not a major issue, but I'd prefer if this didn't happen.
* {T263083}
### Expected behavior
The position of the content container is consistent regardless of the contents of the page.
### Observed behavior
Code samples with long lines aren't wrapping in the same way that normal text does, causing the main content container to over-expand and get pushed below the sidebar. This example shows two pages at the same screen width. In the page on the left, the code sample is causing the misplacement of the main content container.
{F32353076}
Referenced pages:
* https://api.wikimedia.org/wiki/API_reference/Core_API/Search/Search_result_object
* https://api.wikimedia.org/wiki/API_reference/Core_API/Search/Search_pages
#### Expected behavior
Wikimedia logo favicon appears on api.wikimedia.org wiki pages similarly to [[ https://api.wikimedia.beta.wmflabs.org/static/favicon/wmf.ico | api.wikimedia.beta.wmflabs.org
]]
#### Observed behavior
Generic favicon appears on api.wikimedia.org. https://api.wikimedia.org/static/favicon/wmf.ico returns a 404 (maybe a routing thing?)
Deploy the WikimediaApiPortalOAuth extension to the API Portal production site
[x] Add the new extension submodule to the git mediawiki/extensions repo https://gerrit.wikimedia.org/r/c/mediawiki/extensions/+/589906
[x] Code Review.
[x] Security Review T254947
[x] Performance review T254950
[x] Move extension CI config to wikimedia-deployed section https://gerrit.wikimedia.org/r/c/integration/config/+/644302/
[x] Add extension to the make-wmf-branch release tool https://gerrit.wikimedia.org/r/c/mediawiki/tools/release/+/608687
[x] Deploy on beta sites
[x] Add extension to extension-list
[x] Load extension in mediawiki-config
[x] Enable on apiportalwiki https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/644305/
[x] Update https://www.mediawiki.org/wiki/Extension:WikimediaApiPortalOAuth accordingly ("Release status" etc)
[x] Enable experimental endpoints on Extension:OAuth on Meta https://gerrit.wikimedia.org/r/644547
[x] Remove experimental endpoints from beta configs https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/644553
Change the tooltip on the user icon to show the username, making it easier for users to know what user they're logged in with
During private launch, make the main page of the API Portal publicly visible to provide context about the project and give interested users a way to get updates about public launch.
Once the necessary components are deployed to the API Portal beta site, validate the following test cases:
- [x] User with an unconfirmed email address is prompted to confirm their email before they can create a client
- [x] User with a confirmed email address can create a client
- [x] When creating an owner-only client, the form requires a client name, description, and terms agreement.
- [x] After creating an owner-only client, a dialog appears with the client ID, secret, and token.
- [x] When creating a non-owner-only client, the form requires a client name, description, return URL, confidential status, and terms agreement.
- [x] After creating a non-owner-only client, a dialog appears with the client ID and secret.
- [x] Existing OAuth 2.0 clients appear in the client list with their name, created date, and status
- [x] Existing OAuth 1.0 clients do not appear in the client list
- [x] The client details view shows the client ID
- [x] For an owner-only client, the client secret and token can be reset using the reset option
- [x] For a non-owner-only client, the client secret can be reset using the reset option
- [x] Changes in client status are reflected in the Portal
### Issues identified
* {T264110}
* {T264199}
* {T264201}
* {T264202}
* {T264215}
* {T264238}
* {T264240}
* {T264248}
* {T264372}
* {T264371}
* {T264360}
* {T264457}
* {T264628}
* {T264637}
#### Background
I'm not sure what changed in the last few days, but I now see an "English" option in the user dropdown menu on the Beta Site when logged in:
{F32238203}
This pulls up the dialog to select a display language. However, I don't think it's very clear what this option does. In my experience, language switchers aren't usually embedded in dropdown menus.
#### Options
1. Remove this option from the user menu since it is accessible via Preferences (which will be added to the menu)
2. Move the language switcher to a place that makes its function more obvious
3. Rename the option to something like "Set language", "Switch language", or "Language: English". Or use the same language icon used on Vector for language switching.
Thoughts and feedback welcome!
Following the deployment of the API Portal wiki at api.wikimedia.org, configure the wiki to match the configuration used in api.wikimedia.beta.wmflabs.org with the addition of the extra config needed for private launch:
```
$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['user']['read'] = false;
$wgGroupPermissions['docseditor']['read'] = true;
$wgWhitelistRead = [
"Main Page", "Special:UserLogin"
];
```
In addition to the config described above, we also need to disable the Collection Extension. (See T260309 for details.)
To do:
- [x] Apply config
- [x] Make APaskulin (WMF) a bureaucrat
- [x] Verify that all users outside the docseditor group can only view the main page and the login page
#### Objectives
* In the API Portal, present developers with an easily understandable set of scopes to choose from when creating clients
* Tailor scopes so that when an app is requesting authorization from a user, the user feels like the scopes being requested are reasonable
* In the API Portal, offer scopes that cover only the functionality provided by API Gateway APIs
* If we need to change the set of offered scopes to account for new APIs added to the gateway, have this happen relatively infrequently so that we don't overwhelm developers with needing to recreate their clients
#### Background
In T249781, we mapped rights to the core REST API endpoints, but I now think that this was based on a mistaken interaction of the relationship between rights as used by the REST handlers and rights as applied to OAuth clients. What we're looking to determine here, is what to include on the API Portal's create client view.
#### Grant mapping
[Grants](https://meta.wikimedia.org/wiki/Special:ListGrants) that map to the functionality provided by the core REST and wikifeeds APIs (APIs for initial gateway launch):
- basic (See question 1)
- highvolume
- editpage (See question 2)
- editprotected
- editmycssjs
- editinterface (See question 3)
- editsiteconfig
- createeditmovepage
- viewdeleted
Grants that do not map to functionality provided by those APIs and do not need to be offer via the Portal:
- editmyoptions
- uploadfile
- uploadeditmovefile
- patrol
- rollback
- blockusers
- viewrestrictedlogs
- delete
- oversight
- protect
- viewmywatchlist
- editmywatchlist
- sendemail
- createaccount
- privateinfo
- mergehistory
- checkuser
- shortenurls
- globalblock
- setglobalaccountstatus
- oath
#### Questions
# Does the basic grant allow page editing?
# Because of the overlap, could we omit editpage in favor of createeditmovepage?
# Because of the overlap, could we omit editinterface in favor of editsiteconfig?
# How do grants correspond to the strings [shown to users in authorization requests](https://gerrit.wikimedia.org/g/mediawiki/core/+/master/languages/i18n/en.json#1334)?
#### Grants to offer in the Portal (pending open questions)
- basic
- createeditmovepage
- viewdeleted
- editprotected
- editmycssjs
- highvolume
- editsiteconfig
To support OAuth clients created via the API Portal, we'll need to consider the rights used by the Core REST API user contributions endpoints.
For example, the PageHistoryCountHandler uses the bot right.
To make the interface more intuitive and easier to translate, change "DevCenter" to "Dashboard". This is a commonly used term in developer portals for an app management console.
Locations to change:
- [x] User menu (When logged in, select the user icon)
- [x] Sidebar (When logged in, select the notifications icon)
Page: https://api.wikimedia.beta.wmflabs.org/wiki/Test_page
Expected behavior: To comply with the [style guide](https://design.wikimedia.org/style-guide/visual-style_typography.html#use-of-styles), border on h2 headings has style `3px solid #eaecf0` with `padding-bottom: 2px;`
{F32187922}
Observed behavior: Border has style `1px solid #a2a9b1` with different padding-bottom
{F32187915}
Page: Narrow-width page while logged in with an unread notification
Expected behavior:
{F32187690}
Observed behavior:
{F32187694}
Pages: All pages when logged in
Expected behavior: When logged in, selecting the user icon brings up a menu that complies with the styles in OOUI ([ButtonMenuSelectWidget (clearOnSelect=false, menu.horizontalPosition="end")](https://doc.wikimedia.org/oojs-ui/master/demos/?page=widgets&theme=wikimediaui&direction=ltr&platform=desktop#ButtonMenuSelectWidget-clearOnSelect-false-menu-horizontalPosition-end))
Observed behavior: User menu uses different styles (background color, font size, font justification, padding, etc). Note that this task is scoped only to the user menu since it's the most important menu for the initial launch. However, if changes all dropdown menu styles is easier, that also works.
Page: All pages when logged in
Expected behavior: Selecting the user icon brings up a menu that includes an option for "Preferences" that links to Special:Preferences, directly above the "Log out" option
Observed behavior: User menu does not include a link to preferences
Enable the [Discussion Tools](https://www.mediawiki.org/wiki/Extension:DiscussionTools) extension on api.wikimedia.beta.wmflabs.org and api.wikimedia.org
Background: The original design with the two horizontal rules was based on the idea that we could use a smaller font size in the buttons. However, since we’re using the button styles defined by OOUI, I think it would be better to remove the horizontal rules and group page options into a [[ https://design.wikimedia.org/style-guide/components/button-groups.html | button group ]], left-aligned with and directly below the title.
#### Documentation pages (for users without edit permissions, both logged in and logged out)
To do:
- [ ] Remove the two horizontal rules and re-locate the Discussion and Updated {DATE} buttons adjacent to each other, directly under the title. (No changes to the Edit source button are needed at this time.)
- [ ] Ensure that logged-out users see the same options as unprivileged, logged-in users
Expected behavior:
{F32186937}
Observed behavior:
{F32186940}
#### History and talk pages
To do:
- [ ] Remove the two horizontal rules and reduce page option buttons on history and talk pages to a single return-to-page button for all users, both privileged and unprivileged. (Since we'll be using StructuredDiscussions, there's no need for talk page history or editing.)
Expected behavior:
{F32186955}
Observed behavior:
{F32186944}
Page: All documentation pages, for example https://api.wikimedia.beta.wmflabs.org/wiki/Test_page
Expected behavior: The border under the selected item in the navigation should be 2px in width
Observed behavior: Border is 3px in width. Note that the position of the border (aligned with the bottom edge of the header) should remain the same.
{F32186930}
The log out page currently displays a set of Wikimedia logos:
{F32186924}
To do: Remove the logos and associated text ("Logging you out from other wikis of the Wikimedia Foundation:"). Alternatively, the styling of the the logos could be fixed to display more clearly and with more context, but considering that mediawiki.org doesn't include this content on its log-out page, I think we're safe to remove it.
To make the icon more logical and less distracting, replace `userTalk` with `speechBubbles` in [WikimediaApiPortalTemplate.php](https://github.com/wikimedia/mediawiki-skins-WikimediaApiPortal/blob/master/src/WikimediaApiPortalTemplate.php#L325)
Page: All pages
Expected behavior: When logged out, the notification icon does not appear in the navigation.
Observed behavior:
{F32113960}
Page: All pages
Expected behavior: Header should maintain a consistent height between screen widths
Observed behavior: Header height doubles around 1270px screen width
{F32088489}
This is also impacting the sidebar at around the same width:
{F32187894}
To do:
- [x] Add a test link to the footer
- [x] Document the process on the extension page on mediawiki.org
Notes:
I tried adding a link to MediaWiki:FooterLinks as suggested by this [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/skins/WikimediaApiPortal/+/refs/heads/master/docs/Installation.md#site-customization | doc ]] but it doesn't seem to have worked
In the API Portal, I intended to use Jayprakash12345's excellent tabbed window gadget (T255483) for code samples. It works by looking for subpages with titles that start with `Sample code:` and uses that to build the tabbed window. Here's an [[ https://www.mediawiki.org/wiki/API:REST_API/Reference#Examples_3 | example ]]. The sidebar feature in the API Portal works by looking for subpages and assembling them into a sidebar. Because of this, code sample subpages will show up in the sidebar when we don't want them to.
To do: Choose a modification to either the sidebar or the gadget that will allow us to both have tabbed code samples and a sidebar that includes only non-code-sample pages
See also: Another requested change to the sidebar: T260310 Allow ordering within the sidebar
The sidebar works by taking all subpages and sub-subpages of a page and ordering them alphabetically. For the Portal, we need the ability to customize the order of pages that appear in the sidebar
Page: Any page
Expected behavior: Header navigation does not include Print/export
To do: Find and implement a way to remove Print/export from the navigation
Page: https://api.wikimedia.beta.wmflabs.org/wiki/Test_page
Expected behavior: To match the [[ https://design.wikimedia.org/style-guide/visual-style_typography.html | style guide ]], subpages in the sidebar should be of font weight 600
Observed behavior: Weight 700
{F32087478}
Note: Screenshot above shows change in both font weight and font family. Font family change is tracked in T260300
Page: https://api.wikimedia.beta.wmflabs.org/wiki/Special:MovePage/Test_page
Expected behavior: I can move the page by entering a new title
Observed behavior: New title text box is missing
{F32087375}
Page: https://api.wikimedia.beta.wmflabs.org/wiki/Test_page
Expected behavior: The [[ https://design.wikimedia.org/style-guide/visual-style_typography.html#use-of-styles | style guide ]] asks for font sizes using "scale-independent pixels (sp)" with paragraph text in 16 sp
Observed behavior: Seeing an error when inspecting the styles: {F32087258}
I'm not sure how to test whether this is actually resulting in the wrong font size, but the error seems worth investigating. Note that this also seems to be happening on headings.
Page: https://api.wikimedia.beta.wmflabs.org/wiki/Test_page
Expected behavior: To comply with the [[ https://design.wikimedia.org/style-guide/visual-style_typography.html | style guide ]], headings should be of font color #202122
Observed behavior: Headings are of font color #000000
Page: https://api.wikimedia.beta.wmflabs.org/wiki/Test_page#Test_h1
Expected behavior: To comply with the [[ https://design.wikimedia.org/style-guide/visual-style_typography.html#use-of-styles | style guide ]], h1 headings should be: `font-family: Charter,Georgia,serif;`
Observed behavior: Font is `font-family: 'Charter Regular',sans-serif;`. Note that is specifically for page titles, which are `<h1 id="firstHeading" class="firstHeading">`
Page: https://api.wikimedia.beta.wmflabs.org/wiki/Reference/Subreference/Nested_item
Expected behavior: To mimic the [[ https://design.wikimedia.org/style-guide/visual-style_typography.html | style guide ]]:
* Unselected sub-subpages should have font color #54595d
* Unselected sub-subpages should have the adjacent line be of color #eaecf0
* On hover, unselected sub-subpages should have background color #f8f9fa
Screenshots from the style guide:
{F32086723}{F32086779}
Observed behavior: Styles do not match
{F32086737}{F32086798}
Page: All pages
Expected behavior: To comply with the [[ https://design.wikimedia.org/style-guide/visual-style_typography.html#typefaces | style guide ]], fonts should be specified as a system font: `font-family: -apple-system,BlinkMacSystemFont,Segoe UI,Roboto,Lato,Helvetica,Arial,sans-serif;`
Observed behavior: Fonts in the Portal are specified as `Lato`
Page: All pages except the main page
Expected behavior: To comply with the [[ https://design.wikimedia.org/style-guide/visual-style.html | style guide ]], the shadow on the border between the header and the body should be being cast onto the header by the body. The style used by the style guide is: `box-shadow:rgba(0, 0, 0, 0.25) 0px 1px 4px 0px;`
Up-close screenshot of the style guide:
{F32086274}
Observed behavior: The shadow is being cast by the header:.
Up-close screenshot of the beta site:
{F32086296}
On the API Portal Beta Site, test the creation of a navigation sidebar using a subpage as shown [[ https://apigateway.wmf.labs.hallowelt.biz/wiki/Use_cases/Case_2 | here ]].
History:
- Attempted creating a [[ https://api.wikimedia.beta.wmflabs.org/wiki/Test_page/1 | subpage ]] normally
- Attempted enabling namespaces with subpages in [[ https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/619339 | 619339 ]], getting error from MediaWiki
References:
- https://github.com/wikimedia/mediawiki-skins-WikimediaApiPortal/blob/master/components/PageNav.mustache
Replace SVG icons with versions that use the standard dark gray used elsewhere on the Portal (#202122)
Page: https://api.wikimedia.beta.wmflabs.org/wiki/Special:Notifications
Expected behavior: Notifications page on mediawiki.org](https://www.mediawiki.org/wiki/Special:Notifications)
Observed behavior: The preferences menu is partially hidden. There's a missing space between the day and the date. And the "Mark as read" button obstructs the line under the date.
Screenshots:
{F31965832}
{F31965838}
{F31965842}
Change search placeholder text and tooltip from "Search Wikimedia API Portal" to "Search"
Screenshot:
{F31963519}
Page: https://api.wikimedia.beta.wmflabs.org/wiki/Main_Page
Expected behavior: When typing a search term, the language setting icon is fully visible.
Observed behavior: When typing a search term, the language setting icon is partially hidden under search bar.
Screenshot:
{F31963507}
To test the behavior of the API Portal when used in combination with global preferences, restrict api.wikimedia.beta.wmflabs.org to use only the WikimediaAPIPortal skin
To support testing the API Portal Beta Site (api.wikimedia.beta.wmflabs.org), enable the new OAuth extension functionality developed in T257982 on meta.wikimedia.beta.wmflabs.org
To enable the permissions scheme for the API Portal defined in T249834, prevent anonymous users from editing any page. While testing, I found that an anonymous user could edit both a talk page and a user page on api.wikimedia.beta.wmflabs.org
To do:
* [x] Fix confirm to restrict anonymous editing on all namespaces of api.wikimedia.beta.wmflabs.org
* [x] Verify fix
Resources:
* [Manual:Preventing_access](https://www.mediawiki.org/wiki/Manual:Preventing_access#Restrict_anonymous_editing)
To support the permissions scheme for the API Portal defined in T249834, it should be possible for Admins and Bureaucrats to promote users to the documentation editors group, giving them the ability to edit documentation on the site. As an admin on api.wikimedia.beta.wmflabs.org, I wasn't able to add a user to the documentation editor group; the documentation editor group is listed under "Groups you cannot change" on Special:UserRights. This could definitely be due to a lack of knowledge on my part, so advice here is very welcome.
To do:
- [x] Merge config fix for api.wikimedia.beta.wmflabs.org to allow Admins and Bureaucrats to add users to the documentation editors group
- [x] Verify fix ([[ https://api.wikimedia.beta.wmflabs.org/w/index.php?title=Reference&type=revision&diff=48&oldid=31 | Tested successfully ]])
To enable the permissions scheme for the API Portal defined in T249834, prevent users in the Users group from editing pages in the User namespace.
To do:
- [x] Add `$wgNamespaceProtection[NS_USER] = [ 'docseditor' ];` to the configuration for api.wikimedia.beta.wmflabs.org
- [x] Confirm that a user in the group Users cannot edit a user page
Test the permissions scheme for the API Portal defined in T249834 under "Suggested config: Launch".
* [x] A user in group `user` can edit a talk page
* [x] A user in group `user` cannot edit regular pages
* [ ] A user in group `user` cannot edit User pages
* [Failed](https://api.wikimedia.beta.wmflabs.org/w/index.php?title=User:Blankuser123&oldid=27): Fix tracked in T259568
* [x] A user in group `docseditor` can edit or create any page
* [ ] Admins and Bureaucrats can assign a user to the documentation editor group
* Failed: Fix tracked in T259569
* [ ] An anonymous user cannot edit any pages
* Failed on both [talk page](https://api.wikimedia.beta.wmflabs.org/w/index.php?title=Talk:Test_page&oldid=28) and [user page](https://api.wikimedia.beta.wmflabs.org/w/index.php?title=User:Blankuser123&oldid=29): Fix tracked in T259657
User story: As a client developer, I want to be able to request a higher rate limit if my app frequently exceeds its rate limit.
To do: Add documentation to the API Portal that tells users under what conditions they could be granted higher rate limit and how to submit a request. Initially, this will likely be an email address.
User story: As a client developer, I want to be able to see the rate limit applied to each of my clients so I can decide whether to request a higher rate limit.
Background: Since the API Gateway support multiple tiers of rate limits, we need to be able to surface rate limits on a per-client basis to developers.
Add unit tests to support the functionality added to the OAuth extension for T257982
Update [[ https://www.mediawiki.org/wiki/Extension:OAuth | Extension:OAuth ]] with documentation for new endpoints added for T257982
### Notes
#### List clients
GET /oauth2/client
Example: `curl -H "Accept: application/json" --cookie "<session cookie value>" <scheme/host/port/scriptpath>/rest.php/oauth2/client?oauth_version=2`
Query param: `oauth_version`, can be `1` or `2`, defaults to `2`
Response example:
```
{
"clients": [
{
"client_key": "xxx",
"name": "TestFromCurl1807",
"version": "1.0",
"email": "admin@example.com",
"callback_url": "http://default.web.mw.localhost:8080/mediawiki/",
"scopes": [
"authonly"
],
"registration": "20200818230806",
"stage": 0,
"oauth_version": 2,
"description": "foo",
"allowed_grants": [
"authorization_code"
],
"registration_formatted": "23:08, 18 August 2020"
}
],
"total": 1
}
```
#### Reset secret
POST /oauth2/client/{client ID}/reset_secret
Example: `curl -H "Accept: application/json" --cookie "<cookie>" -X POST -F reason=<reason> <scheme/host/port/scriptpath>/rest.php/oauth2/client/<client id>/reset_secret`
Response example:
```
{
"name": "TestFromCurl1807",
"client_key": "xxx",
"secret": "xxx"
}
```
#### Create client
POST /oauth2/client
Example: `curl -H "Accept: application/json" --cookie "<cookie>" -X POST -F name=<name> -F description=<description> -F email=<email> -F is_confidential=<0 or 1> -F grant_types=<grant_types> -F scopes=<scopes> -F callback_url=<callback url> <scheme/host/port/scriptpath>/rest.php/oauth2/client`
Response example:
```
{
"name": "TestFromCurl1807",
"client_key": "xxx",
"secret": "xxx"
}
```
Document WikimedaApiPortal skin in the project wiki and on [[ https://www.mediawiki.org/wiki/Skin:WikimediaApiPortal | mediawiki.org ]]
Add unit tests to support the functionality in the WikimediaApiPortal skin
In the API Portal, it would be nice to give users a library to simplify implementation of OAuth 2.0 flows in their apps.
- [ ] Determine whether any of the libraries listed in [[ https://www.mediawiki.org/wiki/OAuth/For_Developers#Libraries | the OAuth docs ]] support OAuth 2.0
- [ ] If not, determine which generic OAuth 2.0 libraries we'd like recommend, if any
** https://opensource.google/projects/appauth
[Parent task]
Add REST endpoints to the OAuth extension that allow users of the API Portal to:
* List their clients and view client details
* Create a client (T251280)
* Reset client secret (T254200)
* ~~Disable an OAuth client~~ (T254200) - deprioritized for now
In addition, add functionality that allows to us enable the endpoints in beta for testing before enabling them in production, via
experimentalRoutes.json.
Deploy [[ https://gerrit.wikimedia.org/g/mediawiki/skins/WikimediaApiPortal | WikimediaApiPortal skin ]] to the [[ https://api.wikimedia.beta.wmflabs.org/wiki/Main_Page | beta site ]]
Assumption: Does not require T246949
This task concerns the agreement text included in the Create App flow within the API Portal.
* [ ] Draft the terms of service for apps created using the API Portal
* [ ] Publish to the Portal
* [ ] Link to the text from the Create App flow
Once the WikimediaApiPortal skin is deployed to the beta cluster, review the design to ensure that everything looks and works as expected.
#### Tasks opened
* {T260195}
* {T254305}
* {T259735}
* {T260303}
* {T260302}
* {T260300}
* {T260299}
* {T259953}
* {T259669}
* {T259666}
* {T260304}
* {T260306}
* {T260307}
* {T260308}
* {T260309}
* {T260310}
* {T260311}
* {T260312}
* {T260313}
* {T260317}
* {T260624}
* {T260618}
* {T260619}
* {T260620}
* {T260623}
* {T260394}
* {T260628}
* {T260630}
* {T260700}
* {T260733}
#### Notes
* ~~**Main page too wide**: The main page extends to the edges of the frame without borders. See T246949#6268555.~~
* This is intentional. The main page is intended to have a custom design that includes its own content borders. See [this example](https://api.wikimedia.beta.wmflabs.org/wiki/Main_Page).
* Missing link to Special:Preferences: Tracked as {T260628}
To allow the API Portal to be available at api.wikimedia.org while the API Gateway endpoints are available at their respective paths, configure Envoy to route requests for the API Portal. All API Portal pages are prefixed with /wiki/.
To do:
Configure a single route for api.wikimedia.org/{prefix} to {hostname}:{port}/{path}, where {prefix} is a namespace that will never conflict with the Gateway, and where {hostname} serves the Portal.
Document the OAuth 2.0 workflows defined in T249776 in the API Portal
- [ ] Information from [[ https://meta.wikimedia.org/wiki/MediaWiki:Mwoauthconsumerregistration-propose-text | MediaWiki:Mwoauthconsumerregistration-propose-text ]] is covered
To support code samples in API reference docs, enable a gadget based on [[ https://www.mediawiki.org/wiki/User:Jayprakash12345/tabbedWindow.js | tabbedWindow.js ]] in the API Portal
Document the versioning and stability policy for the API Gateway on the API Portal
Current API versions:
- Core REST API: v1
- Wikifeeds API: v1 (Stability: unstable)
Original docs: https://en.wikipedia.org/api/rest_v1/#/Feed
To do:
- [ ] Research Wikifeeds API and docs
- [ ] Duplicate docs
- [ ] Reformat as wikitext
- [ ] Add code samples
- [ ] Change URLs to api.wikimedia.org
Notes:
- **Featured endpoint**:
- Original documentation does not appear to be 100% complete based on endpoint responses (For example: type, wikibase_item, and content_urls are missing from the featured endpoint docs but appear in the response)
- The featured endpoint image section seems to be retrieving the featured image from Wikimedia Commons regardless of the image featured on the individual Wikipedia. This section seems to always include the image description in English, even when a description is available in the target language.
- The featured endpoint seems to provide at least mostread and image content for the top 300 Wikipedias. Wikipedia in the [[ https://meta.wikimedia.org/wiki/List_of_Wikipedias#1+_articles | 1+ articles section ]] do not seem to be supported by the featured endpoint.
- **Announcements endpoint**: I wasn't able to find a wiki that returns any announcements via this endpoint. The [[ https://wikimedia.org/api/rest_v1/feed/availability | availability endpoint ]] does not list wiki availability for the announcements endpoint.
- **On this day endpoint**:
- Similar level of completeness in original docs vs. response as the featured endpoint
- Response includes a text blurb and a year accompanied by an array of page objects that represent links relevant to the event
Original docs: https://www.mediawiki.org/wiki/API:REST_API/Reference
To do:
- [ ] Duplicate docs and code samples
- [ ] Change URLs to api.wikimedia.org
- [ ] Remove information specific to MediaWiki (config variables, dependencies, etc.)
@CCicalese_WMF To make it easier to work on the API Portal in parallel with the API Gateway, it would be ideal to be able to launch the API Portal privately (only approved users can read and write) and then move to our MVP permissions configuration once the API Gateway is available.
### Background
The [OAuth extension](https://www.mediawiki.org/wiki/Extension:OAuth) includes an option to allow a user to reset their client secret.
### To do
To support the [API Portal](https://www.mediawiki.org/wiki/Core_Platform_Team/Initiatives/API_Gateway/Documentation_Plan), add a REST endpoint to the OAuth extension that allows a user to reset a client secret from the API Portal.
### Background
The [OAuth extension](https://www.mediawiki.org/wiki/Extension:OAuth) includes an admin-only feature to [[ https://gerrit.wikimedia.org/g/mediawiki/extensions/OAuth/+/47c8907d776d5dd396da4243f108ccc3dc94ccad/src/Control/ConsumerSubmitControl.php#416 | disable a client ]]. Currently, a user can request that their client be disabled through a request to [[ https://meta.wikimedia.org/wiki/Steward_requests/Miscellaneous | Steward_requests/Miscellaneous on Meta ]].
### To do
To support the [API Portal](https://www.mediawiki.org/wiki/Core_Platform_Team/Initiatives/API_Gateway/Documentation_Plan), add a REST endpoint to the OAuth extension that allows a user to disable their own OAuth client.
**Requirements**
- Overview of the implementation and configuration of the API Gateway and rate limiting system
- How to manage rate limits
- How to add and remove APIs from the Gateway
**Implementation strategy**
- Proposed location: [[ https://wikitech.wikimedia.org/wiki/Portal:Wikitech | Wikitech TechOps docs ]]
- Work with engineers to plan, draft, and review docs
Although editing of pages in the API Portal will be restricted, it is possible to allow logged-in users to post to talk pages to ask questions and share feedback. API Portal talk pages would use [[ https://www.mediawiki.org/wiki/Extension:StructuredDiscussions | StructuredDiscussions ]]. As an alternative, we could provide an email alias for feedback and questions.
To do:
- [x] Evaluate the risks and benefits of opening talk pages to editing by logged in users
- [x] Design a navigation method for accessing talk pages based on the Wikimedia style guide. Chameleon handles this via a dropdown menu in top nav bar.
#### Benefits
* Direct feedback channel for users
* Ability for users to see answered questions from other users
#### Risks
* Vandalism
* Yet another communication channel
The original design process for the API Portal did not include the creation of mobile views. However, mobile views have been identified as a requirement for the MVP. The purpose of this task is to investigate the work required to create mobile views based on the current design.
To do:
- [x] Create a prototype for a mobile design based on https://m.mediawiki.org/wiki/Special:MyLanguage/API:REST and the narrow-width version of https://design.wikimedia.org/style-guide/index.html
- See https://zl8v18.axshare.com/#id=r5i7pi&p=index and https://zl8v18.axshare.com/#id=ve5bje&p=wikipedia_api_index
- [x] Get information about the mobile experience in Chameleon from HalloWelt
To do: Finalize the content of the footer for the API Portal to match the WMF site footer
Footer in the prototype:
{F31762582}
WMF site footer:
{F31747113}
#### Content
Image: https://meta.wikimedia.org/wiki/Brand#/media/File:Wikimedia_Foundation_logo_-_horizontal_white.svg
Text: The Wikimedia Foundation, Inc is a nonprofit charitable organization dedicated to encouraging the growth, development and distribution of free, multilingual content, and to providing the full content of these wiki-based projects to the public free of charge.
Contact https://wikimediafoundation.org/about/contact/
About Wikimedia https://wikimediafoundation.org/about/
Wikimedia projects
Wikipedia https://www.wikipedia.org/
Wikibooks https://www.wikibooks.org/
Wikiversity https://www.wikiversity.org/
Wikinews https://www.wikinews.org/
Wiktionary https://www.wiktionary.org/
Wikisource https://www.wikisource.org/
Wikiquote https://www.wikiquote.org/
Wikivoyage https://www.wikivoyage.org/
Wikimedia Commons https://commons.wikimedia.org/
Wikidata https://www.wikidata.org/
Wikispecies https://species.wikimedia.org/
MediaWiki https://www.mediawiki.org/
Movement affiliates
Wikimedia Chapters https://meta.wikimedia.org/wiki/Wikimedia_chapters
Wikimedia Thematic Organizations https://meta.wikimedia.org/wiki/Wikimedia_thematic_organizations
Wikimedia User Groups https://meta.wikimedia.org/wiki/Wikimedia_user_groups
Other
Terms of use https://foundation.wikimedia.org/wiki/Terms_of_Use
Privacy policy https://foundation.wikimedia.org/wiki/Privacy_policy
Disclaimers https://foundation.wikimedia.org/wiki/Wikimedia:General_disclaimer
Accessibility statement https://wikimediafoundation.org/accessibility-statement/
Cookie statement https://foundation.wikimedia.org/wiki/Cookie_statement
Code of conduct https://www.mediawiki.org/wiki/Code_of_Conduct
License text: Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Terms of Use for details.
- "Creative Commons Attribution-ShareAlike License" links to https://creativecommons.org/licenses/by-sa/3.0/
- "Terms of Use" links to https://foundation.wikimedia.org/wiki/Terms_of_Use
The API Portal prototype includes an API usage view where a user can see their historical API usage data.
{F31747076}
Note: Feel free to adjust the list of tasks below. These are just approximations based on my understanding. Possible duplicate of T246275
Mock data format:
```
{
"limit": {
"count": 10000,
"period": 86400,
},
"usage": {
"2020-04-20": 7819,
"2020-04-21": 8090,
"2020-04-22": 7401,
"2020-04-23": 6991,
"2020-04-24": 9118,
"2020-04-25": 4251,
"2020-04-26": 5823
}
}
```
To do:
* [x] Create policy for data collection and retention. Review with relevant parties.
* [] Create a specification for how this data can be retrieved by the API Portal (Requires T246269)
Draft a set of configuration settings to implement the permissions for the API Portal
Requirements:
* Docs-editors group
* Create pages
* Edit pages
* Logged-in users
* Manage app credentials
* Post to talk pages
* Anonymous users
* View pages
References:
* https://www.mediawiki.org/wiki/Manual:$wgNamespaceProtection
---
Suggested additions for pre-launch (WIP): Intended to make content private until launch
```lang=php
$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['user']['read'] = false;
$wgGroupPermissions['docseditor']['read'] = true;
$wgWhitelistRead = [
"Main Page", "Special:UserLogin"
];
```
Suggested config: Launch (WIP)
```lang=php
$wgGroupPermissions['user']['move'] = false;
$wgGroupPermissions['user']['move-subpages'] = false;
$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['user']['createpage'] = false;
$wgGroupPermissions['docseditor']['docseditor'] = true;
$wgGroupPermissions['docseditor']['move'] = true;
$wgGroupPermissions['docseditor']['move-subpages'] = true;
$wgGroupPermissions['docseditor']['edit'] = true;
$wgGroupPermissions['docseditor']['createpage'] = true;
$wgGroupPermissions['sysop']['docseditor'] = true;
$wgGroupPermissions['sysop']['move'] = true;
$wgGroupPermissions['sysop']['move-subpages'] = true;
$wgGroupPermissions['sysop']['edit'] = true;
$wgGroupPermissions['sysop']['createpage'] = true;
$wgGroupPermissions['bureaucrat']['docseditor'] = true;
$wgGroupPermissions['bureaucrat']['move'] = true;
$wgGroupPermissions['bureaucrat']['move-subpages'] = true;
$wgGroupPermissions['bureaucrat']['edit'] = true;
$wgGroupPermissions['bureaucrat']['createpage'] = true;
$wgNamespaceProtection[NS_MAIN] = [ 'docseditor' ];
$wgNamespaceProtection[NS_PROJECT] = [ 'docseditor' ];
// Local uploads are disabled...
$wgNamespaceProtection[NS_FILE] = [ 'docseditor' ];
$wgNamespaceProtection[NS_TEMPLATE] = [ 'docseditor' ];
$wgNamespaceProtection[NS_HELP] = [ 'docseditor' ];
$wgNamespaceProtection[NS_CATEGORY] = [ 'docseditor' ];
```
The app management flow allow users to view, disable, and reset their clients in the API Portal.
Status: Gathering feedback
#### Requirements for app management flow
User stories: [epic 4, stories 3, 5, and 8](https://www.mediawiki.org/wiki/Core_Platform_Team/Initiatives/API_Gateway#Epic_4:_API_Portal)
- List my apps (nice to have: display client ID in list)
- Display app details (name, description, client ID, return URL, rate limit)
- Provide an option to reset a client secret
- Provide an option to disable an app
#### [Prototype](https://zl8v18.axshare.com/#id=uwqv8b&p=my_account_key_manage)
| --- |--- |--- |--- |
|{F31820297} |{F31831947} | {F31820301}|{F31820303}
#### Terminology
**app**
“App” is synonymous with “client”.
**client ID**
A value created when registering a client in the API Portal. A user can access the client ID for their client when logged in to the API Portal.
**client secret**
A value created when registering an app in the API Portal. A client secret is shown to the user once on creation and can only be accessed again by resetting it.
**access token**
A value generated in one of two ways:
* Created by the API Portal when registering a client authorized to act on behalf of a single user (the user creating the client). In this case, the access token has identical rights, roles, and permissions to that user.
* Created by an OAuth Extension API request /oauth/access_token as part of a user-authorization flow
**rate limit**
A rate limit is applied to a client based on client ID. Rate limits can differ between clients, so a user should be able to see the rate limit for each of their clients when logged in to the API Portal.
#### Questions
* ~~Should we include options to update the Public RSA key and allowed IP ranges as shown above?~~
* No, these options aren't included in the Create app flow.
* Meta doesn't currently offer the ability for non-admins to disable clients. ([epic 4, user story 5](https://www.mediawiki.org/wiki/Core_Platform_Team/Initiatives/API_Gateway#Epic_4:_API_Portal))
#### References
Client management options on Meta:
{F31744982}
The create app flow allow users to register a client with the API Portal.
Status: Getting feedback on proposed form
#### [Prototype](https://zl8v18.axshare.com/#id=uwqv8b&p=my_account_key_manage)
|{F31832979}|{F31820301}|
| --- | --- |
#### Prerequisites
* User must be logged in to the API Portal with a Wikimedia account
* User must have the mwoauthproposeconsumer right (Automatically granted to all users)
* User must have a confirmed email address
#### Form fields
All fields are required.
* App name
* App description
* Account type
* Selecting "Developer account" unchecks the owner-only client option and submits "authorization_code", "refresh_token", and "client_credentials" as the grant types
* Selecting "Bot account" checks the owner-only client option and removed the "Return URL" field
* Return URL (only required for developer accounts)
* Permissions
* Read: applies basic, highvolume, viewdeleted, and oversight grants
* Read/Write: applies basic, highvolume, viewdeleted, oversight, and createeditmovepage grants
* "Client is confidential" checkbox
* User agreement checkbox
#### Map between rights used by the MediaWiki REST API and grant types
| Right | Grant Type(s) | Handler(s) |
| --- | --- | --- |
| read | basic | various |
| writeapi | basic | various |
| bot | highvolume | PageHistoryCountHandler |
| deletedhistory | viewdeleted | PageHistoryHandler |
| suppressrevision | oversight | PageHistoryHandler |
| edit | editpage, createeditmovepage, and others | CreationHandler/UpdateHandler |
#### Map between fields on Meta and fields in the API Portal
| Field | Required | Val | DB | Default | API Portal
| --- | --- | --- | --- | --- | --- |
| Name | Yes | name|oarc_name|none|User-entered, required
|Description|Yes|description|oarc_description|none|User-entered, required
|Owner-only client checkbox| |“This consumer is for use only by [Username]” | | |User-entered, required
|Callback URL|Yes|callbackUrl|oarc_callback_url|none|User-entered, not required for owner-only clients
|Confidential checkbox|No|oauth2IsConfidential|oarc_oauth2_is_confidential|Yes|User-entered, required
|OAuth2 Grant Types|No|oauth2GrantTypes|oarc_oauth2_allowed_grants|[“authorization_code”,”refresh_token”]|User-entered, either:auth code flow ( "authorization_code", "refresh_token") or client credentials flow: ("client_credentials")
|Grants|Yes|grants|oarc_grants|(some basic permissions)|User-entered. Read: basic, highvolume, viewdeleted, oversight. Read/Write: basic, highvolume, viewdeleted, oversight, createeditmovepage
|Agreement|Yes|developerAgreement|oarc_developer_agreement|None (user must agree)|User-entered, include as-is
|Email|Yes|email|oarc_email|Wiki email|Omit and revert to default
|Wiki|Yes|wiki|oarc_wiki|*|Omit and revert to default
|Grant Type“Types of grants being requested:”|Yes|granttype|N/A|normal|Omit and default to “Request authorization for specific permissions.”
|Version|Yes|version|oarc_version|1.0|Omit and revert to default
|Allowed IP ranges| | | | | Omit and revert to default
|OAuth version| | | | |Omit, always 2.0
|Callback prefix checkbox|Yes|“Allow consumer to specify a callback in requests and use "callback" URL above as a required prefix.” | | |Omit and revert to checked. Doesn’t apply to OAuth 2.0.
#### References
* https://docs.google.com/drawings/d/1MFA29S_bOqJJ7knPwL61mvkDSjHPD8Vb-nidxyl3t3k/edit?ts=5e8343f1
* https://meta.wikimedia.org/wiki/Special:OAuthConsumerRegistration/propose
* https://www.mediawiki.org/wiki/Extension:OAuth#User_rights
* https://meta.wikimedia.org/wiki/Special:ListGroupRights
To do: Review prototype with stakeholders and finalize
* Log in: https://zl8v18.axshare.com/#id=ep1qc7&p=log_in
* Create account: https://zl8v18.axshare.com/#id=7mvzpi&p=create_account
This task provides examples of basic workflows for the API Portal.
To do: Review with stakeholders and finalize
#### Anonymous requests (No OAuth flow)
* Read-only
* For evaluation and prototyping
* Anonymous requests have a lower rate limit than requests that use an OAuth flow.
```
# Read requests
GET https://api.wikimedia.org/core/v1/wikipedia/en/page/Earth
# Write requests
# Without OAuth or a csrf token, Core REST API returns a 400 error
{
"actionModuleErrorCode": "missingparam",
"messageTranslations": {
"en": "The \"token\" parameter must be set."
},
"httpCode": 400,
"httpReason": "Bad Request"
}
```
#### OAuth 2.0: App authorization (client-credentials workflow, two-legged)
* For use by apps without a user authorization flow, effectively providing anonymous access for the user while including a client ID to support rate limiting.
* Developer creates an OAuth 2.0 client with "refresh_token" and "client_credentials" as the grant types.
* Client requires approval by an admin within 30 days to avoid expiration
```
# Get access token
POST https://meta.wikimedia.org/w/rest.php/oauth/access_token?grant_type=client_credentials&client_id=<client id>&client_secret=<client secret>
# Call API on behalf of app
GET https://api.wikimedia.org/core/v1/wikipedia/en/page/Earth
Authorization: Bearer <access-token>
```
#### OAuth 2.0: User authorization (authorization-code workflow, three-legged)
* For use by apps that make requests on behalf of a user.
* Developer creates an OAuth 2.0 client with "authorization_code", "refresh_token", and "client_credentials" as the grant types.
* Client does not require manual approval to be authorized by the owner's account.
* Client requires approval by an admin within 30 days to be authorized by other users and avoid expiration.
```
# Request authorization from user
https://meta.wikimedia.org/w/rest.php/oauth/authorize?client_id=<client id>&response_type=code
# Get access token
POST https://meta.wikimedia.org/w/rest.php/oauth/access_token?grant_type=authorization_code&code=<authorization code>&client_id=<client id>&client_secret=<client secret>&redirect_uri=<return URL>
# Call API on behalf of user
GET https://api.wikimedia.org/core/v1/wikipedia/en/page/Earth
Authorization: Bearer <access-token>
# Get refresh token
POST https://meta.wikimedia.org/w/rest.php/oauth/access_token?grant_type=refresh_token&refresh_token=<refresh token>
```
#### OAuth 2.0: Owner authorization (access-token-only workflow, single-legged)
* For use by bot accounts.
* Developer logs in to the API Portal with their local-wiki-approved bot account and creates an OAuth 2.0 client with the “This consumer is for use only by [Username]” option applied.
* Client approved automatically upon creation.
```
# Call API on behalf of client owner
GET https://api.wikimedia.org/core/v1/wikipedia/en/page/Earth
Authorization: Bearer <access-token>
```
#### References
* https://www.mediawiki.org/wiki/API:Tokens
* [[https://docs.google.com/document/d/1qe3Z3rvCyO_EfDT4QzE_DCCa0C4_MNKI-5fDkdbGyFg/edit?ts=5e1e192d# | URL mappings doc]]
* https://www.mediawiki.org/wiki/OAuth/For_Developers#OAuth_2
* https://www.mediawiki.org/wiki/API:REST_API/Pages