Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commiteebf5d2

Browse files
committed
Merge remote-tracking branch 'internal/master' into gdp-round-2
2 parents4692629 +7d1c9f7 commiteebf5d2

17 files changed

+266
-105
lines changed

‎content/changes/2014-01-29-audit-org-members-for-2fa.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -11,7 +11,7 @@ We've added a [new filter][filter] for listing members of an organization withou
1111

1212
<preclass="terminal">
1313
$ curl -H "Authorization: token [yours]" \
14-
https://api.github.com/orgs/octokit/members\?filter\=2fa_disabled
14+
https://api.github.com/orgs/[orgname]/members\?filter\=2fa_disabled
1515
</pre>
1616

1717
The new filter is available for owners of organizations with private
Lines changed: 35 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,35 @@
1+
---
2+
kind:change
3+
title:Finer-grained OAuth scopes for SSH keys
4+
created_at:2014-02-24
5+
author_name:pengwynn
6+
---
7+
As[we announced][blog], we've made some important changes to the way that API consumers manage SSH keys.
8+
9+
##Finer-grained OAuth scopes
10+
11+
To help third party applications request only permissions that they need, the API now supports three new[scopes][] for working with a user's public SSH keys.
12+
13+
-`read:public_key` provides read access to the user's SSH keys
14+
-`write:public_key` allows an app to read existing keys and create new ones
15+
-`admin:public_key` enables an app to read, write, and delete keys
16+
17+
##Changes to`user` scope
18+
19+
Historically,`user` scope has provided full access to manage a user's SSH keys. Now that we have dedicated scopes for managing a user's SSH keys, we have removed those permissions from the`user` scope. Now`user` scope will no longer provide access to SSH keys. Applications that need this access should request one of the new scopes described above.
20+
21+
##Keys are now immutable
22+
23+
To simplify the security audit trail for SSH keys, we're making keys immutable. API consumers can continue to create keys and delete keys as needed, but keys can no longer be changed. To change an existing key, API consumers should delete the existing key and create a new one with the desired attributes. This change applies both to a[user's SSH keys][user-keys] and a[repository's deploy keys][deploy-keys].
24+
25+
##Deleting keys when revoking a token
26+
27+
Also any keys created via an OAuth token from this point forward will be deleted when that token is revoked.
28+
29+
As always, if you have any questions or feedback,[please get in touch][contact].
30+
31+
[contact]:https://github.com/contact?form[subject]=API+improvements+for+SSH+keys
32+
[scopes]:/v3/oauth/#scopes
33+
[user-keys]:/v3/users/keys/
34+
[deploy-keys]:/v3/repos/keys/
35+
[blog]:https://github.com/blog/1786-enhanced-oauth-security-for-ssh-keys
Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
---
2+
kind:change
3+
title:OAuth scopes for organization and team resources
4+
created_at:2014-02-25
5+
author_name:pengwynn
6+
---
7+
As a follow up to[the new scopes][yesterday] we announced yesterday, we've
8+
introduced even more OAuth scopes for working with organization and team
9+
resources:
10+
11+
-`read:org` provides read-only access to organizations, teams, and membership.
12+
-`write:org` allows an application to publicize and unpublicize an organization membership.
13+
-`admin:org` enables an application to fully manage organizations, teams, and memberships.
14+
15+
Check out[the full list of OAuth scopes][scopes] supported by the API to
16+
ensure your application asks for only the permissions it needs. As always, if
17+
you have any questions or feedback,[get in touch][contact].
18+
19+
[yesterday]:http://developer.github.com/changes/2014-02-24-finer-grained-scopes-for-ssh-keys/
20+
[scopes]:/v3/oauth/#scopes
21+
[contact]:https://github.com/contact?form[subject]=API+org+scopes
Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
---
2+
kind:change
3+
title:Query enhancements for listing issues and pull requests
4+
created_at:2014-02-28
5+
author_name:pengwynn
6+
---
7+
We've made it even easier to list all[issues][] and[pull requests][] via the API.
8+
The`state` parameter now supports a value of`all` that will return issues and
9+
pull requests regardless of state.
10+
11+
<preclass="terminal">
12+
$ curl https://api.github.com/repos/atom/vim-mode/issues\?state\=all
13+
</pre>
14+
15+
We've also introduced new sorting options for[listing pull requests][pull
16+
requests]. You can now sort pull requests by`created`,`updated`,
17+
`popularity`, and`long-running`.
18+
19+
<preclass="terminal">
20+
$ curl https://api.github.com/repos/rails/rails/pulls\?sort\=long-running\&direction\=desc
21+
</pre>
22+
23+
Happy querying. If you have any questions or feedback[get in touch][contact].
24+
25+
[issues]:/v3/issues/#list-issues
26+
[pull requests]:/v3/pulls/#list-pull-requests
27+
[contact]:https://github.com/contact?form[subject]=API+query+enhancements
Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
---
2+
kind:change
3+
title:New Payload Format for Deployments
4+
created_at:2014-03-03
5+
author_name:atmos
6+
---
7+
8+
As we[iterate on the preview][january-deployment-api-post] for the new Deployment API, we're making sure that it's friendly to work with for the apps built on top of it.
9+
10+
##Deserialize Deployment Payloads
11+
12+
To make the API even easier to use, we'll now return your custom payload as a JSON object along with the rest of the Deployment resource. No need to parse it as JSON again.
13+
14+
##Code You Need to Update
15+
16+
You should only need to remove the JSON parsing if you're taking advantage of the custom payloads. The formats for creating Deployments remain unchanged.
17+
18+
As always, if you have any questions or feedback, please[get in touch][contact].
19+
20+
[january-deployment-api-post]:/changes/2014-01-09-preview-the-new-deployments-api/
21+
[contact]:https://github.com/contact?form[subject]=Deployments+API
Lines changed: 54 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
---
2+
kind: change
3+
title: Improved timezone handling in the API
4+
created_at: 2014-03-04
5+
author_name: dbussink
6+
---
7+
8+
We have improved support for handling timezones in our API. For example, if you
9+
create commits through the API, we now allow for specifying timezone information
10+
more accurately.
11+
12+
We apply the following rules, in order of priority, to determine timezone
13+
information for API calls:
14+
15+
#### Explicitly provide an ISO 8601 timestamp with timezone information
16+
17+
For API calls that allow for a timestamp to be specified, we use that exact
18+
timestamp. An example of this is the [Commits API](/v3/git/commits) which allows
19+
for specifying the `date` property.
20+
21+
<%= json "message"=> "my commit message", \
22+
"author"=> \
23+
{"name" => "Dirkjan Bussink", "email" => "d.bussink@gmail.com", \
24+
"date" => "2014-02-27T15:05:06+01:00"}, \
25+
"parents"=>["7d1b31e74ee336d15cbd21741bc88a537ed063a0"], \
26+
"tree"=>"827efc6d56897b048c772eb4087f854f46256132" %>
27+
28+
#### Using the `Time-Zone` header
29+
30+
It is possible to supply a `Time-Zone` header which defines a timezone according
31+
to the [list of names from the Olson database](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).
32+
33+
$ curl -H "Time-Zone: Europe/Amsterdam" -X POST https://api.github.com/repos/github/linguist/contents/new_file.md
34+
35+
This means that we generate a timestamp for the moment your API call is made in
36+
the timezone this header defines. For example, the [Contents API](/v3/repos/contents/)
37+
generates a git commit for each addition or change and uses the current time
38+
as the timestamp. This header will determine the timezone used for generating
39+
that current timestamp.
40+
41+
#### Using the last known timezone for the user
42+
43+
If no `Time-Zone` header is specified and you make an authenticated call to the
44+
API, we use the last known timezone for the authenticated user. The last know
45+
timezone is updated whenever you browse the GitHub.com website.
46+
47+
#### UTC
48+
49+
If the steps above don't result in any information, we use UTC as the timezone
50+
to create the git commit.
51+
52+
If you have any questions or feedback, don't hesitate to [contact] us!
53+
54+
[contact]: https://github.com/contact?form[subject]=API+timezones
Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
---
2+
kind:change
3+
title:"Reminder: March 12 Cutover Test for Default Media Type"
4+
created_at:2014-03-05
5+
author_name:jasonrudolph
6+
---
7+
8+
In January, we announced an[upcoming change to the default media type][2014-01-announcement]. To help developers assess the impact of that change before it becomes permanent, we're performing a[24-hour cutover test next week][cutover-test-announcement].
9+
10+
From approximately 12:01am UTC to 11:59pm UTC on March 12, the API will[respond with the v3 media type by default][what's-changing]. (See the[start time for the cutover test in your time zone][start-time].)
11+
12+
Follow[@GitHubAPI][] to receive updates before and after the test.
13+
14+
Please see the[original announcement][2014-01-announcement] for full details. If you have any questions, please[get in touch][contact].
15+
16+
[@GitHubAPI]:https://twitter.com/GitHubAPI
17+
[2014-01-announcement]:/changes/2014-01-07-upcoming-change-to-default-media-type/
18+
[contact]:https://github.com/contact?form[subject]=Upcoming+change+to+default+API+media+type
19+
[cutover-test-announcement]:/changes/2014-01-07-upcoming-change-to-default-media-type/#cutover-test
20+
[start-time]:http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140312T00&p1=1440
21+
[what's-changing]:/changes/2014-01-07-upcoming-change-to-default-media-type/#whats-changing

‎content/v3.md‎

Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -571,5 +571,44 @@ A link that looks like this:
571571
["url1", {:rel => "next"}],
572572
["url2", {:rel => "foo",:bar => "baz"}]] %>
573573

574+
##Timezones
575+
576+
Some requests allow for specifying timestamps or generate timestamps with time
577+
zone information. We apply the following rules, in order of priority, to
578+
determine timezone information for API calls.
579+
580+
####Explicitly provide an ISO 8601 timestamp with timezone information
581+
582+
For API calls that allow for a timestamp to be specified, we use that exact
583+
timestamp. An example of this is the[Commits API](/v3/git/commits).
584+
585+
These timestamps look something like`2014-02-27T15:05:06+01:00`. Also see
586+
[this example](http://developer.github.com/v3/git/commits/#example-input) for
587+
how these timestamps can be specified.
588+
589+
####Using the`Time-Zone` header
590+
591+
It is possible to supply a`Time-Zone` header which defines a timezone according
592+
to the[list of names from the Olson database](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).
593+
594+
$ curl -H "Time-Zone: Europe/Amsterdam" -X POST https://api.github.com/repos/github/linguist/contents/new_file.md
595+
596+
This means that we generate a timestamp for the moment your API call is made in
597+
the timezone this header defines. For example, the[Contents API](/v3/repos/contents/)
598+
generates a git commit for each addition or change and uses the current time
599+
as the timestamp. This header will determine the timezone used for generating
600+
that current timestamp.
601+
602+
####Using the last known timezone for the user
603+
604+
If no`Time-Zone` header is specified and you make an authenticated call to the
605+
API, we use the last known timezone for the authenticated user. The last know
606+
timezone is updated whenever you browse the GitHub.com website.
607+
608+
####UTC
609+
610+
If the steps above don't result in any information, we use UTC as the timezone
611+
to create the git commit.
612+
574613
[support]:https://github.com/contact?form[subject]=APIv3
575614
[pagination-guide]:/guides/traversing-with-pagination

‎content/v3/issues.md‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -31,7 +31,7 @@ List all issues for a given organization for the authenticated user:
3131
Name | Type | Description
3232
-----|------|--------------
3333
`filter`|`string`| Indicates which sorts of issues to return. Can be one of:<br/>*`assigned`: Issues assigned to you<br/>*`created`: Issues created by you<br/>*`mentioned`: Issues mentioning you<br/>*`subscribed`: Issues you're subscribed to updates for<br/>*`all`: All issues the authenticated user can see, regardless of participation or creation<br/> Default:`assigned`
34-
`state`|`string`| Indicates the state of the issues to return. Can be either`open`or`closed`. Default:`open`
34+
`state`|`string`| Indicates the state of the issues to return. Can be either`open`,`closed`,or`all`. Default:`open`
3535
`labels`|`string`| A list of comma separated label names. Example:`bug,ui,@high`
3636
`sort`|`string`| What to sort results by. Can be either`created`,`updated`,`comments`. Default:`created`
3737
`direction`|`string`| The direction of the sort. Can be either`asc` or`desc`. Default:`desc`
@@ -51,7 +51,7 @@ Name | Type | Description
5151
Name | Type | Description
5252
-----|------|--------------
5353
`milestone`|`integer` or`string`| If an`integer` is passed, it should refer to a milestone number. If the string`*` is passed, issues with any milestone are accepted. If the string`none` is passed, issues without milestones are returned. Default:`*`
54-
`state`|`string`| Indicates the state of the issues to return. Can be either`open`or`closed`. Default:`open`
54+
`state`|`string`| Indicates the state of the issues to return. Can be either`open`,`closed`,or`all`. Default:`open`
5555
`assignee`|`string`| Can be the name of a user. Pass in`none` for issues with no assigned user, and`*` for issues assigned to any user. Default:`*`
5656
`creator`|`string`| The user that created the issue.
5757
`mentioned`|`string`| A user that's mentioned in the issue.

‎content/v3/oauth.md‎

Lines changed: 9 additions & 72 deletions
Original file line numberDiff line numberDiff line change
@@ -183,6 +183,12 @@ Name | Description
183183
`read:repo_hook`| Grants read and ping access to hooks in public or private repositories.
184184
`write:repo_hook`| Grants read, write, and ping access to hooks in public or private repositories.
185185
`admin:repo_hook`| Grants read, write, ping, and delete access to hooks in public or private repositories.
186+
`read:org`| Read-only access to organization, teams, and membership.
187+
`write:org`| Publicize and unpublicize organization membership.
188+
`admin:org`| Fully manage organization, teams, and memberships.
189+
`read:public_key`| List and view details for public keys.
190+
`write:public_key`| Create, list, and view details for public keys.
191+
`admin:public_key`| Fully manage public keys.
186192

187193
NOTE: Your application can request the scopes in the initial redirection. You
188194
can specify multiple scopes by separating them with a comma:
@@ -192,76 +198,6 @@ can specify multiple scopes by separating them with a comma:
192198
scope=user,public_repo
193199

194200
##Common errors for the authorization request
195-
<<<<<<< HEAD
196-
197-
There are a few things that can go wrong in the process of obtaining an
198-
OAuth token for a user. In the initial authorization request phase,
199-
these are some errors you might see:
200-
201-
###Application Suspended
202-
203-
If the OAuth application you set up has been suspended (due to reported
204-
abuse, spam, or a mis-use of the API), GitHub will redirect to the
205-
registered callback URL with the following parameters summerizing the
206-
error:
207-
208-
http://your-application.com/callback?error=application_suspended
209-
210-
Please contact[support](https://github.com/contact) to solve issues
211-
with suspended applications.
212-
213-
###Redirect URI mismatch
214-
215-
If you provide a redirect_uri that doesn't match what you've registered
216-
with your application, GitHub will redirect to the registered callback
217-
URL with the following parameters summerizing the error:
218-
219-
http://your-application.com/callback?error=redirect_uri_mismatch
220-
221-
To correct this error, either provide a redirect_uri that matches what
222-
you registered or leave out this parameter to use the default one
223-
registered with your application.
224-
225-
###Access denied
226-
227-
If the user rejects access to your application, GItHub will redirect to
228-
the registered callback URL with the following parameters summerizing
229-
the error:
230-
231-
http://your-application.com/callback?error=access_denied
232-
233-
There's nothing you can do here as users are free to choose not to use
234-
your application. More often that not, users will just close the window
235-
or press back in their browser, so it is likely that you'll never see
236-
this error.
237-
238-
##Common errors for the access token request
239-
240-
In the second phase of exchanging a code for an access token, there are
241-
an additional set of errors that can occur. The format of these
242-
responses is determined by the accept header you pass. The following
243-
examples only show JSON responses.
244-
245-
###Invalid client credentials
246-
247-
If the client\_id and or client\_secret you pass are incorrect you will
248-
receive this error response.
249-
250-
<%= json:error =>:invalid_client_credentials %>
251-
252-
To solve this error, go back and make sure you have the correct
253-
credentials for your oauth application. Double check the`client_id` and
254-
`client_secret` to make sure they are correct and being passed correctly
255-
to GitHub.
256-
257-
###Bad verification code
258-
259-
If the verification code you pass is incorrect, expired, or doesn't
260-
match what you received in the first request for authorization you will
261-
receive this error.
262-
263-
<%= json:error =>:bad_verification_code %>
264-
=======
265201

266202
There are a few things that can go wrong in the process of obtaining an
267203
OAuth token for a user. In the initial authorization request phase,
@@ -351,6 +287,8 @@ registered with your application.
351287

352288
###Bad verification code
353289

290+
<%= json:add_scopes =>['repo'],:note => 'admin script' %>
291+
354292
If the verification code you pass is incorrect, expired, or doesn't
355293
match what you received in the first request for authorization you will
356294
receive this error.
@@ -360,11 +298,10 @@ receive this error.
360298
:error_uri => "http://developer.github.com/v3/oauth/#bad-verification-code"
361299
%>
362300

363-
>>>>>>>master
364-
365301
To solve this error, start the[OAuth process over from the beginning](#redirect-users-to-request-github-access)
366302
and get a new code.
367303

368304
[oauth changes blog]:/changes/2013-10-04-oauth-changes-coming/
369305
[basics auth guide]:/guides/basics-of-authentication/
370306
[deployments]:/v3/repos/deployments
307+
[public keys]:/v3/users/keys/

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp