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)
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.