A2A 에서 klip result 확인 관련 문의
안녕하세요,
저희가 하려는 것은 다음과 같습니다:
앱에서 버튼을 클릭하면 사용자는 klip 화면으로 넘어가서, 인증을 하고, 해당 결과값을 저희가 받아 앱이 사용하는 db 에 history 를 저장하는 것입니다.
klip 의 결과값을 알기 위해 다음 api 를 사용했습니다:
-
Klip API 사용자가 과도한 네트워크 트래픽을 발생시키는 시도하는 등 불법 혹은 비정상적인 방식으로 API를 사용하려고 시도하는 경우, 사전 고지없이 API 사용이 차단될 수 있습니다.
-
안녕하세요,
질문 주신 내용들에 대해서는 별도로 확인 후 답변드리겠습니다만, "문제가 발생한 케이스"에 대해서는 저희도 따로 확인이 필요할 것 같습니다.
혹시 문제가 되었던 해당 요청의 request key, tx hash, klaytn address (eoa) 를 전달해주실 수 있을까요?
감사합니다.
0 -
답변 감사합니다.
case1 (klay):
tx: 0x69943f61871066e12b413d9bac00436ae2431b78e25d38d341f5a94c9f2fc770
klip 인증으로 보낸 고객: 0xc04f0ddce43726c2e73deebb62559d63108c96ea
case 2 (NFT):
tx:0xaa9ed5ce7ea1e5092bdbdd02066edcdf75b68e310c7aea19a86d27131c7e7dde
klip 인증으로 보낸 고객 : 0xEa3c4884844954B934Ea824Db061c763B5a2b2C0
request key 는 애초에 frontend 에서 klip 이 requested 로 바뀌는것을 못받았고 따라서 서버 call 을 못해서
저장하고 있지 않아 알려드리기가 어려운데 지금이라도 다르게 알 수 있는 방법이 있나요?감사합니다.
0 -
tx 추가드립니다.
0xd471716fa87159eeba08000cea4f12ee509d42b7c23c41b72b104ae73d5151ef
이 외에도 약 10건 정도 있는 것으로 파악됩니다.
추가로 힌트가 있었다면, 해당 문제 겪은 대부분의 사용자들이 klip 의 버벅임을 언급했습니다.감사합니다
0 -
안녕하세요
request key 를 저장하지 않았다고 하셨는데
혹시 [get] /v2/a2a/result api 를 호출했던 기록도 따로 안남기고 있으신건지 궁금합니다그게 아니라면 최초 [post] /v2/a2a/prepare api 를 호출했던 시간을 공유해 주시면 감사하겠습니다
0 -
안녕하세요, 답변 감사합니다.
말씀드렸다시피 초당 몇 번씩 주기적으로 요청을 하고 있는데 그걸 모든 유저에 대해서 다 모아서 저희 서버로 api 콜을 하게 해서 request key 를 저장하는게 부담이 많이 됩니다 :(
그래서 기록을 따로 남기지 않고 있습니다. 저는 그걸 다 저장하는 로드가 크고 불필요하다고 느껴집니다. 일반적으로 남겨야 하는데 저희가 놓친게 혹시 있을까요?
문제 경험했던 유저들은 알고 있으니, 그분들께 핸드폰 고유주소는 받을 수 있을것 같습니다.
(klip 서버에 어떤걸 저장하는지 모르니 해당 tx이 어떤 request key 에서 온건지 특정할 수 있는 뭔가가 있으면 저희가 같이 소통해서 찾아낼 수 있지 않을까 싶습니다.)그리고 1~4부터의 질문들 중에 답변이 가능한게 하나도 없을까요?
저희도 클립 사용을 독려하고 싶어 계속 문의드립니다.
답변 달리면 바로 메일로 볼 수 있으니 즉시 들어오겠습니다.
감사합니다.
0 -
1~4 질문들에 대해 현재 상황에서 우선 가능한 답변을 먼저 드리며
이슈에 대해 정확한 원인 파악이 완료되면 추가적인 답변을 드리도록 하겠습니다.
1. 비밀번호를 다 쳤음에도 klip api 결과가 즉시 requested 를 리턴해주지 않을 수 있는 케이스가 있나요?
해당 이슈는 일반적으로 발생하면 안되는 상태이며 현재 분석중에 있습니다.
2. 해당 api 의 속도가 느려서 사용자가 앱으로 돌아와서 조금 기다렸는데도 requested 상태를 못받을 수 있나요?
api 가 완료되는 즉시 requested 상태로 바뀌는게 맞습니다.
3. 지금 저희가 택한 방법이 적절하지 않다면 어떠한 방법이 있을 수 있을까요?
기본적으로 request key 발급과 결과 확인은 서버에서 하는걸 권장드립니다.
하지만 이는 권장 사항이며 로드가 크고 불필요하다고 느끼신다면 클라이언트에서 하셔도 문제 없습니다.
4. 만약 맞는 방식을 택한거라면, 유저당 초당 몇번 정도의 api call 을 하는게 적절하다고 보시나요?
api 사용 차단의 경우는 해킹시도나 서버 장애가 우려될 정도의 과도한 사용에 대해서 라고 생각하시면 됩니다.
[get] /v2/a2a/result api call 은 각 서비스에서 유저 경험에 맞게 자유롭게 구현하셔도 문제 없습니다.
하지만 klaytn network 가 약 1초에 한번씩 블록을 만들기 때문에 너무 잦은 호출은 무의미 할수 있습니다.
저희의 판단 기준을 공개하면, 그 자체가 공격의 우회 포인트가 될 수 있기 때문에 정확한 기준을 안내해드리긴 어렵습니다.0 -
답변 감사합니다!
1. 일반적으로 발생하는 안되는 상태인데 저희한테서만 발생하는건지 (우리가 잘못 쓰거나 착각해서), 아니면 실제 있고 겪고 계신 문제인건 맞는데 원인분석을 하고 계신건지가 궁금합니다.
2. 1번과 같이, 그렇지 않은 케이스도 본적이 있으신지가 궁금합니다.
3. 서버에서 확인을 할 수 없는 이유는 client 에서 post prepare api 를 부름과 동시에 저희 서버로 'klip 으로 보냈다는' api 호출을 하게 되면 그때 부터 서버는 사용자가 비밀번호를 언제 치는지도 모르는 상황에서 무기한 polling 을 해야합니다. client 가 requested 임을 알려주면 그때 부터는 block 생성만 기다리면 되기 때문에 대기가 가능하지만, 그렇지 않고 사용자가 klip 에 들어갔다가 마음이 바뀌어서 (혹은 otp가 오래걸려서 등등) 인증을 안하거나 하는데 굉장히 오래걸리면 그만큼 서버는 기다려야 합니다. 실시간으로 해주려고 하면요.
그렇지 않으려면, request key 를 서버가 받아다가 10분에 한번씩 받았던 request key 를 처리 해주거나 하는 방법이 있겠지만 실시간으로 반영이 안되므로 현재 선호되는 방식은 아닙니다.
4. 1초 안에 여러번 하는 이유는, client 입장에서는 사용자가 비밀번호를 쳐서 인증 완료 후 저희 앱을 꺼버리면 현재 client 에서 polling 을 하고 있기 때문에 Client 가 서버에게 requested 상태라고 알려줄 수 가 없기 때문입니다.
블록 생성의 문제가 아니라 requested 가 되기만을 기다리는것이기 때문에 klip 에게 요청하는 get api 의 결과를 기다리는 중입니다.
이 문제에 대한 원인 파악을 저희가 어떻게 도울 수 있을까요?
0 -
새로운 케이스가 생겼는데요, 이건 유저말이 백프로 사실인지 확실하게 판단을 못했습니다.
그래도 한번 볼 필요가 있는 케이스 일것 같아서요.
사용자가 klip 비밀번호를 치고 난 후에 서버로 저희 api 콜이 제대로 안됐고, transaction 은 이루어졌습니다. (여기까지는 간혹 발생하는 일이라서 지금 klip 측과 해결하려는 부분)
그런데 그 다음에 다시 다른 nft 를 보내려고 하니 klip 비밀번호를 치지 않고서 바로 전송완료가 떴다고 합니다.
0x540abc128dbb872c0f216743fe73a8609fc2288aca070fcec2706458da43d809
새벽에 있었던 tx 라서 보기 좀 편할 수 있을것 같습니다.
그래서 사용자 입장에서는 한번은 비밀번호 치고 nft 를 보냈고, 한번은 비밀번호 없이 보내게 된 것 같습니다.
0 -
안녕하세요. 문의주신 부분에 대한 답변입니다.
우선 현재 request_key 를 알수 없어 분석에 시간이 걸리는점 양해 부탁드립니다.1. 일반적으로 발생하면 안되는 상태이며 다른 유저들도 발생하고 있는지 광범위 하게 분석중입니다.
동일한 이슈가 다른 유저들도 있을거라 짐작하고 있지만 질문자님이 처음으로 제보해주신건 맞습니다.2. 위와 동일합니다.
3. 네 선호하는 방식으로 구현해주시면 됩니다.
4. 위와 동일하게 선호하는 방식으로 구현해주시면 됩니다.
0 -
답변 감사합니다.
우선 request key 를 서버가 들고 있고 몇 분에 한번씩 klip 에 요청을 보내 완료됐는지 물어보는 식으로 해뒀습니다. 실시간이 아닌 점이 아쉽지만 일단 유저들 transfer 가 안되는 것 보다는 낫다고 판단해서요.
expiration time 이 지난 이후 비밀번호를 넣어도 transaction 안 만드는것 맞죠?
그 부분을 가정하고 작업했습니다.수고 감사드립니다.
0 -
안녕하세요,
혹시 분석하신 내용이 있으실까요?
여전히 같은 상황이 발생하고 있어서요 :(
감사합니다.
0 -
같은 일들이 지속적으로 발생하게되서 죄송합니다.
최근 문제가 발생한 케이스들의 request key 를 알수 있을까요??
0 -
그때 말씀드린것 처럼 request key 는 따로 모으지 않고 있어서, 한다면 이 문제를 찾기 위해 임시로 코드에 넣어서 해야할것 같습니다.
없이는 분석이 오래걸리는건가요 아니면 불가능한건가요?
0 -
해당 request 의 최종 상태값을 알고 싶은데 request key 가 없어 확인이 어려운 상황입니다.
문제가 된 request 들에 대해서 로그를 남겨두시면 도움이 될수 있을것 같습니다.
추가적으로 궁금한 사항인데요
preapred 와 requested 이외 completed, canceled, error 상태가 존재하는데 이 케이스들에 대해서도 처리를 하고 계신지 궁금합니다.
0 -
일단 위에 말씀드렸던 현재 저희가 적용한 workaround 는
receipt 에 tx 가 없으면 기다리고,
tx 가 있으면 해당 tx 가 blockchain 상에서 실제로 committed 됐는지 확인 후 처리를 합니다.몇 분 후에도 receipt 에 tx 가 없다면 비번을 안쳤거나 문제가 있거나 하는 것으로 간주해 실패한 request 라고 봅니다.
그래서 말씀주신 상태들을 굳이 안봐도 된다고 판단했습니다.
혹시 이 방법에 문제가 있을까요?
0 -
말씀하시는 receipt 이 result api 를 호출한 결과이실까요??
0 -
네네 그 pending 등 status 도 들고 있고, tx 도 들고 있는 리턴 값이요
https://a2a-api.klipwallet.com/v2/a2a/result?request_key=${receipt['request_key']}
0 -
최초 prepare api 호출시에 request key 의 expiration time 값이 같이 response 됩니다.
혹시 이 시간이 지난 후에 실패로 간주하시는 건지 궁금합니다.현재 request key 의 expiration time 은 10분으로 설정되어 있습니다.
말씀하신 몇분이 10분 이상일까요??0 -
네 10분인거 알고 있고, 실패로 간주합니다.
지금 문제되는 케이스들 중에서 10분 넘어간 케이스는 없는것으로 알고 있어요.
0 -
제가 아래 처럼 이해했는데 이게 맞을까요?
1. 유저 a2a 호출
2. server 에서 result api 를 호출하며 tx 필드 유무 확인
3. 10분 이상 tx 필드가 없어서 실패로 간주
4. 그러나 실제 tx 는 성공함
0 -
아 우회 방법과 기존에 문제되던 케이스 두 가지를 혼돈하신것 같습니다.
우회 방법 적용 전에 문제 되던 상황:
1. 유저가 a2a 호출, result api 도 호출. return 받은 status 를 확인. (비밀번호 인증 후 앱으로 돌아왔을 때)
2. status가 requested 인 경우 서버 api 호출.
3. 어떤 알 수 없는 케이스들에서 비밀번호 입력 후 앱으로 돌아왔는데 requested 라고 뜨지 않아서 서버 api 호출 하지 않음. 몇 초간 계속 ping 해도 requested 라고 뜨지 않은 것으로 보임 (서버 api 호출이 안됐기 때문에)
우회 방법 적용 후:
1. 유저가 a2a 호출
2. 서버가 result api 호출 해서 tx 필드 유무 확인.
3. 10 분 이상 tx 필드가 없어서 실패로 간주.
까지 맞고, 이렇게 했을 때 문제 되는 케이스는 발견하지 못했습니다.
저희 예상은 어떤 경우에는 비밀번호 입력 후 api 호출 해도 status 가 requested 가 뜨지 않는 것 아닌가 싶어서요.
애초에 자주 발생하는 상황도 아니고, 우회 방법으로는 10분 안에 다시 제대로 처리를 해주기 때문에, 유저들에게 큰 불만은 없어서 어느정도 상황이 일단락 된 상태 입니다.
여전히 언제 이런 상황이 발생하는지 궁금하긴 합니다.
0 -
현재 해당 request id 를 알수 없어 실제로 request 상태가 prepared 에서 requested 로 넘어가지 않았는지 확인이 불가능합니다.
궁금한 사항이 하나 있는데
혹시 기존 처리 방법에서는 status 를 requested 만 확인하셨던 걸까요?
completed 상태는 확인을 안 하셨었는지 알고 싶습니다.0 -
앱 frontend 에서는 prepared 상태인지만 확인하고 prepared 상태만 아니면 무조건 서버로 넘깁니다. 서버에서는 각 상태에 맞게 행동하도록 구현을 했었고요.
저희가 겪었던 케이스는 아예 서버로 api 콜이 안된 경우입니다. 그래서 prepared 에서 넘어가지 않았다고 이해했고요. 그런데 유저는 transfer 가 됐어요.
상태를 frontend 에서 지속적으로 확인을 하게 해봤는데도, (초당 몇 번씩 몇 초간 확인하게) 서버로 콜이 된게 없었습니다.이게 sporadic 하게 수백번 중 한두건 발생하는것 같은데, 저희 쪽에서는 test 할 수 있는 방법이 매번 klip 에 비밀번호를 쳐야만 prepared->requested 로 바뀌기 때문에 손으로 재현이 어렵네요 :(
0 -
Sebastian 님,
이번 주말에 유독 더 발생 케이스 빈도가 높아졌는데, 이 부분 확인 가능한가요?
그리고 tx id 를 통해서 request id 를 아실 수 있는 방법은 없으신가요?
tx id 는 수십개 알려드릴 수 있습니다.0 -
안녕하세요 kevin 님
tx hash 로 남아있는 로그를 확인할수 있습니다. tx hash 를 공유해주시면 확인해보겠습니다.
이전에 서버에서 result api 를 호출하면 문제가 없다고 하셨는데 이 방법으로도 문제가 발생하는 건지 궁금합니다
0 -
답변 감사합니다! 문제가 생겼던 (tx 는 완료됐는데, klip 쪽 response 가 이상했던) tx 는 다음과 같습니다:
0x184bb6f58800beae7bcf59a44148df4c69fc11ac07093fc22ca3a4abe57e6bde
0x06a3ff778c02e5daaeee7619178842f460f4489041fd5feb6251c7c1ea9848d4
0x861c5c9c257431ec69ce7d50358eda78eb139e024241c9b17848563fc873d505
0x04862d6d39c2cd0d7acebfab70d45770695eeb9c27265eebca1a16b0afd3749b
0xffb09280b9509e03114e8aed96f2a34a7ebdadf388e41760f4d5196e8953d417
0x73b69d000834601d6892100123ada43ac5d27fdcaa080a8607bdc811d3565f18txid 를 통해 request id 를 아실 수 있는거죠?
추가로 더 있는데, 일일히 찾아봐야 해서 일단 여기까지 드리겠습니다.그리고 혹시 오해 하실까봐 말씀드리면 지금 저희 예전 app version 을 쓰는 사용자들만 문제가 되고 있는 거고요, 그 분들은 우회 방법을 사용하지 않고 있어서 누락이 생기고 있습니다.
우회 방법 적용 전에 문제 되던 상황:
1. 유저가 a2a 호출, result api 도 호출. return 받은 status 를 확인. (비밀번호 인증 후 앱으로 돌아왔을 때)
2. status가 requested 인 경우 서버 api 호출.
3. 어떤 알 수 없는 케이스들에서 비밀번호 입력 후 앱으로 돌아왔는데 requested 라고 뜨지 않아서 서버 api 호출 하지 않음. 몇 초간 계속 ping 해도 requested 라고 뜨지 않은 것으로 보임 (서버 api 호출이 안됐기 때문에)
우회 방법 적용 후, 새로운 앱 버전 쓰는 유저들 경우에는 requested 라고 뜨지 않아도 몇 분 기다렸다가 다시 result api 호출해서 확인하기 때문에 문제가 없습니다.
0 -
안녕하세요
말씀해주신 tx 들을 확인해본 결과 status 가 모두 completed 상태로 저장 되어있습니다. 또한 result api 를 요청하신 기록에서 requested 상태로 응답이 내려간것도 확인되었습니다.
a2a api 의 status 가 제대로 변하지 않는다고 말씀 주셨는데 현재까지 저희가 분석하였을 때는 a2a request 가 모두 completed 상태로 잘 저장이 되어 있어 a2a api 의 문제가 아닌것으로 판단됩니다.
혹시라도 추가적인 이슈가 있다면 언제든지 연락 부탁드립니다.
0 -
안녕하세요,
확인 감사합니다!
Status 는 당연히 모두 completed 상태로 끝나긴 합니다 결국은.
다만 저희가 처음 request 할 때, 분명 비밀번호를 다 친 상황임에도 불구하고 completed 가 오지 않았다는 부분이 문제인겁니다. 그런 케이스에서 저희가 누락을 겪는거고요.
그래서 a2a api 의 문제라고 생각들어 말씀드립니다.
0 -
안녕하세요
유저가 비밀번호 입력후 a2a 요청을 완료하면 해당 요청의 상태는 requested 가 됩니다.
그 후 tx 가 블록에 반영되고 나면 요청이 completed 상태로 바뀌게 됩니다.
최초 질문시 requested 나 completed 상태로 변경되면 서버로 요청을 한다고 하셨는데 이부분이 문제가 없는지 확인해보시면 좋을거 같습니다.그리고 서버에서 result api 를 호출하여 tx hash 를 받도록 수정하신뒤에는 문제가 발생하지 않았다고 하셨습니다.
tx hash 는 requested 상태일때만 추가되는 값이며 tx hash 와 요청 status 는 한꺼번에 업데이트가 됩니다.
tx hash 를 지금 잘 받고 계시다면 status 를 requested 상태로도 잘 받고 있다는 걸로 간주됩니다.
동일한 a2a api 가 서버에서는 잘 동작하는데 클라이언트에서만 문제가 발생하긴 힘들어 보입니다.추가적으로 말씀하신 tx 들에 대하여 [GET] /v2/a2a/result api 를 호출하신 기록들을 상태별로 정리한 목록입니다.
result api 호출시에 해당 상태들이 응답되었으며 모든 tx 들에 대하여 동일하게 requested 상태에 대한 응답을 받으셨습니다.
completed 상태로 받으신 결과가 없는데 클라이언트에서 최종 상태를 꼭 받을수 있도록 처리하는걸 권장드립니다.
그리고 어떠한 이유로든 result 요청이 중단되는 경우가 있는건 아닌지 확인해 보시면 좋을거 같습니다.0x184bb6f58800beae7bcf59a44148df4c69fc11ac07093fc22ca3a4abe57e6bde
prepared 0번, requested 71 번, completed 0번0x06a3ff778c02e5daaeee7619178842f460f4489041fd5feb6251c7c1ea9848d4
prepared 2번, requested 36번, completed 0번0x861c5c9c257431ec69ce7d50358eda78eb139e024241c9b17848563fc873d505
prepared 0번, requested 289번, completed 0번0x04862d6d39c2cd0d7acebfab70d45770695eeb9c27265eebca1a16b0afd3749b
prepared 0번, requested 46번, completed 0번0xffb09280b9509e03114e8aed96f2a34a7ebdadf388e41760f4d5196e8953d417
prepared 0번, requested 93번, completed 0번0x73b69d000834601d6892100123ada43ac5d27fdcaa080a8607bdc811d3565f18
prepared 0번, requested 28번, completed 0번0 -
안녕하세요,
답변 감사합니다.
네 제가 바로 위에서 completed 라고 했는데, requested/completed 로 봤던게 맞습니다.
서버에서 tx hash 를 잘 받게 되는 이유는 말씀드렷듯, workaround logic을 적용했기 떄문입니다.
https://klipforum.zendesk.com/hc/ko/community/posts/9178934261401/comments/10953236658841
서버에서는 tx hash가 없으면 일단 queue 에 넣고 대기 시키고 있습니다. 몇 분 대기 후 다시 api 날려서 확인하고, 그때 들어있으면 처리하는거라, 서버에서도 같은 문제가 발생한다고 볼 수 있을것 같습니다.
제가 갖고 의심은, 비밀번호를 친 직후에 api 콜을 해도 requested로 바뀌지 않는 case 가 있다는 주장이거든요. 그러나 klip 측에서는 그렇게 생각하시지 않고, 저 또한 제 로컬에서 재현 성공을 하진 못했기 때문에, 다시 한번 제가 놓친 부분이 있는지 확인해보겠습니다.
그리고 client 에서 계속 completed 최종 상태를 기다릴 수는 없는 이유중 하나가, 간혹 blockchain 의 상태가 안좋거나, 쓰시는 노드의 상황이 안좋거나 등등의 이유로 수 초를 requested 에서 completed 로 넘어가지 않는다면 유저가 기다리다가 앱을 꺼버리는 등 행동을 하기 때문에 client 에서 무제한 completed 를 기다릴 수는 없습니다. 그래서 저희가 서버측에서 모든 request-key 에 대해 일단 cache 에 저장해두고 몇 분 후 다시 status check 하는 식으로 처리를 했습니다.
0
댓글을 남기려면 로그인하세요.
댓글
댓글 30개