Hi - I just switched to the new Ory CLI v1 (the Docker image: oryd/ory). According to the migration guide I should set API keys if I don't want to authenticate via browser (which is what I need, when running on CI). I created a workspace API key as well as a project API key, but I does not seem to work. The CLI will always prompt me with the browser URL that I should visit. This is how I use it:

docker run --rm -p 62100:62100 -e ORY_PROJECT_API_KEY=ory_pat_xxx oryd/ory tunnel --port 62100 --project suspicious-wozniak-by8qc6gqla <http://localhost:42100>

Side note: I can pass in whatever I want for the

ORY_PROJECT_API_KEY

, even when using a wrong key, it will not complain. But when using it with the

ORY_WORKSPACE_API_KEY

, it will actually complain when using a wrong key. But still, when using the correct key, I'm not authenticated and I will receive the browser URL. I also tried adding the

--quiet

flag, but this will get me:

please authenticate the CLI or remove the --quiet flag

- Am I doing anything wrong?

have you tried passing both env vars?

Yes, I tried it like this:

docker run --rm -p 62100:62100 -e ORY_PROJECT_API_KEY=xxx -e ORY_WORKSPACE_API_KEY=xxx oryd/ory tunnel --port 62100 --project suspicious-wozniak-by8qc6gqla --workspace xxx <http://localhost:42100>

But the behaviour is the same, I'm getting the browser URL prompt.

It also looks like the older version (

0.3.4

) was removed from homebrew so users are now downloading an unstable prerelease version by default without any mention of it in the CLI documentation. 0.3.4 can still be downloaded as binary, but I think defaulting to that and removing the prior from brew like that is pretty rough.

well I guess homebrew is the problem as it does not allow you to specify the version and keep multiple around... you should be able to install the old version still using the other install methods mentioned in the docs

it does allow you to keep multiple versions around. https://docs.brew.sh/Versions so I guess homebrew isn’t the problem

sure, I understand the problem, its just not super easy to fix with our release automation (goreleaser -> binaries -> pushed to different places like our brew repo) we also don't really consider brew to be a production but rather a convenience service

Is there anything I can provide to give you some more hints what could be the issue concerning the api-key based authentication? Or is this a known bug maybe?

I guess its easy to reproduce, but it would still help to create a github issue to keep track of it thx

Okay sure, I will do this tomorrow! A short side-question concerning the versioning topic: for the curl-based Linux installation, is it also possible to select a specific version? The install-link uses the master-branch from ory/meta, but I cannot find a possibility to select another version from that.

This is an issue for us as well. We need to run the tunnel using

--quiet

. For now we've pinned to v0.3.4.

Out of curiosity, what are your use cases for this?

We are using the oryd/ory docker image in our local compose setup where we use the ory tunnel feature to bootstrap our environment. We don't want every developer to open a browser to authenticate, it should be done automatically. Same for our CI environment, where we need to start the tunnel in an automated way to run end-to-end testing.

Ok makes sense for e2e testing, for dev environments I'd still highly recommend you to force everyone to login with their personal account. Only then you can revoke the access properly when people are off-boarded. You can persist the Ory config file during reruns, even if the whole container is recreated. Then the token will be stored and reused as long as it is valid. See the

--config

flag help for details.

Thank you, I can confirm that it is working now (when using the

--quiet

flag). But (at least for starting the tunnel) it is necessary to add both API keys as well as the

--workspace

flag. If I only use the

ORY_PROJECT_API_KEY

it will not work. Is it meant to be like this? In the migration guide it says that "Depending on the use-case you might need to use one or both.", so maybe starting the tunnel is one of these use-cases?

tl;dr you need the workspace ID The problem is that we need to look up the project to get the slug, and depending on how you pass the project (ID vs. slug vs. ID prefix vs. slug prefix) we need to list all projects of the workspace to get that, or we need to fetch exactly that project. There is currently an env variable that allows you to pass the slug and avoid the lookup in general, but I'd really like to remove it for consistency.

You mean the

--project

flag to pass the slug? This one is actually also required for me 😄 I need to set both API-keys, the

--project

and the

--workspace

flag to make it work currently.

Yes exactly, because what you can do is

ory tunnel --project 23a2e --workspace 'My workspace name prefix'

So we first need to list workspaces, then list projects of the correct workspace, and then we get the slug of the project.

Okay, thanks for the feedback, then I will pass both flags 👍 It may be worth noting, that I can use the project-slug for the

--project

flag, but for the

--workspace

flag I cannot use the name of the workspace. It really has to be that long UUID.

ah yeah with the api key it has to be the uuid, because the workspace api key cannot get a list of workspaces (yet, hopefully fixed soon)

Okay got it, thank you very much!

np, you're welcome

We are using the oryd/ory docker image in our local compose setup where we use the ory tunnel feature to bootstrap our environment.

This is similar to our use case. We automatically start the tunnel when a dev starts our API service in their dev environment. Every dev has their own project, so we are not worried about revoking access.

you should just be able to omit it