travis.rb: Always getting "invalid access token"

Any update on this? This is a pretty important thing to not be working.

Thanks in advance!

Ian

Assuming previous discussion is on-point, it seems like the issue is getting erroneously labelled as malicious by some blacklisting bot. Is there a process for recovering an IP address from this black hole? I was hit by it a few days ago and, despite not touching https://api.travis-ci.org/ for a couple of days, I’m still blocked.

Also, if it would be possible to return a different error code for blocked IPs, and produce a more obvious error message in session.rb, that would be awesome. It’s not a perfect match, but 503 Service Unavailable is pretty close, since you’re doing this in response to a DDOS attack. You could even send an enormous Retry-After to indicate retrying won’t help.

@eranshapira sounds like your company should pay @rkh to fix it, rather than to pay your devs to migrate

Support solved my problem! First, mine was a little different than the OPs problem. I was following these instructions: https://docs.travis-ci.com/user/triggering-builds and using a pro account. It turns out the API URL is different for pro accounts than the URL in the instructions. You should use api.travis-ci.com instead of api.travis-ci.org. The support person said she made a PR to the instructions so they may already be updated. HTH

@bhansa Try with --debug --debug-http flags to show how the command is hanging. For a successful login, it looks like this:

$ travis login --pro --debug --debug-http
** Loading "/Users/asari/.travis/config.yml"
** GET "config"
**   took 0.25 seconds
We need your GitHub login to identify you.
This information will not be sent to Travis CI, only to api.github.com.
The password will not be displayed.

Try running with --github-token or --auto if you don't want to enter your password anyway.

Username: BanzaiMan
Password for BanzaiMan: **************
** GitHub API: POST /authorizations
Two-factor authentication code for BanzaiMan: ######
** GitHub API: POST /authorizations
**   took 1 seconds
** GitHub API: GET /user?per_page=100
**   took 0.13 seconds
** POST "auth/github" {:github_token=>"DEADBEEF"}
**   took 0.78 seconds
** GET "users/"
**   took 0.14 seconds
Successfully logged in as BanzaiMan!
** GitHub API: DELETE /authorizations/495711192
**   took 1.1 seconds
** Storing "/Users/asari/.travis/config.yml"

You might also want to try --github-token, with which the output looks like:

$ travis login --pro --debug --debug-http --github-token DEADBEEF

** Loading "/Users/asari/.travis/config.yml"
** GET "config"
**   took 0.27 seconds
** GitHub API: GET /user?per_page=100
**   took 0.2 seconds
** POST "auth/github" {:github_token=>"DEADBEEF"}
**   took 1.7 seconds
** GET "users/"
**   took 0.14 seconds
Successfully logged in as BanzaiMan!
** Storing "/Users/asari/.travis/config.yml"

How is this issue still open after 1.5 years? I’m having the same issue. I can’t get an org token that will work

I had this problem in the office today as well and could not find the cause. It seems some backend servers respond with 403 on the first HEAD / request, which is performed to test the SSL connection. I “fixed” it by monkey-patching the def check_ssl method in session.rb to do nothing.

I want to remark that the client works fine without the patch from my home internet connection. Maybe a different travis endpoint is used?

(https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments) to +1 this post.

$ ruby --version
ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-darwin15]
$ travis --version
1.8.0


$ rm -Rf ~/.travis


$ travis login --debug --github-token $GITHUB_TRAVIS_TOKEN
** Loading gh
** GET "config"
**   took 0.28 seconds
** GitHub API: GET /user?per_page=100
**   took 1.7 seconds
** POST "auth/github" {:github_token=>"6f73bc1b55588f461137b18a5e1d1c9589e3b943"}
**   took 0.51 seconds
** GET "users/"
**   took 0.39 seconds
Successfully logged in as balupton!
** Storing "/Users/balupton/.travis/config.yml"

$ travis restart -r docpad/website --debug
** Loading "/Users/balupton/.travis/config.yml"
** Loading gh
** GET "config"
**   took 0.3 seconds
** GitHub API: HEAD /repos/docpad/website
**   took 2.2 seconds
** GET "repos/docpad/website"
**   took 0.86 seconds
invalid access token - try running travis login --org


$ travis logout
Successfully logged out!
$ rm -Rf ~/.travis


