Is the request here to just change the order of the two clauses?

Is the request here to just change the order of the two clauses?

No. I just made a mistake in the Actual field 🤦🏼 . I have edited it to show the current behavior

There are some cases where we return a 403 with no extra message. We need to make a decision from a security standpoint. If you return a 404, then a user can fish for workspaces that exist. If you return a 403 with no context, you prevent information gain.

It's a usability vs security thing. I'm happy either way, but we've had penn tests in the past mark this information gain as a security vulnerability

I think the security perspective is that we need to avoid communicating that a workspace exists to someone who is not authorized to have access to it. The message "this workspace does not exist, or you do not have access to it" seems to satisfy that. It doesn't provide additional context, but it does make the message more comprehensible to humans.

403 v. 404 I don't think matters as long as it's the same whether the workspace exists or not.

I'm going to argue strongly for 404 in this case. 403 is very surprising when querying your own workspaces. c.f. #2177

Also, pretty sure 404 is the more standard thing to do, e.g. from incognitio, coder/m returns

Request URL: https://github.com/coder/m
Request Method: GET
Status Code: 404 
Remote Address: 192.30.255.112:443
Referrer Policy: strict-origin-when-cross-origin

Why don't we just return 404 on all most 404 cases for now. If it is a security issue, we can come back to it. Is that fair? Because we do a mix of 403/404 in different places atm.

This PR only returns a 403 when trying to fetch a user that does not exist.

Places I return a 404: (#2194)

• Any workspace fetch (by id, by name)
• Any org fetch (by id, by name)
• Template (by id)
• Parameters (by id)

I think we can eval the security implications in the future, but UX wise, a 403 is kind of annoying. Especially considering how we handle deleted query param at the moment (meaning a 403 could just be a deleted workspace).

I know we can do a case by case right now, like the workspace by name in your own "user" namespace will be 404, but by ID is 403. But if we do this now, then how we use the api in the CLI will be result in different behavior based on nuances that are not obvious to the user imo.

404 for everything is a sane default that I support.

403 should be returned if all of the following are true:

1. The request has a valid credential for a valid user (that is, we have an authenticated identity of the user)
2. The user really is not authorized to do what they're trying to do
3. The path component of the URL doesn't contain any identifying information about resources the user shouldn't be able to determine existence of.

c.f. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#client_error_responses

So

This PR only returns a 403 when trying to fetch a user that does not exist.

I believe this should be a 404 as well.

Will 404 all cases for now then.

Fixed! (error is a bit verbose, but that can be improved with the cli error handling in general)

#2194

GET http://127.0.0.1:3000/api/v2/users/me/workspace/testttt?include_deleted=false: unexpected status code 404: Resource not found or you do not have access to this resource
Run 'coder start --help' for usage.