graphql_devise: Token invalidation does not occur in test environments

Describe the bug

When using the same token in two requests in a spec file the second request accepts the then expired token.

Environment

devise (4.7.3)
  bcrypt (~> 3.0)
  orm_adapter (~> 0.1)
  railties (>= 4.1.0)
  responders
  warden (~> 1.2.3)
devise_token_auth (1.1.5)
  bcrypt (~> 3.0)
  devise (> 3.5.2, < 5)
  rails (>= 4.2.0, < 6.2)

graphiql-rails (1.7.0)
  railties
  sprockets-rails
graphql (1.12.12)
graphql_devise (0.17.0)
  devise_token_auth (>= 0.1.43, < 2.0)
  graphql (>= 1.8, < 1.13.0)
  rails (>= 4.2, < 6.2)

Steps to reproduce

user = create(:user)

query_string = <<-GRAPHQL
  query {
    user(id: "#{user.id}") {
      firstName
    }
  }
GRAPHQL

auth_headers = user.create_new_auth_token
request.headers.merge!(auth_headers)

post(
  :execute,
  params: {
    query: query_string
  }
)

expect(response).to have_http_status(:ok)
parsed_body = JSON.parse(response.body)
# This is something like {"data"=>{"user"=>{"firstName"=>"Lowell"}}}

# ensure that we're not sending the request in the allowed batch time
sleep(DeviseTokenAuth.batch_request_buffer_throttle + 1.second)

request.headers.merge!(auth_headers) # The old access-token
post(
  :execute,
  params: {
    query: query_string
  }
)

expect(response).to have_http_status(:ok)
parsed_body = JSON.parse(response.body)
# This is still like {"data"=>{"user"=>{"firstName"=>"Lowell"}}}

# I would expect the following expectations to be valid
expect(parsed_body['data']).to be_nil
expect(parsed_body['errors'].count).to eq(1)
expect(parsed_body['errors'].first['message'])
  .to eq('user field requires authentication')

Using Timecop results in the same issue.

Expected behavior

I would expect the second request to return an error.

Actual behavior

The second request returns the requested data.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 21 (21 by maintainers)

Most upvoted comments

No problem, @TomasBarry. I’m closing this one as that appears to be the problem and the issue should be moved to DTA. Feel free to reopen if you run into something else. I might open an issue on DTA if you don’t.

@mcelicalderon, nice. Playing with that commit it looks fine. Will keep digging in on my side I imagine it’s something on the setup we’re doing.

Thanks for digging into this.