Unable to railway ssh due to unauthorized issue

[gustahrodrigues]

I'm unable to ssh to my container due to unauthorized issue.

$ railway --version
railway 4.6.3

$ RAILWAY_TOKEN="mytoken" railway ssh --project="project-id" --environment="env-id" --service="service-id" -- <any command>
Unauthorized. Please login with `railway login`

I would like to run such a command in a CI mode, that's why railway login might not be a good option.

[JakeCooper]

@Milo123459 Is gonna have a look at this one. Team tokens are now workspace tokens, and those should defs work here (and in all other commands)

[Milo123459]

The API seems to not work with account tokens on the SSH subscription, when specified to the authorization header. It works in regular POST operations. Other subscriptions work.

[jamesmeneghello]

We are also having the same problem, and it's broken several of our CI pipelines (that use a token to use railway ssh).

[jaredLunde]

@jamesmeneghello your issue should be fixed now and if not lmk

[jamesmeneghello]

@jaredLunde working for us, thanks very much!

[arielweinberger]

This is the result of terrible UX/DX. Apparently, in the same screen where you create account tokens, if you select a workspace (as you naturally would, as a responsible engineer who scopes tokens following good practices), you will get the Unauthorized error. You need to select No workspace on the dropdown, then it's properly "account scoped".

It's wild that Railway is so popular, yet the only way to perform basic operations like updating env variable values via CI/CD pipelines is creating an account-wide, user-specific token. And if that user is off-boarded, or belongs to a team member who left the company, your Railway deployments will just stop working?

We used Railway to do most of the heavy-lifting during development, but the team ignoring tickets like this one for 4 months, this one for 6+ months, and I even saw one existing for 2+ years pushed me to decide not to go to production on Railway.

Just hire support engineers to help your users out. This is very deterring.

[ndneighbor]

Hey @arielweinberger, before I get into anything on here, I just want to say that I am sorry first and foremost. We like to pride ourselves about seeing everything from Discord, Slack, and Twitter/X - but we've been behind the ball on our GitHub presence.

If you or anyone else from the Appwrite team reached out over on our support channels... (You'd be eligible for a Slack Connect channel.) I am sure that we would have been able to discuss your go live strategy. That said, your evaluation system is fair, how one does anything is how one does everything. I take responsibility for the response.

Let's get into the meat and potatoes.

When it comes to the scoping and permissions of tokens on Railway, there have been a few evolutions when it comes to account and workspace scoping that we have passed on as debt to the API experience. (Which I am sorry for.) We are targeting improvements to the general role system of how tokens get made but for us to land them, it will take a significant amount of work.

So for us to support the following:

• The only way to perform basic operations like updating env variable values via CI/CD pipelines is creating an account-wide, user-specific token

We would want SCIM provisioning in place where the administration of user provisioning is handled at the org. level and not at the unique account level. For a few customers, we've enabled SSO for their org, this has been a short stopgap so that the security organization can control the API tokens for that org. in a user controlled account. That said, we're tracking the requests that you raised here.

For:

• if you select a workspace (as you naturally would, as a responsible engineer who scopes tokens following good practices), you will get the Unauthorized error. You need to select No workspace on the dropdown, then it's properly "account scoped".

I have raised this to broader team internally as well, we'll try to get some action on it, or use the feedback when we revamp the token experience when it's time.

As for your go live, I am also happy to privately where else we fell short of your expectations. Else, I do believe that @jaredLunde did address the root report here, and feel comfortable closing the ticket if you don't have a response.