[Bug][API] project check url encoding

[jeffschaper]

Search before asking

• [X] I had searched in the issues and found no similar issues.

What happened

We're rolling out DORA metrics at my company and we chose to use a forward slash (/) as a delimiter in our project naming convention. For example, team/ci/app.

I wrote a Python script to onboard projects to DevLake and part of the logic includes checking to see if the project already exists. The /check endpoint doesn't seem to not be handling url encoding the way I'd expect.

Here's a sample curl request curl http://localhost:8080/api/rest/projects/team%2Fci%2Fapp/check -H "Authorization: Bearer <token>"

The API response returns a 404 HTTP error: 404 page not found

What do you expect to happen

I'd expect the API response to return a json object as described in the API docs

{
  "exist": false
}

How to reproduce

Make a call to the /check endpoint with a project name using %2F to delimit a project name such as team/ci/app

Sample curl request: curl http://localhost:8080/api/rest/projects/team%2Fci%2Fapp/check -H "Authorization: Bearer <token>"

Anything else

The error seems to only be happening in our dev environment. Localhost seems to be handling this scenario without any issues.

Further, the error only happens when I substitute a forward slash (/) for %2F. Single word project names seem to be handled okay in dev.

I think I tracked down the functions responsible:

• https://github.com/apache/incubator-devlake/blob/f99d5bd6145467fda99c49f5bc1af66821e787db/backend/server/services/project.go#L421-L431
• https://github.com/apache/incubator-devlake/blob/f99d5bd6145467fda99c49f5bc1af66821e787db/backend/server/api/project/project.go#L36-L75

Version

v1.0.1@e061ef2

Are you willing to submit PR?

• [X] Yes I am willing to submit a PR!

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[dosubot[bot]]

The issue you're experiencing with URL encoding in the /check endpoint might be related to how the Gin framework handles URL paths. In the code, the UseRawPath setting is enabled, which should allow special characters like %2F to be processed correctly ^[1].

However, since the problem occurs only in your dev environment and not on localhost, there might be differences in configuration or middleware that affect URL handling. Check if there are any discrepancies in the CORS or authentication middleware settings between the two environments ^[1][2].

Additionally, ensure that the server in the dev environment is configured to handle encoded URLs properly. You might want to verify any reverse proxy settings or server configurations that could be affecting the request path.

If these suggestions don't resolve the issue, consider debugging the request handling in the dev environment to see how the path is being interpreted.

To continue talking to Dosu, mention @dosu.

[jeffschaper]

I'll check with my platform team on these questions