I'm trying use the GitHub API to search for Repositories through my app, but every time I send a request from my app I get authentication error:
Request forbidden by administrative rules. Please make sure your request has a User-Agent header (http://developer.github.com/v3/#user-agent-required). Check https://developer.github.com for other possible causes.
The send request that I send is this:
https://api.github.com/search/repositories?q=atom
I know that I have to provide a username in order to authenticate , but how do I do that withing the request? I don't seem to be finding it in the documentation.
Related
I've been doing some HTTP methods and header research recently if we should use GET with basic authorization instead of POST when submitting?
HTTP Methods
The GET method requests a representation of the specified resource. Requests using GET should only retrieve data.
The POST method submits an entity to the specified resource, often causing a change in state or side effects on the server.
As we see here, the POST method normally changes the state of the server. If sending out JWTs/HTTP cookies, we are not modifying the state of the server. Nor are we creating a new resource in the server.
I understand that we should not not send the username and password as a GET parameter but should we use the authorization header instead?
Basic authentication
For "Basic" authentication the credentials are constructed by first combining the username and the password with a colon (aladdin:opensesame), and then by encoding the resulting string in base64 (YWxhZGRpbjpvcGVuc2VzYW1l).
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
The only advantage I see to using POST over GET is that we need no extra code in the HTML/JS on the client side to send headers via the fetch API. To send headers, we would need an onsubmit and then check if status code is 200. If 200, we will need to redirect to the page after the login screen. Then again, if using the fetch API, this means the server does not need to send a new HTML page to the client all the time either.
Should we use GET with basic auth or POST when logging in since we don't create a resource/modify the server state?
Would this change if say we enable 2FA since we would need to generate a code for that user?
Doing basic authentication in the browser and using GET is not that recommended.
To do your own login form it is better to always do it using HTTPS and POST. Do post the username/password in the body of the request and secure it with proper CSRF protection.
If you want to level up, you can always look at the OpenIDConnect approach, but that is more advanced depending on your needs.
Also, a good approach is to explore how existing site implement a login form and look at the HTTP(s) traffic in a tool like Fiddler.
I maintain a private repository but want to make one file publicly available.
GitHub documentation states that the CURL command below can retrieve a file:
curl -u username:token https://api.github.com/user
But I would like to provide access through a URL. E.g.
https://username:token#raw.githubusercontent.com/me/repo/master/README.md
This always return a 404. Am I missing something?
From "How can I download a single raw file from a private github repo using the command line?", you wouldneed to use a PAT (Personnal Access Token) without the username:
curl -s https://$TOKEN#raw.githubusercontent.com/....
But I would not recommend making that token visible in any way: it would give access to that file and the rest of the repository.
Putting that file in a separate location (be it a separate public repository, or any other online text storage service) would be safer.
For those of you wondering the "why" on 404 vs 401, it's basically a security measure on GitHub's part to output 404 instead of 401: https://docs.github.com/en/github-ae#latest/rest/overview/other-authentication-methods#basic-authentication
For those wondering why we get a 404 in the browser while cURL gives us a success response, you might've assumed that providing the username and password in the URL like https://username:password#somesite.com would pass the credentials along in the initial request. That is not the case - the browser steps in and sees if the page you are requesting returns a WWW-Authenticate response header, and only then does it send your credentials. In the case of your GitHub url, the resource doesn't send back a WWW-Authenticate. If it did return WWW-Authenticate, then you obviously wouldn't run into this problem.
And then there's cURL. cURL assumes Basic Authentication by default and automatically sets the Authorization header to your username and password (either from the url like my previous example, or set through CLI options like in your example), and it sends it regardless of whether or not the server returns a WWW-Authenticate response header.
Unfortunately for us, there's no way to force the browser to send it with the initial request. As to why GitHub doesn't send a WWW-Authenticate response header, it's probably because they don't want to promote the least secure way of authentication - they no longer allow account passwords to be sent this way, after all. However, they do realize its ease of use and have mitigated some of its weaker points by allowing users to use oAuth access token, GitHub App installation access token, or Personal Access Token in its place that can limit its scope of access. So really, it's the browser that is following standards, and GitHub allowing a form of Basic Authentication with some alterations, and cURL immediately passing our credentials into the Authorization header. I believe the below is what's happening behind your requests:
cURL sends a request along with Authorization header → GitHub: "Well, I didn't ask, but yeah, your creds check out" → GitHub: Authorized and redirects to resource
Browser sends request and waits for WWW-Authenticate response before handing credentials → GitHub: "Umm, you don't have permission to access this resource but I can't let you know whether it actually exists") → GitHub: Returns 404 (instead of 401 with WWW-Authenticate header) stopping the browser short from receiving the WWW-Authenticate header response and sending out an Authorization header with the credentials on hand.
I have an endpoint on API Gateway that I want to make it work with requests from Strip.com only. I have tried adding stripe.com on Access-Contril-Allo-Origin* as it shown below but does not seem to be working at all.
How do I set CORS on API Gateway?
CORS only applies to requests made from a browser. It doesn't apply if you're trying to protect, for example, a webhook URL that you want Stripe to send data to. The typical approaches here are either to include a shared secret in your webhook URL, or to configure a username & password, both of which Stripe support. Examples:
https://yourdomain.com/admin/webhook/6f637faa33a2116f410cfb12af2028a85d22fcf5
https://user:pass#yourdomain.com/admin/webhook/
The other protection here is that you can verify any event received by sending an API request to Stripe to retrieve that event:
https://stripe.com/docs/webhooks#verifying-events
I think you need to have the schema on the header, like, https://stripe.com as Access-Control-Allow-Origin
I'm, trying to get content of this URL
https://www.google.com/m8/feeds/contacts/default/full?oauth_token=XXXX.XXXXXXXXXXXXXXXXXXXXXXXX&v=3.0&max_result=500
but received error code 401 with description : There was an error in your request. That's all we know.
Two things to point.
A successful Oauth authentication needs to be implemented first before you are able to make a HTTP request. Be sure to use the correct scope that you need; In your case, you're using the read/write scope.
Refer to this LINK as an example on implementing OAuth on PHP.
Second, v and oauth_token are not valid URL parameters for HTTP requests. Check this Google Contacts API documentation for more information.
Hope this helps.
I am trying to use the Cloudcontrol REST API.
Has anybody used that API? I did not find out how to authenticate.
As an example, I tried https://api.devcctrl.com/app/APPMNAME/deployment/default/error/
I found : https://api.devcctrl.com/doc/#Token but I don't understand how exactly to use it.
An example would be great.
What I really want to do: I want to deploy an app using REST API. I cannot use the CLI tools due to missing python installation.
Thanks
Mike
First, in order to get the token, you need to send a HTTP POST request to api.cloudcontrol.com/token/using Basic Authentication using the email and password of your cloudControl account. You will get a JSON response like this:
{"token": "<TOKEN_KEY>"}'
You need this token key to authenticate for all other requests to the API. To do so, add an Authorization Header to your request with this content:
Authorization -> "cc_auth_token="<TOKEN_KEY>""
Furthermore, you might also need to set up some other headers for PUT or POST requests, like:
Content-Type -> "application/x-www-form-urlencoded"
Content-Length -> <length of your parametrized url values, e.g. bar=baz&foo=qux>
Accept-Encoding -> "compress, gzip"
You can find examples of this usage in the pycclib (Python) or gocclib (Go) libraries.