Define REST API Spec for Consistent Usage of Project Key

[devleejb]

What would you like to be added:
Currently, when sending a request to /yorkie.v1.AdminService/GetDocument, even if the project key is included in the header, the project's name still needs to be included in the request body. This inconsistency makes it challenging for users to interact with the API. To address this issue, it is necessary to define a clear REST API specification that ensures consistent usage of the project key in requests.

Why is this needed:
Having a defined REST API spec will make it easier for users to interact with the API and ensure a more intuitive usage of the project key in requests.

[hackerwins]

Related to #813

[Wu22e]

I'm interested in this issue. Can I work on it?

[krapie]

@Wu22e As always, feel free to discuss with us while designing the specification.

[krapie]

@Wu22e @devleejb how about we discuss about this issue together to decide the spec for implementation?

[devleejb]

It's a good idea!

It seems that we should list up all APIs that can be called with project key.
For example, /yorkie.v1.AdminService/GetDocument, /yorkie.v1.AdminService/GetDocuments, ...

Maybe, we have to discuss about it with this issue(#813).
How about discussing it in discord channel?

[Wu22e]

Secret key validation can be performed for all AdminService APIs except LogIn, SignUp, ChangePassword, and DeleteAccount.

Current Situation

In the authenticate function of yorkie/server/rpc/interceptors/admin.go, the authorization value in the header is used to distinguish between a token and a secret key (priority: token first, then secret key).

If a user token is used in the authorization header for GetProjects, project-level identification is not possible.
If a secret key is used, project-level identification is possible, but it allows access to all projects under that user’s identity.

Proposed Solution:

• Only include the User Token in the Authorization header.
• The project list retrieval API will use the owner ID to fetch all projects with the user token.

1. For single project retrieval, use the x-secret-key in the header to verify if the project corresponding to the secret key matches the requested project name. Specific APIs will pass through an interceptor, e.g. AdminSecretKeyInterceptor.

2. Or, store the project found using x-secret-key in the context and ensure that the project in the request matches the project corresponding to the secret key when fetching projectInfo.

Other methods may also exist, so it would be great to discuss further!

[krapie]

@Wu22e @devleejb @hackerwins Seems like we have lost our conversation afterward. Any thoughts?

[devleejb]

Sorry for the delayed response.

I think it's a good approach to separate the field in the authorization header.

@hackerwins @krapie
What do you think about method 2? Also, I believe we can remove the project_name field if a project secret key exists, as it would be redundant.