I am building an Github OAuth app and attempting to see if I can validate the access_token returned by github upon login. The access_token is returned by github by making a POST call to the end point https://github.com/login/oauth/access_token and passing in CLIEND_ID and CLIENT_SECRET provided by github. Using this access_token, we can then access users information. My main question is, is there an end point to validate this token? I wanted this because I am running a node server which accesses files on github. As of now, the node end point is open and anyone can just call the functions in it. In each function, I would like to check if the user has a valid token or not before returning data to them and as such, have some form of security to my node API.
This is how I get the access_token in node
const params = "?client_id="+CLIENT_ID+"&client_secret="+ CLIENT_SECRET +"&code="+req.query.code;
await fetch("https://github.com/login/oauth/access_token"+params,{
method: "POST",
headers:{
"Accept": "application/json"
}
}).then((response) => {
return response.json();
}).then((data)=> {
res.json(data);
});
I have tried the following cURL end points, and it does return data
curl -H 'Authorization: token myGitHubAccessToken' https://api.github.com/user/repos
reference: https://onecompiler.com/questions/3uxsn58yz/how-to-test-a-github-access-token-is-valid
The above command does return data and my client ID, so it is somewhat useful. However, the access_token, which github returns a new one every time the user logs in, it itself seems to never expire. So I can copy a previously returned token to get the same data dump in the above command. I had read whats the lifetime of Github OAuth API access token that the token never expires, but then that itself is an issues. Is there some other method I should use to get around this issue? I dont want my API's to be open. If I could validate the access_token provided by github in every one of the node functions and also have it expire upon logging out, the issue will be resolved.
Also tried some options mentioned here: https://developer.github.com/changes/2/
of which, https://docs.github.com/en/rest/apps/oauth-applications?apiVersion=2022-11-28#check-a-token
made the most sense to me. But the cURL command given on that page:
curl \
-X DELETE \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <YOUR-TOKEN>"\
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/applications/Iv1.8a61f9b3a7aba766/token \
-d '{"access_token":"e72e16c7e42f292c6912e7710c838347ae178b4a"}'
does not seem to work. It returns Bad Data.
Please advise! Thank you!!
Found the answer:
To check access token:
curl -H 'Authorization: token access_token' https://api.github.com/user/repos
The above command returns repos. For me, this is enough because I just want some reply from github using the token thats not a 404
To delete the token:
curl \
-X DELETE \
-H "Accept: application/vnd.github.v3+json" \
-u CLIENT_ID:CLIENT_SECRET \
https://api.github.com/applications/CLIENT_ID/token \
-d '{"access_token":"ACCESS_TOKEN"}'
Reference: Remove/revoke GitHub OAuth 'access_token'
Apologies for the bad editing. Cant get it to look just right.
I am trying to get a response from Microsofts Office 365 Management API using bash curl commands-
I get the token like this-
TOKEN=$(curl -X POST "https://login.microsoftonline.com/$TENANTID/oauth2/token" -d "grant_type=client_credentials&client_id=$CLIENTID&client_secret=$ACCESSCODE&resource=$RESOURCEURL" | jq -r '.access_token')
And then use the token to fetch the data like this-
RESULT=`curl -X GET -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" https://manage.office.com/api/v1.0/$TENANTID/ServiceComms/Services`
I do get a token back with the first command, so that works fine and my tenant/client/resource strings are correct
But the second one always gives
{
"error":{
"code":"","message":"Authorization has been denied for this request."
}
}
I pretty sure I have access-
What am I missing?
Turns out the resource URL i was using did not match the URL i was requesting data from
This question is about the search-tweets-ruby client provided by twitter for use with their premium and enterprise API's.
I am following the instructions and run into a 'Bad Authentication data' error when running the app (via terminal - Mac OS X) to retrieve tweets with a single rule.
The 'bearer token' and 'dev environment' are correct because a Curl request works.
The following are the contents of my ./config/config.yaml file
auth:
app_token: my_generated_bearer_token
labels:
environment: my_dev_environment_name
options:
search_type: premium
archive: fullarchive
max_results: 500
write_mode: standard-out
out_box: ./output
I'm not sure what I'm missing here, but would appreciate an assist. I haven't worked with the Twitter API before, although I've reviewed the documentation before asking on SO.
Thanks, everyone.
Update:
The first sample call, from the provided link is:
$ruby ./search-app.rb -r "snow profile_region:colorado has:media".
This yields a 'bad authentication error'.
I provided the contents of my yaml file, because presumably that is the only difference between the Curl request and the client app, if the 'bearer token' and 'environment name' work with Curl.
curl --request POST \
--url https://api.twitter.com/1.1/tweets/search/30day/prod.json \
--header 'authorization: Bearer AAAAAAAAAAAAAAAAAAAAAMLheAAAAAAA0%2BuSeid%2BULvsea4JtiGRiSDSJSI%3DEUifiRBkKG5E2XzMDjRfl76ZC9Ub0wnz4XsNiRVBChTYbJcE3F' \
--header 'content-type: application/json' \
--data '{
"query":"from:TwitterDev lang:en",
"maxResults": "100",
"fromDate":"201811010000",
"toDate":"201811062359"
}'
There is no code.
I think the issue is that your YAML file is configured for the full-archive search endpoint, yet your CURL-based call is going to the 30-day search endpoint. If you update the YAML file to point to the '30day' endpoint, I suspect it will succeed.
Trying to lunch a job workflow via REST API and passing extra variables for the playbook to consume, but returned body shows that provided variables are put in ignored_fields section.
Used POSTMAN and CURL to run the templates both returned the same result
CURL command
curl -X POST http://172.16.0.97/api/v2/job_templates/8/launch/ -H "Content-Type: application/json" -H "Authorization: Bearer Je
gxwfQrdKQXoRUtNWtWFz62FX5bTy" -d "{\"extra_vars\": {\"vendor\":\"juniper\"}}"
Returned body
{"job":34,"ignored_fields":{"extra_vars":{"vendor":"juniper"}},"id":34,"type":"job","url":"/api/v2/jobs/34/","related":{"created_by":"/api/v2/users/1/","modified_by":"/api/v2/users/1/","labels":"/api/v2/jobs/34/labels/","inventory":"/api/v2/inventories/1/","project":"/api/v2/projects/7/","extra_credentials":"/api/v2/jobs/34/extra_credentials/","credentials":"/api/v2/jobs/34/credentials/","unified_job_template":"/api/v2/job_templates/8/","stdout":"/api/v2/jobs/34/stdout/","job_events":"/api/v2/jobs/34/job_events/","job_host_summaries":"/api/v2/jobs/34/job_host_summaries/","activity_stream":"/api/v2/jobs/34/activity_stream/","notifications":"/api/v2/jobs/34/notifications/","job_template":"/api/v2/job_templates/8/","cancel":"/api/v2/jobs/34/cancel/","create_schedule":"/api/v2/jobs/34/create_schedule/","relaunch":"/api/v2/jobs/34/relaunch/"},"summary_fields":{"inventory":{"id":1,"name":"Demo Inventory","description":"","has_active_failures":true,"total_hosts":1,"hosts_with_active_failures":1,"total_groups":0,"groups_with_active_failures":0,"has_inventory_sources":false,"total_inventory_sources":0,"inventory_sources_with_failures":0,"organization_id":1,"kind":""},"project":{"id":7,"name":"Cox-Phase3","description":"","status":"successful","scm_type":"git"},"job_template":{"id":8,"name":"Port Flap","description":""},"unified_job_template":{"id":8,"name":"Port Flap","description":"","unified_job_type":"job"},"created_by":{"id":1,"username":"admin","first_name":"","last_name":""},"modified_by":{"id":1,"username":"admin","first_name":"","last_name":""},"user_capabilities":{"delete":true,"start":true},"labels":{"count":0,"results":[]},"extra_credentials":[],"credentials":[]},"created":"2019-05-14T09:43:16.115516Z","modified":"2019-05-14T09:43:16.177517Z","name":"Port Flap","description":"","job_type":"run","inventory":1,"project":7,"playbook":"main.yml","forks":0,"limit":"","verbosity":1,"extra_vars":"{}","job_tags":"","force_handlers":false,"skip_tags":"","start_at_task":"","timeout":0,"use_fact_cache":false,"unified_job_template":8,"launch_type":"manual","status":"pending","failed":false,"started":null,"finished":null,"elapsed":0.0,"job_args":"","job_cwd":"","job_env":{},"job_explanation":"","execution_node":"","controller_node":"","result_traceback":"","event_processing_finished":false,"job_template":8,"passwords_needed_to_start":[],"ask_diff_mode_on_launch":false,"ask_variables_on_launch":false,"ask_limit_on_launch":false,"ask_tags_on_launch":false,"ask_skip_tags_on_launch":false,"ask_job_type_on_launch":false,"ask_verbosity_on_launch":false,"ask_inventory_on_launch":false,"ask_credential_on_launch":false,"allow_simultaneous":false,"artifacts":{},"scm_revision":"","instance_group":null,"diff_mode":false,"job_slice_number":0,"job_slice_count":1,"credential":null,"vault_credential":null}
According to the fine manual, AWX (and thus Tower) version 3.0 and greater has made extra_vars more strict: https://docs.ansible.com/ansible-tower/latest/html/userguide/job_templates.html#ug-jobtemplates-extravars
If you are running a version greater than 3.0, you will need to either turn on playbook survey or set ask_variables_on_launch=True for that template
In my case, I'm using curl -L ... and the payload got lost after the redirect. Be sure to double check that if you find the extra_vars still gets ignored after ensuring ask_variables_on_launch=True.
Tangentially related to the API when utilizing the AWX and Tower CLI I ran into a similar issue of variables not being taken when launching jobs. The solution was that on the Job Template in Tower the "Prompt on Launch" setting needed to checked for the variable to pass through. So much time wasted on such a simple miss.
I am trying to upload a zip file to Google drive account using curl.
The file is uploaded successfully but the filename is not getting updated. It gets uploaded with default filename i.e. "Untitled".
I am using below command.
curl -k -H "Authorization: Bearer cat /tmp/token.txt" -F "metadata={name : 'backup.zip'} --data-binary "#backup.zip" https://www.googleapis.com/upload/drive/v2/files?uploadType=multipart
You can use Drive API v3 to upload the zip file. The modified curl code is as follows.
curl -X POST -L \
-H "Authorization: Bearer `cat /tmp/token.txt`" \
-F "metadata={name : 'backup.zip'};type=application/json;charset=UTF-8" \
-F "file=#backup.zip;type=application/zip" \
"https://www.googleapis.com/upload/drive/v3/files?uploadType=multipart"
In order to use this, please include https://www.googleapis.com/auth/drive in the scope.
The answer above works fine and was the command I used in uploading my file to Google Drive using Curl. However, I didn't understand what scope was and all of the initial setup required to make this command work. Hence, for documentation purposes. I'll give a second answer.
Valid as at the time of writing...
Visit the Credentials page and create a new credential (this is assuming you have created a project). I created credentials for TVs and Limited devices, so the work flow was similar to:
Create credentials > OAuth client ID > Application Type > TVs and Limited Input devices > Named the client > Clicked Create.
After doing this, I was able to copy the Client ID and Client Secret when viewing the newly created credential.
NB: Only the variables with double asterisk from the Curl commands should be replaced.
Next step was to run the Curl command:
curl -d "client_id=**client_id**&scope=**scope**" https://oauth2.googleapis.com/device/code
Scope in this situation can be considered to be the kind of access you intend to have with the credential having the inputted client_id. More about scope from the docs For the use case in focus, which is to upload files, the scope chosen was https://www.googleapis.com/auth/drive.file.
On running the curl command above, you'll get a response similar to:
{ "device_code": "XXXXXXXXXXXXX", "user_code": "ABCD-EFGH",
"expires_in": 1800, "interval": 5, "verification_url":
"https://www.google.com/device" }
Next step is to visit the verification_url in the response in your browser, provide the user_code and accept requests for permissions. You will be presented with a code when all prompts have been followed, this code wasn't required for the remaining steps (but there may be some reasons to use it for other use cases).
Next step is to use the Curl command:
curl -d client_id=**client_id** -d client_secret=**client_secret** -d device_code=**device_code** -d grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code https://accounts.google.com/o/oauth2/token
You will get a response similar to:
{ "access_token": "XXXXXXXXX", "expires_in": 3599,
"refresh_token": "XXXXXXXXX", "scope":
"https://www.googleapis.com/auth/drive.file", "token_type": "Bearer"
}
Now you can use the access token and follow the accepted answer with a Curl command similar to:
curl -X POST -L \
-H "Authorization: Bearer **access_token**" \
-F "metadata={name : 'backup.zip'};type=application/json;charset=UTF-8" \
-F "file=#backup.zip;type=application/zip" \
"https://www.googleapis.com/upload/drive/v3/files?uploadType=multipart"