Cannot get rowdy to return refresh token

[neverfox]

If I run the docker example, and submit a request with offline_token=true, it doesn't return a refresh token in the response. Same thing if I configure the csv fixture for refresh tokens.

[neverfox]

PROTECTED_RESOURCE="https://www.example.com/protected/resource/"

REALM=http://localhost:8000
SERVICE=https://www.example.com
SCOPE=all

# Build the URL to query the auth server
AUTH_URL="${REALM}?service=${SERVICE}&scope=${SCOPE}&offline_token=true"

# Query the auth server to get a token -- replace the username and password
# below with the value from 1password
TOKEN=$(curl -s --user "mozart:password" "${AUTH_URL}")

# Get the access token from the JSON string: {"token": "...."}
ACCESS_TOKEN=$(echo ${TOKEN} | jq .token | tr -d '"')

# Get the refresh token
REFRESH_TOKEN=$(echo "${TOKEN}" | jq .refresh_token | tr -d '"')

# refresh token is null because it's not in the response
echo $REFRESH_TOKEN

docker-compose.override.yml

version: "2.1"
services:
  rowdy:
    environment:
      ROCKET_ENV: production
    ports:
      - "8000:80"
    volumes:
      - ./cli/test/fixtures:/app/test/fixtures
    command: [./rowdy-cli, noop, test/fixtures/config_noop.json]

[neverfox]

Update: so far, I've tracked the problem down to configuration.refresh_token_enabled() returning false in the route code. Up to that point, the code was doing all of the right things with relation to producing the requested refresh payload. But the config.json is not deserializing to the expected Configuration, which is ending up like this:

Configuration { ..., refresh_token: None }

[neverfox]

The answer is obvious now! The refresh_token is expected to be part of token::Configuration not the top-level Configuration, yet test/fixtures/config_noop.json has it at the top level. I was so focused on the assumption that the config file was valid that I never thought to check that until now. Maybe that's a holdover from before a refactor? In any case, that might suggest that it's a good idea to validate for unexpected config keys as well as expected ones. It also suggests that maybe there are some additional tests that would be useful to catch this kind of thing, i.e. an end-to-end test of the cli server.

I had to change a few other things in the config: A256 -> A256GCM, and adding an extra number to the key vector to make 32 numbers.

[lawliet89]

Thanks for the suggestion. The JSON deserializer ignores unexpected keys. I'll look into improving the documentation and see if I can configure the deserializer to error on unexpected keys.