Always getting "invalid access token"

[balupton]

If you are experiencing this issue to, use the reaction button 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 --org

[balupton]

Opening ~/.travis/config.yml and using the token from inside that with the -t flag works fine...

update: works fine locally, seems that key can't be used on other machines

[balupton]

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

[balupton]

Okay, now the above doesn't even work, what the hell.

$ rm -Rf ~/.travis

$ travis login --skip-completion-check --org --github-token "$GITHUB_TRAVIS_TOKEN"
Successfully logged in as balupton!

$ travis restart --debug --skip-completion-check --org -r docpad/website
** Loading "/Users/balupton/.travis/config.yml"
** GET "repos/docpad/website"
**   took 0.46 seconds
invalid access token - try running travis login --org

Travis CI status page says All Systems Operational.

I give up. Someone please help.

[balupton]

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.

[emilesilvis]

Getting this too.

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

$ travis -v
1.8.0

[germanattanasio]

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>'
~$

[martinbonnin]

Same here :-(

$ ruby -v
ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux]
$ travis -v
1.8.0

[crunis]

I am having this error by just executing require 'travis' and it stopped as soon as I executed this command from a different IP. Seems Travis applies some low rate-limit for logins.

[spiderpug]

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?

[JesseAldridge]

Seeing this too in 1.8.1, on every command. I can't use this tool at all.

$ travis whoami
/Library/Ruby/Gems/2.0.0/gems/travis-1.8.1/lib/travis/client/session.rb:219:in `raw': invalid access token (Travis::Client::NotLoggedIn)
  from /Library/Ruby/Gems/2.0.0/gems/travis-1.8.1/lib/travis/client/session.rb:331:in `check_ssl'
  from /Library/Ruby/Gems/2.0.0/gems/travis-1.8.1/lib/travis/client/session.rb:40:in `initialize'
  from /Library/Ruby/Gems/2.0.0/gems/travis-1.8.1/lib/travis/client.rb:36:in `new'
  from /Library/Ruby/Gems/2.0.0/gems/travis-1.8.1/lib/travis/client.rb:36:in `new'
  from /Library/Ruby/Gems/2.0.0/gems/travis-1.8.1/lib/travis/cli/api_command.rb:37:in `initialize'
  from /Library/Ruby/Gems/2.0.0/gems/travis-1.8.1/lib/travis/cli/parser.rb:36:in `new'
  from /Library/Ruby/Gems/2.0.0/gems/travis-1.8.1/lib/travis/cli/parser.rb:36:in `new'
  from /Library/Ruby/Gems/2.0.0/gems/travis-1.8.1/lib/travis/cli.rb:62:in `run'
  from /Library/Ruby/Gems/2.0.0/gems/travis-1.8.1/bin/travis:18:in `<top (required)>'
  from /usr/bin/travis:23:in `load'
  from /usr/bin/travis:23:in `<main>'

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

[BanzaiMan]

Hello. I have released version 1.8.2, which adds a new flag (--debug-http) for debugging HTTP connexions that we make. My hope is that this flag will give us insight into this issue. Please try adding this flag to problematic commands to see what the underlying issue might be.

Please note that this command may potentially expose sensitive data, so please do be careful when you paste the output publicly.

Thank you!

[BanzaiMan]

@crunis Not sure what you mean. This _is_ the travis gem.

[JesseAldridge]

Same result for me:

$ travis login --debug-http
/usr/local/lib/ruby/gems/2.2.0/gems/travis-1.8.2/lib/travis/client/session.rb:221:in `raw': invalid access token (Travis::Client::NotLoggedIn)
    from /usr/local/lib/ruby/gems/2.2.0/gems/travis-1.8.2/lib/travis/client/session.rb:333:in `check_ssl'
    from /usr/local/lib/ruby/gems/2.2.0/gems/travis-1.8.2/lib/travis/client/session.rb:41:in `initialize'
    from /usr/local/lib/ruby/gems/2.2.0/gems/travis-1.8.2/lib/travis/client.rb:36:in `new'
    from /usr/local/lib/ruby/gems/2.2.0/gems/travis-1.8.2/lib/travis/client.rb:36:in `new'
    from /usr/local/lib/ruby/gems/2.2.0/gems/travis-1.8.2/lib/travis/cli/api_command.rb:41:in `initialize'
    from /usr/local/lib/ruby/gems/2.2.0/gems/travis-1.8.2/lib/travis/cli/parser.rb:36:in `new'
    from /usr/local/lib/ruby/gems/2.2.0/gems/travis-1.8.2/lib/travis/cli/parser.rb:36:in `new'
    from /usr/local/lib/ruby/gems/2.2.0/gems/travis-1.8.2/lib/travis/cli.rb:62:in `run'
    from /usr/local/lib/ruby/gems/2.2.0/gems/travis-1.8.2/bin/travis:18:in `<top (required)>'
    from /usr/local/bin/travis:23:in `load'
    from /usr/local/bin/travis:23:in `<main>'

