Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Admin tokens doesn't seem to work after migration #3959

Open
ideallical opened this issue May 20, 2022 · 4 comments
Open

Admin tokens doesn't seem to work after migration #3959

ideallical opened this issue May 20, 2022 · 4 comments
Labels

Comments

@ideallical
Copy link

Expected behavior:
After migrating data from v4 to v7, I see that the tokens of an ADMIN (role) user have migrated "succesfully" (I see that the user.tokens looks very similair to user.tokens in v4).
I'd expect to be able to do GraphQL requests on v7 with the same admin token.

Actual behavior:
However, I see this error on authenticated requests:

{
    "error": {
        "id": "c2d4d7e0-d843-11ec-9b03-bd65bb011f16",
        "traceID": "c2d489c0-d843-11ec-9b03-bd65bb011f16",
        "code": "TOKEN_INVALID",
        "type": "INVALID_REQUEST_ERROR",
        "message": "TOKEN_INVALID"
    },
    "report": null
}

Even on a request that doesn't require authentication (to get a Story by url) I see this:

{
    "error": {
        "id": "f7c36930-d843-11ec-beb7-69d34046240e",
        "traceID": "f7c209a0-d843-11ec-beb7-69d34046240e",
        "code": "RAW_QUERY_NOT_AUTHORIZED",
        "type": "INVALID_REQUEST_ERROR",
        "message": "RAW_QUERY_NOT_AUTHORIZED"
    },
    "report": null
}

The requests should be fine, as I use the same code but than on localhost and a different admin token, and then it works.

Related Issues:

Versions:

  • Coral 7.0.1
@ideallical ideallical added the bug label May 20, 2022
@ideallical
Copy link
Author

Also; I noticed the value of SINGING_SECRET env (https://docs.coralproject.net/environment-variables#signing_secret) of the new coral talk was different than the old TALK_JWT_SECRET env from v4 (https://legacy.docs.coralproject.net/talk/configuration/#talk-jwt-secret)

However, now that they're the same, the token is still not accepted in the new coral talk, but it is accepted for the coral talk v4 version.

@ideallical
Copy link
Author

Ok, so found the issue.

Turns out that the coral talk v4 tokens, when decode look like this:

{
  "jti": "840fd2b3-xxxxx-47de-ae6a-xxxxxxxx",
  "aud": "talk",
  "pat": true,
  "sub": "dexx6ed-xxxx-4980-b48e-xxxxxxxx1b96",
  "iat": 1527066087
}

But when I create a new token and decode it, it looks like so:

{
  "pat": true,
  "iat": 1653307310,
  "nbf": 1653307310,
  "iss": "bexxx0e0-xxxx-43ec-b060-4cxxxxxab299",
  "sub": "073xxxx8-01d9-463d-ba06-b7046fxxxf6",
  "jti": "ff4xxxx9-a98b-4018-97e7-54xxxxcfd"
}

It boiled it down to that the admin-token in the new coral talk needs to have the tenantId value as iss. Otherwise the token is not accepted.
So I manually added that, with the jwt secret here:
https://jwt.io/

And now the token works.

I'd suggest, for backwards compatibility if the iss field is not provided in the admin-token, then to assume the default tenantId value on the server. Then old admin tokens keep work after the migration.

@tessalt
Copy link
Contributor

tessalt commented May 24, 2022

@ideallical thanks for updating! We'll take a look at this and determine if this is a bug or something we should call out in the docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants