Token refused error (again)

I followed the getting started instructions a few times actually to make sure I didn’t leave anything out and each attempt leaves me with the same result - Token-refused error.

I think the main question is why the instructions, including the excitingly simple and relatively new video here: Install The Things Stack LoRaWAN Network Server in 6 minutes using Docker - YouTube
seem to always result in a bunch of localhost artifacts after installation. I know several have asked about this, but it appears this is the root of the problem:

Is there a way to ensure that localhost settings are not provisioned during the getting started guide? Or am I just completely overlooking something?

For what its worth, I’m running a VM on digitalocean with a custom domain using the acme Letsencrypt method per the instructions.

root@tts:~# ttn-lw-stack config | grep localhost
                                        --as.mqtt.public-address="localhost:1883"
                                    --as.mqtt.public-tls-address="localhost:8883"
                           --as.webhooks.downlink.public-address="http://localhost:1885/api/v3"
                                   --console.oauth.authorize-url="http://localhost:1885/oauth/authorize"
                                      --console.oauth.logout-url="http://localhost:1885/oauth/logout"
                                       --console.oauth.token-url="http://localhost:1885/oauth/token"
                                        --console.ui.as.base-url="http://localhost:1885/api/v3"
                                      --console.ui.canonical-url="http://localhost:1885/console"
                                      --console.ui.edtc.base-url="http://localhost:1885/api/v3"
                                       --console.ui.gcs.base-url="http://localhost:1885/api/v3"
                                        --console.ui.gs.base-url="http://localhost:1885/api/v3"
                                        --console.ui.is.base-url="http://localhost:1885/api/v3"
                                        --console.ui.js.base-url="http://localhost:1885/api/v3"
                                        --console.ui.ns.base-url="http://localhost:1885/api/v3"
                                       --console.ui.qrg.base-url="http://localhost:1885/api/v3"
                             --gcs.basic-station.default.lns-uri="wss://localhost:8887"
                    --gcs.the-things-gateway.default.mqtt-server="mqtts://localhost:8881"
                                     --gs.mqtt-v2.public-address="localhost:1881"
                                 --gs.mqtt-v2.public-tls-address="localhost:8881"
                                        --gs.mqtt.public-address="localhost:1882"
                                    --gs.mqtt.public-tls-address="localhost:8882"
                                               --is.database-uri="postgresql://root@localhost:26257/ttn_lorawan_dev?sslmode=disable"
                                  --is.email.network.console-url="http://localhost:1885/console"
                          --is.email.network.identity-server-url="http://localhost:1885/oauth"
                                     --is.oauth.ui.canonical-url="http://localhost:1885/oauth"
                                       --is.oauth.ui.is.base-url="http://localhost:1885/api/v3"
                                                 --redis.address="localhost:6379"

Also, to fix I know there is some combination of envs that can be added to the docker-compose file under the stack service, ie:

environment:
      TTN_LW_OAUTH_AUTHORIZE_URL: https://tts.mydomain.com:1885/oauth/authorize
      TTN_LW_CONSOLE_UI_AS_BASE_URL: https://tts.mydomain.com/api/v3 
      TTN_LW_CONSOLE_UI_IS_BASE_URL: https://tts.mydomain.com/api/v3
      TTN_LW_OAUTH_SERVER_ADDRESS: https://tts.mydomain.com/oauth

But i haven’t been able to find a dependable source for what needs to be fixed, how to translate --console.ui.gcs.base-url into an above docker ready variable, and what localhost value needs to change and what doesnt.

I’ve found smatterings of configs in loose forum posts, but it’s a little bit of a goose chase.

Any suggestions?

Are you replacing “thethings.example.com” with your domain name in the ttn-lw-stack-docker.yml before you start anything at all.

I’ve got to a working server but I have to go back and do it again to sort out some other wrinkles in the instructions that I only picked up from the video - principally changing the oauth secret before running docker-compose run --rm stack is-db create-oauth-client

Thanks for the reply Nick. Yep, changed all the example domains in the config file with a find and replace in VS to make sure I didnt miss any, did that particular step 3 times.

