according to the documentation I can get the contents of a particular file in a github repo like this:
GET /repos/:owner/:repo/contents/:path
which indeed works for my public repos? But what about my private ones? How can I have my applications access their contents?
You need to add authorization to your request.
One way to do this is through the headers. Add both of the following headers:
User-Agent: 'YOUR_USERNAME'
Authorization: 'token YOUR_TOKEN'
Related
I am making a new backend page where you should be able to download an export.
I already got the the route and the export working. If I call my export action from curl with sw-access-key I get my download: store-api/v3/_action/orderer-export/77f40024cfd448d9a90063a75dc9fb2e
How do I make the download link with auth?
Update
I added a service and created it like:
vendor/shopware/administration/Resources/app/administration/src/module/sw-import-export/service/importExport.service.js
Also changed store-api to api in my DownloadRoute.php: #RouteScope(scopes={"api"})
Now I can use this new service to call my API and the the file contents as response. Still no download.
Looking at \Shopware\Core\Content\ImportExport\Controller\ImportExportActionController::download I finally got it.
Simply add defaults={"auth_required"=false} to your route:
#Route("/api/v{version}/_action/import-export/file/download", name="api.action.import_export.file.download", defaults={"auth_required"=false}, methods={"GET"})
Security Warning: If your download contains non public information you need to add a secure token or download link. Otherwise your download is free for anyone. Shopwares own ImportExport generates download links with a token. Have a look there.
Is there a way to retrieve information about the number of stars of a GitHub repository over time? I know I can get a list of all users who starred a repository using the stargazers API endpoint. This doesn't include information about when each user has starred the repo, though. Any hints on how I can retrieve this data?
You can get the property starred_at using this custom media :
Accept: application/vnd.github.v3.star+json
Your headers might look something like this (I'm using Javascript here):
headers: {
...
Accept: 'application/vnd.github.v3.star+json',
...
},
See the documentation here: https://developer.github.com/v3/activity/starring/#alternative-response-with-star-creation-timestamps
This repository: https://github.com/timqian/star-history uses this technique to retrieve the stars over time to create a chart.
I am attempting to do implement an authorization code grant I start by calling (from the browser):
https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature&client_id=1ee7dba4-ca87-4451-8b82-a5df0d95fa41&state=a39fh23hnf23&redirect_uri=http://localhost:4000/docusign/authGrantReturn/
Sometimes I am asked for login/password, which always tells me that the response type is not supported or that the user/pass are not valid. I found this previous answer (Authorization Code Grant error: invalid authentication request) but did not find the checkbox discussed.
Otherwise, it calls back my rediect url (handled in node), and provides me with a 'code' and returns the 'state' I previously sent, and here begins my confusion:
I make an http request using the fetch library like so:
let combination = `${integrationKey}:${secretKey}`;
let b64Combination = Buffer.from(combination).toString('base64');
fetch('https://account-d.docusign.com/oauth/token?grant_type:authorization_code&code='+b64Combination,{
method: 'GET',
headers: { 'Authorization': 'Basic ${b64Combination}', 'Content-Type': 'application/x-www-form-urlencoded', 'Content-Encoding': 'gzip'}
})
.then...
But this returns html content in the body.
Does that mean I should make the call to https://account-d.docusign.com/oauth/token from the browser rather than node?
When it asks me to log in, am I to use my sand-box account credentials? or the credentials of a regular docusign user?
Sorry for the confused question...
Best regards,
Adrian.
I would suggest you use the DocuSign nodeJS SDK and code example.
https://github.com/docusign/eg-03-node-auth-code-grant
Follow the instructions here, this code makes it very simple and if you update all your info - it just works.
Then, you can see how to modify it to your needs.
(for your second question, yes, for now you use your sandbox creds when you build/test your app)
I have a github release with no assets yet:
$ curl https://api.github.com/repos/cljsinfo/api-docs/releases/1260660/assets
[
]
But I cannot upload an asset to this release:
$ curl -X POST --header "Content-Type:application/edn" --data-binary #cljsdocs-full.edn "https://api.github.com/repos/cljsinfo/api-docs/releases/1260660/assets?name=full.edn&access_token=$(cat my-token)"
{
"message": "Not Found",
"documentation_url": "https://developer.github.com/v3"
}
my api access token has public_repo access. Thanks for any helping on uploading this asset.
You're making the POST request to https://api.github.com/repos/cljsinfo/api-docs/releases/1260660/assets which is not the upload URL for the release. It should be https://uploads.github.com/repos/cljsinfo/api-docs/releases/1260660/assets.
See the docs for more info:
https://developer.github.com/v3/repos/releases/#upload-a-release-asset
The asset upload URL is of the form https://<upload_url>/repos/:owner/:repo/releases/:id/assets?name=foo.zip. There are several possible reasons you might get the very unhelpful "Not Found" error:
Wrong release id. The :id field in the URL above is NOT the name you gave the release, but a numeric id generated by GitHub (probably a database ID). To get the release ID, you have to call the releases API and search through the JSON response for a release where the tag_name is equal to the name you used. For example, if you named your release v0.0.3, search in the JSON for a release with "tag_name": "v0.0.3" and use that release's id field.
Wrong upload URL. The URL you use to upload assets is not the same one ou use for all other API calls. To get the right upload URL, you use the same releases API, find your release using tag_name a described above, and extract the upload_url field from the JSON response. This is Ivan's (accepted) answer.
Missing GitHub access token permissions. This is the one that tripped me up the worst, as the token I was using was able to make API calls to the releases API and get info about my repo, but NOT upload assets to that same repo. The "Not Found" error response doesn't hint at this at all. Check the permissions for your token in your personal access tokens page and make sure repo and/or public_repo are checked, as appropriate.
Note that for Enterprise flavored GitHub, the upload url isn't the same form as for 'github.com', and you should use the 'upload_url' returned when creating/querying the release:Get Release API Docs
For example here's what's returned from our enterprise github server (slightly munged to protect the guilty):"upload_url": "https://git.example.com/api/uploads/repos/example-owner/example-repo/releases/5/assets{?name,label}",
I am trying to create a Private upload using the bcx API.
But for some reason I cannot find, the upload is uploaded successfully but it's not being marked as Private.
The documentation is here:
https://github.com/basecamp/bcx-api/blob/master/sections/uploads.md
This is what I am sending:
POST https://basecamp.com/1234567/api/v1/projects/1234567/uploads.json HTTP/1.1
Authorization: Basic ZXJpY0BXXXXXXXXXXXXXXX5hbHMuY29tOmdvcmF2ZW5zNTU=
Content-Type: application/json
User-Agent: mickey#mouse.com
Host: basecamp.com
Content-Length: 198
Expect: 100-continue
{"content":"this was moved from the other account","attachments":[{"token":"af4e7e8e8XXXXXXXXXXXXXXX256549ee0010","name":"Final Export_acu-macrrc_2013-01-22.xls"}],"subscribers":null,"private":true}
When I send this I get a 201 created response along with additional details... Happy Days!
But, when I look in the Web UI, the "upload" is there but it's not marked as Private.
(I have successfully created other private objects in this project with this user)
Can anyone see anything wrong please?
Thanks
this turned out to be a bug in the API.
it's now been fixed and works as expected.
hth
Trev