# User Api Key 클라이언트가 유효한 auth\_redirect를 등록할 수 있는 가능성

**URL:** <https://meta.discourse.org/t/feasibility-of-allowing-a-user-api-key-client-to-register-a-valid-auth-redirect/312901>\
**Category:** Development\
**Created:** [6월 20, 2024, 4:01오후 UTC](https://meta.discourse.org/t/feasibility-of-allowing-a-user-api-key-client-to-register-a-valid-auth-redirect/312901 "2024-06-20T16:01:11Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![angus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/angus/32/341715_2.png) [@angus](https://meta.discourse.org/u/angus)\
**Post date:** [6월 24, 2024, 7:34오전 UTC](https://meta.discourse.org/t/feasibility-of-allowing-a-user-api-key-client-to-register-a-valid-auth-redirect/312901/4 "2024-06-24T07:34:11Z")

</div>

> [@pmusaraj](#):
>
> 개별 사용자 키의 id와 이름은 등록된 클라이언트의 id와 이름에서 독립적입니다.

이것이 제가 `client_id`를 마이그레이션해야 한다고 생각하는 이유입니다 🙂

현재 `user_api_keys` 테이블은 아마도 두 개의 별도 데이터 모델이어야 할 것, 즉 사용자 API 키와 사용자 API 키 클라이언트를 혼재시키고 있습니다. 현재 방식의 한계를 키 생성 메서드([여기](https://github.com/discourse/discourse/blob/main/app/controllers/user_api_keys_controller.rb#L62))에서 볼 수 있습니다:

```plaintext
# destroy any old keys we had
UserApiKey.where(user_id: current_user.id, client_id: params[:client_id]).destroy_all

key =
  UserApiKey.create!(
    application_name: @application_name,
    client_id: params[:client_id],
    user_id: current_user.id,
    push_url: params[:push_url],
    scopes: scopes.map { |name| UserApiKeyScope.new(name: name) },
  )

```

새로운 키를 생성하려면 `client_id`가 유일하게 유지되도록 동일한 `client_id`를 가진 모든 키를 삭제해야 합니다.换句话说, 현재 데이터 모델은 클라이언트와 키 사이의 1:1 관계를 요구합니다. 이 1:1 관계는 일부 사용 사례에는 유용하지만 다른 사용 사례에는 제한이 됩니다.

실제로 이 1:1 제한이 여러분이 제안한 방식이 작동하지 않을 가능성이 높은 이유입니다.

> [@pmusaraj](#):
>
> 대신 `user_api_key`에 `user_api_key_client_id`라는 컬럼을 추가하는 것이 어떨까요. 관련 클라이언트가 있는 키는 클라이언트에 구성된 리다이렉트를 사용할 수 있고(물론 기존 키는 현재 동작을 유지합니다).

클라이언트가 여러 키에 대해 리다이렉트를 등록하려면 `client_id`의 유일성이 키 자체에서 독립적이어야 합니다. 그렇지 않으면 `client_id`가 등록 작업에서 리다이렉트를 식별하는 데 사용되므로 여러 키에 대한 등록이 작동하지 않습니다.

`client_id`와 `application_name`을 전용 `user_api_key_clients` 테이블로 이동하면 1:1 케이스를 유지하면서 1:N 케이스도 허용할 수 있으며, ActivityPub 목적의 redirect\_uri 등록과 같은 기능이 가능해집니다.

---

_[View the full topic](https://meta.discourse.org/t/feasibility-of-allowing-a-user-api-key-client-to-register-a-valid-auth-redirect/312901)._