I did install with sudo like so: sudo gem install travis in case that's relevant.

[BanzaiMan]

@JesseAldridge Thanks for testing. Looks like the implementation still needs some work.

[BanzaiMan]

Hello. I've released a special debugging version https://rubygems.org/gems/travis/versions/1.8.3.travis.726.4.pre.debug that enables the logging universally (meaning that it is on whether or not you pass --debug-http).

You can try this with gem install travis --pre.

As before, please do be careful when you paste the output. Thank you.

[dleve123]

I'm running into this as well before and after going down the gem install travis --pre route.

$ ruby -v
ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-darwin14.0]
$ travis logout
I, [2016-01-14T12:11:50.148098 #3814]  INFO -- : head https://api.travis-ci.org/
D, [2016-01-14T12:11:50.148206 #3814] DEBUG -- request: User-Agent: "Travis/1.8.2 (Mac OS X 10.10.5 like Darwin; Ruby 2.1.5-p273; RubyGems 2.2.2; command logout) Faraday/0.9.2 Typhoeus/0.7.1"
Accept: "application/vnd.travis-ci.2+json"
I, [2016-01-14T12:11:50.403904 #3814]  INFO -- Status: 403
D, [2016-01-14T12:11:50.404128 #3814] DEBUG -- response: Connection: "keep-alive"
Server: "nginx"
Date: "Thu, 14 Jan 2016 17:11:50 GMT"
Content-Type: "text/plain"
Content-Length: "10"
Status: "403 Forbidden"
Access-Control-Allow-Origin: "*"
Access-Control-Allow-Credentials: "true"
Access-Control-Expose-Headers: "Content-Type, Cache-Control, Expires, Etag, Last-Modified"
Strict-Transport-Security: "max-age=31536000"
X-Oauth-Scopes: ""
Vary: "Accept-Encoding"
X-Rack-Cache: "miss"
Via: "1.1 vegur"
/usr/local/var/rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/travis-1.8.3.travis.726.4.pre.debug/lib/travis/client/session.rb:221:in `raw': invalid access token (Travis::Client::NotLoggedIn)
        from /usr/local/var/rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/travis-1.8.3.travis.726.4.pre.debug/lib/travis/client/session.rb:333:in `check_ssl'
        from /usr/local/var/rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/travis-1.8.3.travis.726.4.pre.debug/lib/travis/client/session.rb:41:in `initialize'
        from /usr/local/var/rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/travis-1.8.3.travis.726.4.pre.debug/lib/travis/client.rb:36:in `new'
        from /usr/local/var/rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/travis-1.8.3.travis.726.4.pre.debug/lib/travis/client.rb:36:in `new'
        from /usr/local/var/rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/travis-1.8.3.travis.726.4.pre.debug/lib/travis/cli/api_command.rb:41:in `initialize'
        from /usr/local/var/rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/travis-1.8.3.travis.726.4.pre.debug/lib/travis/cli/parser.rb:36:in `new'
        from /usr/local/var/rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/travis-1.8.3.travis.726.4.pre.debug/lib/travis/cli/parser.rb:36:in `new'
        from /usr/local/var/rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/travis-1.8.3.travis.726.4.pre.debug/lib/travis/cli.rb:62:in `run'
        from /usr/local/var/rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/travis-1.8.3.travis.726.4.pre.debug/bin/travis:18:in `<top (required)>'
        from /usr/local/var/rbenv/versions/2.1.5/bin/travis:23:in `load'
        from /usr/local/var/rbenv/versions/2.1.5/bin/travis:23:in `<main>'

Before I was on the latest version (the --pre version) of the gem, this token problem "creeped" in – I would get it sometimes, but not always.

[balupton]

Just installed the --pre version, will post back with how I go.

[spiderpug]

I'm thinking this is a backend issue. Using the pre version from our office's line I basically receive the output that was already posted (https://github.com/travis-ci/travis.rb/issues/315#issuecomment-160693760), but at home I get this using the same computer/env/setup:

I, [2016-01-14T20:07:53.225886 #3462]  INFO -- : head https://api.travis-ci.org/
D, [2016-01-14T20:07:53.225974 #3462] DEBUG -- request: User-Agent: "Travis/1.8.2 (Mac OS X 10.10.3 like Darwin; Ruby 2.1.2-p95; RubyGems 2.2.2; command whoami) Faraday/0.9.1 Typhoeus/0.8.0"
Accept: "application/vnd.travis-ci.2+json"
I, [2016-01-14T20:07:53.944451 #3462]  INFO -- Status: 200
D, [2016-01-14T20:07:53.944534 #3462] DEBUG -- response: Connection: "keep-alive"
Server: "nginx"
Date: "Thu, 14 Jan 2016 19:07:53 GMT"
Content-Type: "application/json"
Content-Length: "17"
Status: "200 OK"
Access-Control-Allow-Origin: "*"
Access-Control-Allow-Credentials: "true"
Access-Control-Expose-Headers: "Content-Type, Cache-Control, Expires, Etag, Last-Modified"
Strict-Transport-Security: "max-age=31536000"
X-Endpoint: "Travis::Api::App::Endpoint::Home"
X-Pattern: "/"
X-Oauth-Scopes: "public"
X-Accepted-Oauth-Scopes: "public"
Vary: "Accept,Accept-Encoding"
X-Rack-Cache: "miss"
Via: "1.1 vegur"

Monkey-patching the def check_ssl still works.

[rkh]

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.

[JesseAldridge]

Is there a way to generate secure environment vars other than using the cli tool? We want to run CI against pull requests, and we need secure env vars to run our tests, and it looks like we can't use the web UI for generating secure env vars when working with PRs. So I think we might be stuck unless this issue gets resolved.

[JesseAldridge]

Strangely the cli tool works for one guy in our office and no one else.

[eranshapira]

This is an issue that will cause our company to drop Travis and move to Jenkins.

[balupton]

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

[stdavis]

I'm having this same problem and the suggested monkey patch isn't working for me. Post-monkey patch I get: 'invalid access token - try running travis login' even when I run travis login. Is there any other way to encrypt variables until this gets fixed?

[glennpratt]

@rkh any update here? I just tried to help people in Boston and Hungary setup travis.rb and it was pretty rough :(

Here in Texas, I've had no issues.

[mroth]

Experiencing the same issue here 100% of the time now, looks like the auto blocking @rkh mentioned, debug output with pre version:

I, [2016-02-26T11:39:50.756102 #43700]  INFO -- : head https://api.travis-ci.org/
D, [2016-02-26T11:39:50.756167 #43700] DEBUG -- request: User-Agent: "Travis/1.8.2 (Mac OS X 10.11.3 like Darwin; Ruby 2.3.0-p0; RubyGems 2.5.1; command login) Faraday/0.9.2 Typhoeus/0.8.0"
Accept: "application/vnd.travis-ci.2+json"
I, [2016-02-26T11:39:51.399180 #43700]  INFO -- Status: 403
D, [2016-02-26T11:39:51.399245 #43700] DEBUG -- response: Connection: "keep-alive"
Server: "nginx"
Date: "Fri, 26 Feb 2016 16:39:53 GMT"
Content-Type: "text/plain"
Content-Length: "10"
Status: "403 Forbidden"
Access-Control-Allow-Origin: "*"
Access-Control-Allow-Credentials: "true"
Access-Control-Expose-Headers: "Content-Type, Cache-Control, Expires, Etag, Last-Modified"
Strict-Transport-Security: "max-age=31536000"
X-Oauth-Scopes: ""
Vary: "Accept-Encoding"
X-Rack-Cache: "miss"
Via: "1.1 vegur"
/Users/mroth/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/travis-1.8.3.travis.726.4.pre.debug/lib/travis/client/session.rb:221:in `raw': invalid access token (Travis::Client::NotLoggedIn)
    from /Users/mroth/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/travis-1.8.3.travis.726.4.pre.debug/lib/travis/client/session.rb:333:in `check_ssl'
    from /Users/mroth/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/travis-1.8.3.travis.726.4.pre.debug/lib/travis/client/session.rb:41:in `initialize'
    from /Users/mroth/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/travis-1.8.3.travis.726.4.pre.debug/lib/travis/client.rb:36:in `new'
    from /Users/mroth/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/travis-1.8.3.travis.726.4.pre.debug/lib/travis/client.rb:36:in `new'
    from /Users/mroth/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/travis-1.8.3.travis.726.4.pre.debug/lib/travis/cli/api_command.rb:41:in `initialize'
    from /Users/mroth/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/travis-1.8.3.travis.726.4.pre.debug/lib/travis/cli/parser.rb:36:in `new'
    from /Users/mroth/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/travis-1.8.3.travis.726.4.pre.debug/lib/travis/cli/parser.rb:36:in `new'
    from /Users/mroth/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/travis-1.8.3.travis.726.4.pre.debug/lib/travis/cli.rb:62:in `run'
    from /Users/mroth/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/travis-1.8.3.travis.726.4.pre.debug/bin/travis:18:in `<top (required)>'
    from /Users/mroth/.rbenv/versions/2.3.0/bin/travis:23:in `load'
    from /Users/mroth/.rbenv/versions/2.3.0/bin/travis:23:in `<main>'

I'm on a residential Verizon FiOS connection in NYC, in the 96.250.79.xx block. I use the CLI client only sporadically, so it's very unlikely that I hit a rate limit of some kind.

UPDATE: ...and as soon as it started, the problem is now gone. Seems like sporadic issues with the server? (Or perhaps someone saw this post and whitelisted my IP range?)

[balupton]

@rkh where is the rate limit code, perhaps the community could pull request it

[carlessistare]

Same problem here

[obazoud]

Same problem here!

[obazoud]

My workaround:

• remove ~/.travis/config.yml
• comment checkssl in session.rb
• travis login --pro
• travis encrypt FOO=bar --pro now works!