$ travis login --debug --auto-password
** Loading gh
** GET "config"
**   took 0.33 seconds
** Tools::Github: requesting to load github.com login and password from keychain
** GitHub API: POST /authorizations
** GitHub API: GET /user?per_page=100
** Tools::Github: token is not acceptable: Requires authentication
We need your GitHub login to identify you.
This information will not be sent to Travis CI, only to api.github.com.
The password will not be displayed.
Try running with --github-token or --auto if you don't want to enter your password anyway.
Username: balupton
Password for balupton: BLAH
** GitHub API: POST /authorizations
Two-factor authentication code for balupton: BLAH
** GitHub API: POST /authorizations
**   took 1.3 seconds
** GitHub API: GET /user?per_page=100
**   took 1.4 seconds
** POST "auth/github" {:github_token=>"BLAH"}
**   took 0.62 seconds
** GET "users/"
**   took 0.41 seconds
Successfully logged in as balupton!
** GitHub API: DELETE /authorizations/BLAH
**   took 1.5 seconds
** Storing "/Users/balupton/.travis/config.yml"

$ travis restart -r docpad/website --debug
** Loading "/Users/balupton/.travis/config.yml"
** Timeout::Error: execution expired
** Loading gh
** GET "config"
**   took 0.29 seconds
** GitHub API: HEAD /repos/docpad/website
**   took 1.6 seconds
** GET "repos/docpad/website"
**   took 0.35 seconds
invalid access token - try running travis login --org


$ travis logout
Successfully logged out!
$ rm -Rf ~/.travis


$ travis login --auto --org --debug
** Loading gh
** GET "config"
**   took 0.36 seconds
** Tools::Github: requesting to load GitHub for Mac token from keychain
** GitHub API: GET /user?per_page=100
**   took 1.7 seconds
** POST "auth/github" {:github_token=>"BLAH"}
**   took 0.52 seconds
** GET "users/"
**   took 0.34 seconds
Successfully logged in as balupton!
** Storing "/Users/balupton/.travis/config.yml"

$ travis restart -r docpad/website --debug
** Loading "/Users/balupton/.travis/config.yml"
** Loading gh
** GET "config"
**   took 0.64 seconds
** GitHub API: HEAD /repos/docpad/website
**   took 2 seconds
** GET "repos/docpad/website"
**   took 0.27 seconds
invalid access token - try running travis login

This worked for me

travis login --org --github-token <REDACTED>
travis repos --active
# use the desired repo below 
travis token
# use the token given below
travis encrypt \
--org \
--token <REDACTED> \
--repo <REPO> \
<STRING TO ENCRYPT> \
--add deploy.password

Was getting the described behavior until I explicitly put --org, token and repo options. Then it worked. Maybe the “auto discovery” doesn’t work. Tried it when I noticed using the --debug-http option that even though I logged in with “–org” the encrypt command was trying to connect to travis-ci.com.

@Thor07, do you know if there is any way to determine this? I might have putzed around with the curl configurations, but I do not know for sure…I do not think that I have done anything to affect the browser.

@arewm @graingert are you by chance using a request modifier extension under hood like modheader(if using a browser) which causes this issue too.

There has not been any motion on this in over a year. I am still getting the same error and the suggested workaround is not working (commenting out check_ssl).

Are there any other ideas on the matter, or have others gotten this working?

I signed up for a plan yesterday and ran into this today. I’ve contacted them and we’ll see if I continue paying… Gitlab has been making a lot of interesting noise lately.

On Wed, Jan 18, 2017 at 7:34 PM, Thomas Grainger notifications@github.com wrote:

Otherwise it’s time to move to gitlab-ci

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/travis-ci/travis.rb/issues/315#issuecomment-273646856, or mute the thread https://github.com/notifications/unsubscribe-auth/AACCoS4lA_XhDoccyaH0VjJNbZGwx0AXks5rTq-qgaJpZM4Fw9bc .

This is beyond embarrassing for Travis.

It’s not the client since I’m only trying to trigger a build using Travis API as per https://docs.travis-ci.com/user/triggering-builds. I tried one request with a wrong token by mistake and now constantly getting “access denied” from Travis. I guess I’ll be shopping elsewhere very soon.

i just started getting this this morning 😕

I think this is our (quite aggressive) auto-blocking kicking in, which we have in place due to a permanent DDoS we’ve been under since September. I think the “invalid access token” is a red herring that’s automatically generated by the client on 403s.

I’ll see if I can figure out a way to solve this without opening the floodgates.

I’ve installed/uninstalled travis and tried several things but I’m always getting invalid access token…

~$ ruby -v
ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-darwin14.0]

~$ travis -v
1.8.0

~$ travis login
/X/.rvm/gems/ruby-2.1.5/gems/travis-1.8.0/lib/travis/client/session.rb:218:in `raw': invalid access token (Travis::Client::NotLoggedIn)
    from /X/.rvm/gems/ruby-2.1.5/gems/travis-1.8.0/lib/travis/client/session.rb:330:in `check_ssl'
    from /X/.rvm/gems/ruby-2.1.5/gems/travis-1.8.0/lib/travis/client/session.rb:40:in `initialize'
    from /X/.rvm/gems/ruby-2.1.5/gems/travis-1.8.0/lib/travis/client.rb:36:in `new'
    from /X/.rvm/gems/ruby-2.1.5/gems/travis-1.8.0/lib/travis/client.rb:36:in `new'
    from /X/.rvm/gems/ruby-2.1.5/gems/travis-1.8.0/lib/travis/cli/api_command.rb:37:in `initialize'
    from /X/.rvm/gems/ruby-2.1.5/gems/travis-1.8.0/lib/travis/cli/parser.rb:36:in `new'
    from /X/.rvm/gems/ruby-2.1.5/gems/travis-1.8.0/lib/travis/cli/parser.rb:36:in `new'
    from /X/.rvm/gems/ruby-2.1.5/gems/travis-1.8.0/lib/travis/cli.rb:62:in `run'
    from /X/.rvm/gems/ruby-2.1.5/gems/travis-1.8.0/bin/travis:18:in `<top (required)>'
    from /X/.rvm/gems/ruby-2.1.5/bin/travis:23:in `load'
    from /X/.rvm/gems/ruby-2.1.5/bin/travis:23:in `<main>'
    from /X/.rvm/gems/ruby-2.1.5/bin/ruby_executable_hooks:15:in `eval'
    from /X/.rvm/gems/ruby-2.1.5/bin/ruby_executable_hooks:15:in `<main>'
~$

Getting this too.

$ ruby -v
ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-darwin14]

$ travis -v
1.8.0

ARGH!!!

$ travis restart --debug --skip-completion-check --org -r docpad/website -t "$TRAVIS_ACCESS_TOKEN";
** Loading "/Users/balupton/.travis/config.yml"
** Timeout::Error: execution expired
** GET "repos/docpad/website"
**   took 0.5 seconds
** GET "builds/" {:number=>"82", :repository_id=>402397}
**   took 2.1 seconds
** POST "requests" {"job_id"=>77026387}
**   took 4.8 seconds
** GET "jobs/77026387"
**   took 0.63 seconds
** GET "jobs/77026387"
**   took 0.34 seconds
job #82.1 has been restarted
** Storing "/Users/balupton/.travis/config.yml"

$ travis restart --debug --skip-completion-check --org -r docpad/website;
** Loading "/Users/balupton/.travis/config.yml"
** Timeout::Error: execution expired
** GET "repos/docpad/website"
**   took 0.39 seconds
invalid access token - try running travis login --org

So it seems if you want it to work every time, then you must include --org and -t properties.

This is the most annoying bug ever.

So I came up with this, which still failed:

travis login --skip-completion-check --org --github-token "$GITHUB_TRAVIS_TOKEN";
export TRAVIS_ACCESS_TOKEN=`cat ~/.travis/config.yml | grep access_token | sed 's/ *access_token: *//'`;
travis restart --debug --skip-completion-check -r docpad/website -t "$TRAVIS_ACCESS_TOKEN";
travis restart --debug --skip-completion-check -r bevry/learn -t "$TRAVIS_ACCESS_TOKEN";

Then I did this, which worked:

travis login --skip-completion-check --org --github-token "$GITHUB_TRAVIS_TOKEN";
export TRAVIS_ACCESS_TOKEN=`cat ~/.travis/config.yml | grep access_token | sed 's/ *access_token: *//'`;
travis restart --debug --skip-completion-check --org -r docpad/website -t "$TRAVIS_ACCESS_TOKEN";
travis restart --debug --skip-completion-check --org -r bevry/learn -t "$TRAVIS_ACCESS_TOKEN";

Then I did this, which still worked:

travis login --skip-completion-check --org --github-token "$GITHUB_TRAVIS_TOKEN";
travis restart --debug --skip-completion-check --org -r docpad/website;
travis restart --debug --skip-completion-check --org -r bevry/learn;

It seems that the subsequent commands have an issue with using a consistent endpoint. I would imagine that by default, the endpoint for commands should be the first one in ~/.travis/config.yml