Cant set expiration of robot-account using POST /api/v2.0/projects/{project_name_or_id}/robots

[Sachade]

Expected behavior and actual behavior:
When creating a robot account using the RobotV1 endpoint POST /api/v2.0/projects/{project_name_or_id}/robots there is a property in the model sent as body called expires_at, which seems to be there to be able to set when the robot-account is o expire. Whatever this expires_at is set to it will always create a robot which expires at the same time it was created, making this feature kind of unusable.

Example:

curl -X 'POST' \
  'https://harbor.****.com/api/v2.0/projects/13/robots' \
  -H 'accept: application/json' \
  -H 'X-Is-Resource-Name: false' \
  -H 'authorization: Basic ****** \
  -H 'Content-Type: application/json' \
  -H 'X-Harbor-CSRF-Token: l7KMJLcpEBF3DyY3XoMT4Jv9DQMAukuryckSleGGBtX1DxZKUfg9ys0csCADUXUm/QmMT208AhWp6qufMzOvvQ==' \
  -d '{
  "name": "robot-account-for-test",
  "description": "Trying to set expiration for robot-account",
  "expires_at": 1727647200,
  "access": [
    {
      "resource": "/project/13/repository",
      "action": "pull"
    }
  ]
}'

Gives the response:

{
  "creation_time": "2024-09-20T11:26:09.542Z",
  "id": 1387269,
  "name": "robot$accountapi+robot-account-for-test",
  "secret": "******"
}

And fetching the account above to get the expiration:

curl -X 'GET' \
  'https://harbor.******.com/api/v2.0/projects/13/robots/1387269' \
  -H 'accept: application/json' \
  -H 'X-Is-Resource-Name: false' \
  -H 'authorization: Basic ******'

{
  "creation_time": "2024-09-20T11:26:09.542Z",
  "description": "Trying to set expiration for robot-account",
  "disable": false,
  "duration": 0,
  "editable": true,
  "expires_at": 1726831569, <= Does not match what we sent on creation
  "id": 1387269,
  "level": "project",
  "name": "robot$accountapi+robot-account-for-test",
  "permissions": [
    {
      "access": [
        {
          "action": "pull",
          "resource": "repository"
        }
      ],
      "kind": "project",
      "namespace": "accountapi"
    }
  ],
  "update_time": "2024-09-20T11:26:09.542Z"
}

Steps to reproduce the problem:

1. Create a robot account as a above using POST /api/v2.0/projects/{project_name_or_id}/robots with expires_at set
2. Fetch the created account using Get /api/v2.0/projects/{project_name_or_id}/robots
3. See that the expiration-date on the fetched robot doesnt match the value we created it with
4. Also check the portal in the listing of robot-accounts for the project where the account was added to find out the account is already expired.

Versions:
Please specify the versions of following systems.

• harbor version: v2.11.0-70255684
• docker engine version: containerd://1.7.16

[wy65701436]

it needs to specify the duration in days in the request body, and the expires_at is calculated in the backend.

[Sachade]

Yeah exactly. But the POST /api/v2.0/projects/{project_name_or_id}/robots doesnt care about the duration in the body, instead it just tries to forward the expires_at to the controller

harbor/src/server/v2.0/handler/robotV1.go

Line 71 in 438d4c0

ExpiresAt: params.Robot.ExpiresAt,

This bug has probably been here for a while but it was less obvious until this fix #19829. Since, prior to this, it was using the default-duration when coming from "robotV1" (still not the set expiration). Now it will use "0" which makes it impossible to create a robot-account that actually can be used with this feature.

[wy65701436]

the robotV1 is used for the legacy robot, which has been deprecated. You need to refer the https://github.com/goharbor/harbor/blob/v2.11.0/src/server/v2.0/handler/robot.go.

[Sachade]

Yes, thats probably the best way to go. However, the robotv1 is still there and a change made it missfunctional/unusable without any notice?

Maybe it should be removed from the specs since it cant be used anymore?

[epgtid]

Same Problem that @Sachade .

Is there any plan to fix this issue in future versions or will it be removed from the api. Because the problem is that if it is still accessible and does not work without notification, it wastes a lot of time for administrators.