Double and triple checked the oauth client secret between the config file and the docker command you reference as well. That one in particular was something I made sure I did too because that is the only troubleshooting step in the docs here for the token-refused problem (https://www.thethingsindustries.com/docs/getting-started/installation/troubleshooting)

CONSOLE_SECRET="this-should-match-the-yml-file"

SERVER_ADDRESS="tts.mydomain.com"

docker-compose run --rm stack is-db create-oauth-client \

--id console \

--name "Console" \

--owner admin \

--secret "${CONSOLE_SECRET}" \

--redirect-uri "${SERVER_ADDRESS}/console/oauth/callback" \

--redirect-uri "/console/oauth/callback" \

--logout-redirect-uri "${SERVER_ADDRESS}/console" \

--logout-redirect-uri "/console"

Even tried this by hardcoding the console secret and server address into the later lines…

I have it on my todo list to have another go at a fresh install, give me 24 hours to give it a try

I appreciate the help!

Btw, most recently trying this on v3.11.2

No worries, pushes me along to make progress!

Sadly I get the same. Twice.

Plus Data Storage is still not installing.

Meh.

Dangit. Thanks for trying.

This seems to be a pretty common problem that has continued recurring across versions.

Please someone from TTN - any ideas?

1 Like

Is this a problem with the guide and scripts non properly populating the domain across all those remnant localhost settings?

I have a GitHub based install which doesn’t have any Token Refused issue.

But I haven’t looked at the details of the install / initialisation and I’m not sure how productive it would be to try a compare & contrast. My preference is that the stack is a box that I backup the databases whilst I get on with the tricky bits of firmware and data processing.

Hopefully @benolayinka can come up with a scheme for us to work together.

Likewise!

@benolayinka how did you make it look so easy in your video? :grin:

1 Like

Meantime, do you know how to convert these into envs to drop into the docker-compose file?
Is it something like:
CONSOLE_OAUTH_AUTHORIZE_URL=“http://mydomain.com:1885/oauth/authorize” ?

Is that convention true for all the values?

I assume a workaround would be to simple convert all the localhost values into one big list in under the stack service and hope for the best.

@descartes this ended up working for me:

Though not very satisfyingly since I still don’t understand why. It kinda just worked by accident.

1 Like

I think it’s to do with the way docker allocates ports to its various containers, I was having a re-read of the stand alone install instructions the other day and if I’m not mistaken there was a mention of another way to fix it there, good luck :wink:
cheers
H

Hi @mrpher , sorry you’re having trouble with your install. It looks to me like none of the configuration settings are being loaded from ttn-lw-stack-docker.yml.

This will be TTN_LW_CONSOLE_OAUTH_AUTHORIZE_URL, documented here → Configuration | The Things Stack for LoRaWAN

We’ve improved search so hopefully you can find this stuff by searching the docs.

How are you running ttn-lw-stack here? Did you install it separately? The instructions are for running The Things Stack inside Docker, so checking config should look like

docker-compose run stack config | grep localhost

This will run the stack image configured in docker-compose.yml, which is actually ttn-lw-stack -c /config/ttn-lw-stack-docker.yml, as you can see here → https://www.thethingsindustries.com/docs/the-things-stack/host/docker/configuration/

When you run it using ttn-lw-stack in path, it is not configured to look in /config/ttn-lw-stack-docker.yml for configuration settings, so everything defaults to localhost. You could specify the config file using the -c option, but you shouldn’t be running ttn-lw-stack from your system PATH anyway, just from Docker.

Hey @benolayinka thanks for the help!

I’m a little confused by your question though about installing ttn-lw-stack separately? I merely following the instructions from here: Configuration | The Things Stack for LoRaWAN

Which says to set up the folder structure w ttn-lw-stack-docker.yml inside config>stack

From there I changed all the necessary settings within that file (ie, set domains, sendgrid, certs, etc)

Then did the same for docker-compose.yml file (choose postgres, add any additional services, etc)

And finally I did the setup steps listed here: Running The Things Stack | The Things Stack for LoRaWAN

The result with a docker ps is 3 containers - redis, postgres and stack.

I ran ttn-lw-stack config | grep localhost because I saw somewhere on the forums that that would list all the localhosts left behind when running the above steps. However that does make sense that it is not configured to look at the settings in my config>stack>ttn-lw-stack-docker.yml file so it wouldn’t reflect the changes I made in the steps above.

If I run docker-compose run stack config | grep localhost now, with the containers already running the output shows
--console.ui.gcs.base-url="http://localhost:1885/api/v3"

But that is likely because I had to manually add the following to my docker-compose.yml to get rid of the token refused error:

 environment:
      TTN_LW_BLOB_LOCAL_DIRECTORY: /srv/ttn-lorawan/public/blob
      TTN_LW_REDIS_ADDRESS: redis:6379
      # If using CockroachDB:
      # TTN_LW_IS_DATABASE_URI: postgres://root@cockroach:26257/ttn_lorawan?sslmode=disable
      # # If using PostgreSQL:
      TTN_LW_IS_DATABASE_URI: postgres://root:root@postgres:5432/ttn_lorawan?sslmode=disable
      TTN_LW_CONSOLE_UI_AS_BASE_URL: https://tts.mydomain.com/api/v3 
      TTN_LW_CONSOLE_UI_IS_BASE_URL: https://tts.mydomain.com/api/v3
      TTN_LW_OAUTH_SERVER_ADDRESS: https://tts.mydomain.com/oauth
      TTN_LW_IS_OAUTH_UI_CANONICAL_URL: https://tts.mydomain.com/oauth
      TTN_LW_IS_OAUTH_UI_IS_BASE_URL: https://tts.mydomain.com/api/v3
      TTN_LW_APPLICATION_SERVER_GRPC_ADDRESS: tts.mydomain.com
      TTN_LW_DEVICE_CLAIMING_SERVER_GRPC_ADDRESS: tts.mydomain.com
      TTN_LW_CONSOLE_OAUTH_AUTHORIZE_URL: http://tts.mydomain.com:1885/oauth/authorize
      TTN_LW_CONSOLE_OAUTH_TOKEN_URL: http://tts.mydomain.com:1885/oauth/token

I noticed that @benolayinka uses the Enterprise settings in his video.

So I’ll have a quick go at that over lunch

@descartes @benolayinka Unless I missed something, I didn’t notice any core differences in the config examples between open and enterprise. Outside of the obvious like multi-tenant.

And the minor detail of a license key? I’ll soon find out

I’m also using 3.10.3.

And taking lots of snapshots of the VM along the way!

1 Like