Skip to main content

Enterprise Server 3.15 ist derzeit als Release Candidate verfügbar.

Verwenden von CORS und JSONP zum Erstellen von ursprungsübergreifenden Anforderungen

Sie können API-Anforderungen in allen Domänen mithilfe von ursprungsübergreifenden Ressourcenfreigaben (CORS) und JSONP-Rückrufen ausführen.

Informationen zu ursprungsübergreifenden Anforderungen

Eine ursprungsübergreifende Anforderung ist eine Anforderung an eine andere Domäne als die, von der die Anforderung stammt. Aus Sicherheitsgründen blockieren die meisten Webbrowser ursprungsübergreifende Anforderungen. Sie können jedoch ursprungsübergreifenden Ressourcenfreigaben (CORS) und JSONP-Rückrufe für ursprungsübergreifende Anforderungen nutzen.

Ressourcenfreigabe zwischen verschiedenen Ursprüngen (Cross-Origin Resource Sharing, CORS)

Die REST-API unterstützt CORS (ursprungsübergreifende Ressourcenfreigaben) für AJAX-Anforderungen aus jedem Ursprung. Weitere Informationen finden Sie in der CORS W3C-Empfehlung und im HTML 5-Sicherheitshandbuch

Im Folgenden findest du eine Beispielanforderung, die von einem Browser gesendet wird, der http://example.com aufruft:

$ curl -I http(s)://HOSTNAME/api/v3 -H "Origin: http://example.com"
HTTP/2 302
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: ETag, Link, x-ratelimit-limit, x-ratelimit-remaining, x-ratelimit-reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval

Die CORS-Preflight-Anforderung lautet wie folgt:

$ curl -I http(s)://HOSTNAME/api/v3 -H "Origin: http://example.com" -X OPTIONS
HTTP/2 204
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Authorization, Content-Type, If-Match, If-Modified-Since, If-None-Match, If-Unmodified-Since, X-Requested-With
Access-Control-Allow-Methods: GET, POST, PATCH, PUT, DELETE
Access-Control-Expose-Headers: ETag, Link, x-ratelimit-limit, x-ratelimit-remaining, x-ratelimit-reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval
Access-Control-Max-Age: 86400

JSON-P-Rückrufe

Sie können einen ?callback-Parameter an einen beliebigen GET-Aufruf senden, um die Ergebnisse in einer JSON-Funktion zu umschließen. Dieser Ansatz wird in der Regel verwendet, wenn Browser GitHub Enterprise Server-Inhalte in Webseiten einbetten möchten und domänenübergreifende Probleme umgangen werden sollen. Die Antwort enthält die gleiche Datenausgabe wie die reguläre API sowie die relevanten HTTP-Headerinformationen.

$ curl http(s)://HOSTNAME/api/v3?callback=foo

> /**/foo({
>   "meta": {
>     "status": 200,
>     "x-ratelimit-limit": "5000",
>     "x-ratelimit-remaining": "4966",
>     "x-ratelimit-reset": "1372700873",
>     "Link": [ // pagination headers and other links
>       ["http(s)://HOSTNAME/api/v3?page=2", {"rel": "next"}]
>     ]
>   },
>   "data": {
>     // the data
>   }
> })

Sie können einen JavaScript-Handler schreiben, um den Rückruf zu verarbeiten. Hier finden Sie ein minimales Beispiel, das Sie ausprobieren können:

<html>
<head>
<script type="text/javascript">
function foo(response) {
  var meta = response.meta;
  var data = response.data;
  console.log(meta);
  console.log(data);
}

var script = document.createElement('script');
script.src = 'http(s)://HOSTNAME/api/v3?callback=foo';

document.getElementsByTagName('head')[0].appendChild(script);
</script>
</head>

<body>
  <p>Open up your browser's console.</p>
</body>
</html>

Alle Header haben den gleichen Zeichenkettenwert wie die HTTP-Header mit Ausnahme von Link. Link-Header werden vorab für Sie geparst und als Matrix von [url, options]-Tupeln angezeigt.

Zum Beispiel ein Link wie der folgende ...

Link: <url1>; rel="next", <url2>; rel="foo"; bar="baz"

... sieht in der Rückrufausgabe wie folgt aus:

{
  "Link": [
    [
      "url1",
      {
        "rel": "next"
      }
    ],
    [
      "url2",
      {
        "rel": "foo",
        "bar": "baz"
      }
    ]
  ]
}