วิธีตรวจสอบสิทธิ์ Apidog CLI: การเข้าสู่ระบบ, โทเค็น และ CI Secrets

ครั้งแรกที่คุณเรียกใช้ apidog run แล้วมันหยุดทำงานพร้อมข้อความ “No access token found” นั่นหมายความว่าคุณได้เจอส่วนหนึ่งของขั้นตอนการทำงานแบบ command-line ที่ไม่มีใครเตือนคุณเกี่ยวกับมัน แฟล็ก, ID สถานการณ์, และ reporter ล้วนคัดลอกจากแท็บได้ง่าย การยืนยันตัวตนเป็นขั้นตอนที่คำสั่งที่คัดลอกมาพังบนเครื่องของคุณ, มีการรั่วไหลของความลับลงในบันทึก, หรือทำงานได้ดีบนแล็ปท็อปของคุณแต่ล้มเหลวใน CI ด้วยเหตุผลที่ข้อความผิดพลาดไม่ได้อธิบายไว้

คู่มือนี้คือคำตอบสำหรับขั้นตอนนี้โดยเฉพาะ Apidog CLI เป็นแพ็คเกจ npm, apidog-cli, ที่รันสถานการณ์การทดสอบ API ที่คุณสร้างไว้ในแอป Apidog ได้โดยตรงจากเทอร์มินัล เนื่องจากสถานการณ์เหล่านั้นอยู่ในบัญชีของคุณ CLI จึงต้องพิสูจน์ว่าได้รับอนุญาตให้ดึงและรันได้ และทำได้ด้วย access token จัดการโทเค็นให้ถูกต้องเพียงครั้งเดียว การรันทุกครั้งหลังจากนั้นจะเป็นคำสั่งสั้นๆ ที่ราบรื่น หากทำผิดพลาด คุณจะต้องต่อสู้กับข้อผิดพลาดการยืนยันตัวตนแบบเดิมในสภาพแวดล้อมที่แตกต่างกันสามแห่ง

เราจะครอบคลุมทุกด้าน: การสร้าง access token, การเข้าสู่ระบบด้วย apidog login, การตรวจสอบว่าคุณเข้าสู่ระบบในฐานะใครด้วย apidog whoami, ตำแหน่งที่จัดเก็บโทเค็น, วิธีที่ apidog run ตัดสินใจว่าจะใช้โทเค็นใด, และส่วนที่ทีมส่วนใหญ่ทำผิดพลาด นั่นคือการจัดการโทเค็นนั้นเป็นความลับใน CI แทนที่จะวางลงในไฟล์ pipeline กลไกการติดตั้งอยู่ในคู่มือแยกต่างหาก; คู่มือนี้มีไว้สำหรับการยืนยันตัวตนเท่านั้น หากคุณยังไม่ได้ติดตั้ง CLI ให้เริ่มต้นด้วย คู่มือการติดตั้ง Apidog CLI จากนั้นกลับมาที่นี่

ทำไม CLI จึงต้องมีโทเค็น

CLI ไม่ได้มีการทดสอบของตัวเอง มันเข้าถึงโปรเจกต์ Apidog ของคุณ ค้นหาสถานการณ์ด้วย ID และรันในแบบเดียวกับที่แอปเดสก์ท็อปทำ การออกแบบนี้เป็นเหตุผลที่มันต้องการการยืนยันตัวตน: สถานการณ์, ค่าสภาพแวดล้อม, การยืนยันทั้งหมดอยู่ในฝั่งเซิร์ฟเวอร์ในบัญชีของคุณ ดังนั้น runner จึงต้องระบุตัวตนก่อนที่เซิร์ฟเวอร์จะส่งข้อมูลเหล่านั้นมาให้

access token คือวิธีที่มันระบุตัวตน โทเค็นนี้ผูกกับบัญชี Apidog ของคุณ ดังนั้นการรันที่ยืนยันตัวตนด้วยโทเค็นของคุณสามารถทำสิ่งที่คุณทำได้: อ่านโปรเจกต์ของคุณ, ดึงสถานการณ์ของคุณ, รันพวกมันกับสภาพแวดล้อมที่คุณกำหนดไว้ นั่นเป็นเหตุผลว่าทำไมโทเค็นจึงเป็นข้อมูลรับรองที่คุณต้องเก็บรักษาอย่างดี ใครก็ตามที่ถือมันสามารถรันสถานการณ์ในฐานะคุณได้ โดยมุ่งเป้าไปที่สภาพแวดล้อมใดก็ตามที่สถานการณ์เหล่านั้นกำหนดไว้ ถือว่ามันเหมือนกับ personal access token สำหรับบริการอื่นๆ

นี่คือการยืนยันตัวตนประเภทที่แตกต่างจากการยืนยันตัวตนที่การทดสอบของคุณดำเนินการ สถานการณ์ของคุณอาจส่ง bearer token หรือ API key ของตัวเองไปยัง endpoint ที่กำลังทดสอบ และนั่นเป็นเรื่องที่แตกต่างกันซึ่งครอบคลุมอยู่ใน วิธีการยืนยันตัวตน API access token ของ CLI ยืนยันตัวตน runner กับ Apidog ข้อมูลรับรองภายในคำขอของคุณยืนยันตัวตนคำขอของคุณกับ API ของคุณ แยกสองสิ่งนี้ให้ชัดเจน เพราะมันอยู่ในที่ที่แตกต่างกันและหมุนเวียนตามตารางเวลาที่แตกต่างกัน

ขั้นตอนที่ 1: สร้าง access token

คุณสร้างโทเค็นใน Apidog ไม่ใช่จาก CLI มีสองที่ที่มันปรากฏขึ้น และคุณจะใช้ที่ใดขึ้นอยู่กับสิ่งที่คุณกำลังทำ

สำหรับโทเค็นที่กำหนดขอบเขตบัญชีของคุณที่คุณจะนำกลับมาใช้ใหม่ในสถานการณ์ต่างๆ ให้เปิดแอป Apidog หรือเว็บคอนโซล คลิกรูปประจำตัวของคุณ และดูภายใต้การตั้งค่าบัญชีของคุณในส่วน API access token

สร้างขึ้นมาหนึ่งอัน คัดลอกทันที และเก็บไว้ในที่ปลอดภัย เช่น password manager โดยปกติคุณไม่สามารถเห็นสตริงทั้งหมดอีกครั้งหลังจากที่คุณออกจากหน้านั้น ซึ่งเป็นเรื่องปกติสำหรับข้อมูลรับรองและเป็นเหตุผลที่ต้องคัดลอกทันทีที่มันปรากฏขึ้น

สำหรับโทเค็นที่ผูกกับสถานการณ์เฉพาะที่คุณกำลังเชื่อมต่อเข้ากับ CI มีเส้นทางที่เร็วกว่า เปิดสถานการณ์การทดสอบ สลับไปที่แท็บ CI/CD เลือกตัวเลือก command-line และคลิกเพื่อสร้าง access token Apidog จะสร้างคำสั่ง apidog run ทั้งหมดให้คุณพร้อมกับโทเค็น, ID สถานการณ์, และ ID สภาพแวดล้อมที่กรอกไว้แล้ว คำสั่งที่สร้างขึ้นนั้นเป็นจุดเริ่มต้นที่เป็นทางการ และการคัดลอกหมายความว่าคุณไม่ต้องพิมพ์ ID ด้วยตนเองเลย คู่มือ Apidog CLI ฉบับสมบูรณ์ จะอธิบายแท็บ CI/CD อย่างละเอียด

ไม่ว่าจะด้วยวิธีใด ผลลัพธ์ก็คือสิ่งเดียวกัน: สตริงโทเค็น สิ่งที่คุณทำกับมันต่อไปคือการเลือกระหว่างสองรูปแบบการยืนยันตัวตน

ขั้นตอนที่ 2: เลือกรูปแบบการยืนยันตัวตนของคุณ

CLI รองรับสองวิธีในการนำเสนอโทเค็น และแต่ละวิธีก็เหมาะกับสถานการณ์ที่แตกต่างกัน

วิธีแรกคือการเข้าสู่ระบบที่จัดเก็บไว้ คุณรัน apidog login เพียงครั้งเดียว CLI จะบันทึกโทเค็นลงในเครื่องของคุณ และทุกๆ apidog run ในภายหลังจะอ่านมันโดยอัตโนมัติ ไม่มีโทเค็นในบรรทัดคำสั่งหลังจากนั้น นี่คือสิ่งที่คุณต้องการบนเครื่องของนักพัฒนาที่คุณใช้ทุกวัน

วิธีที่สองคือแบบต่อคำสั่ง คุณส่ง --access-token ในการเรียก apidog run เอง ซึ่งมักจะมาจากตัวแปรสภาพแวดล้อม ไม่มีสิ่งใดถูกจัดเก็บ โทเค็นจะถูกจัดเตรียมใหม่ทุกครั้ง และมันจะไม่ทิ้งร่องรอยบนดิสก์ นี่คือสิ่งที่คุณต้องการใน CI ที่ runner เป็นแบบชั่วคราวและโทเค็นมาจากความลับ

คุณน่าจะใช้ทั้งสองอย่าง คือการเข้าสู่ระบบที่จัดเก็บไว้ในเครื่องและการใช้ต่อคำสั่งใน pipeline สองส่วนถัดไปจะครอบคลุมแต่ละวิธี

บนเครื่องของคุณเอง เข้าสู่ระบบเพียงครั้งเดียวและลืมเรื่องโทเค็นไปได้เลย แบบฟอร์มแบบโต้ตอบจะแจ้งให้คุณกรอก เพื่อให้สตริงไม่ปรากฏในประวัติ shell ของคุณ:

apidog login

CLI จะขอ access token ของคุณ คุณวางมันลงไป และกด Enter เบื้องหลังมันจะตรวจสอบโทเค็นกับ Apidog ก่อนที่จะบันทึกอะไรลงไป; โทเค็นที่ไม่ถูกต้องหรือหมดอายุจะถูกปฏิเสธทันที แทนที่จะล้มเหลวในภายหลังในการรันครั้งแรก เมื่อสำเร็จ มันจะยืนยันบัญชีที่เข้าสู่ระบบและบอกคุณว่ามันจัดเก็บข้อมูลรับรองไว้ที่ใด

หากคุณต้องการส่งโทเค็นโดยตรง เช่น ภายในสคริปต์การตั้งค่า ให้ใช้แฟล็ก --with-token:

apidog login --with-token YOUR_ACCESS_TOKEN

ข้อควรระวังหนึ่งข้อกับรูปแบบนี้: โทเค็นในบรรทัดคำสั่งจะถูกบันทึกในประวัติ shell ของคุณและสามารถอ่านได้จากรายการกระบวนการในขณะที่คำสั่งทำงาน เลือกใช้ apidog login แบบโต้ตอบสำหรับการใช้งานด้วยตนเอง และสงวน --with-token ไว้สำหรับการตั้งค่าที่ไม่ใช่แบบโต้ตอบที่คุณกำลังอ่านค่าจากตัวแปรที่คุณควบคุม ห้ามใส่โทเค็นจริงลงในสคริปต์ที่คุณ commit เด็ดขาด

โทเค็นไปอยู่ที่ไหน? CLI จะเขียนลงในไฟล์การตั้งค่าภายใต้ไดเรกทอรี .apidog ในโฟลเดอร์หลักของคุณ นั่นคือที่เก็บข้อมูลรับรองในเครื่องบนเครื่องของคุณเอง ซึ่งเป็นประเด็นสำคัญ: โทเค็นจะอยู่บนดิสก์ที่เฉพาะบัญชีผู้ใช้ของคุณเท่านั้นที่สามารถอ่านได้ และ CLI จะหยิบมันขึ้นมาในการรันทุกครั้งในภายหลังโดยที่คุณไม่ต้องพิมพ์ซ้ำ หากคุณอยู่บนเครื่องที่ใช้ร่วมกันหรือเครื่องแบบใช้แล้วทิ้ง ให้ข้ามการเข้าสู่ระบบที่จัดเก็บไว้ และใช้โทเค็นแบบต่อคำสั่งแทน เพื่อไม่ให้มีสิ่งใดคงอยู่หลังจากที่คุณจากไป

ขั้นตอนที่ 4: ตรวจสอบด้วย apidog whoami

หลังจากเข้าสู่ระบบแล้ว ให้ยืนยันว่ามันทำงานได้ก่อนที่คุณจะพึ่งพามัน:

apidog whoami

คำสั่งนี้จะพิมพ์บัญชีที่ CLI กำลังยืนยันตัวตนอยู่ นี่เป็นวิธีที่เร็วที่สุดในการตอบคำถามว่า “ฉันเข้าสู่ระบบแล้วหรือยัง และในฐานะใคร?” โดยไม่ต้องรันสถานการณ์จริง ใช้มันเมื่อการรันล้มเหลวด้วยข้อผิดพลาดการยืนยันตัวตนและคุณไม่แน่ใจว่าปัญหาคือโทเค็นหรือสิ่งอื่นที่ตามมา; หาก whoami แสดงบัญชีของคุณ การเข้าสู่ระบบที่จัดเก็บไว้ก็ใช้ได้ และคุณสามารถมองหาสาเหตุอื่นได้

apidog whoami ยังยอมรับ --access-token หากคุณต้องการตรวจสอบโทเค็นเฉพาะแทนที่จะเป็นโทเค็นที่จัดเก็บไว้ สิ่งนี้มีประโยชน์สำหรับการยืนยันว่าโทเค็น CI นั้นถูกต้องก่อนที่คุณจะเชื่อถือมันใน pipeline: วางโทเค็นลงใน apidog whoami --access-token YOUR_ACCESS_TOKEN แบบครั้งเดียวจากเทอร์มินัลที่ปลอดภัย ดูว่ามันแก้ไขไปเป็นบัญชีของใคร จากนั้นย้ายมันเข้าไปในที่เก็บความลับของคุณ

เมื่อคุณทำเสร็จบนเครื่องที่ใช้ร่วมกัน หรือเมื่อคุณต้องการเปลี่ยนไปใช้บัญชีอื่น ให้ล้างข้อมูลรับรองที่จัดเก็บไว้:

apidog logout

สิ่งนี้จะลบโทเค็นที่บันทึกไว้จากไฟล์การตั้งค่า การรัน apidog run ครั้งถัดไปจะต้องมีการเข้าสู่ระบบใหม่หรือแฟล็ก --access-token ซึ่งเป็นพฤติกรรมที่คุณต้องการหลังจากคืนเครื่องไป

ขั้นตอนที่ 5: apidog run เลือกโทเค็นอย่างไร

เมื่อคุณเข้าใจลำดับที่ runner ตรวจสอบ ข้อผิดพลาด “No access token found” ก็จะไม่เป็นเรื่องลึกลับอีกต่อไป เมื่อคุณเรียกใช้ apidog run CLI จะค้นหาโทเค็นตามลำดับนี้:

แฟล็ก --access-token ที่ส่งมาในคำสั่ง หากมีอยู่
โทเค็นที่จัดเก็บไว้บนดิสก์จากการเข้าสู่ระบบ apidog login ครั้งก่อน

หากไม่พบทั้งสองอย่าง มันจะหยุดและบอกให้คุณรัน login ก่อนหรือส่ง --access-token ลำดับความสำคัญนั้นมีประโยชน์: แฟล็กจะชนะการเข้าสู่ระบบที่จัดเก็บไว้เสมอ ดังนั้นคุณสามารถเข้าสู่ระบบในฐานะตัวเองได้ทุกวันและยังสามารถแทนที่ด้วยโทเค็นอื่นสำหรับการรันแบบครั้งเดียวโดยไม่ต้องออกจากระบบ

ในทางปฏิบัติสิ่งนี้หมายความว่าการรันในเครื่องของคุณสามารถสั้นได้เท่ากับ ID:

apidog run -t 605067 -e 1629989 -n 1 -r cli

ไม่มีโทเค็นในบรรทัดนั้น เพราะการเข้าสู่ระบบที่จัดเก็บไว้จัดเตรียมให้ -t ระบุสถานการณ์ด้วย ID, -e เลือกสภาพแวดล้อม, -n 1 รันหนึ่งครั้ง, และ -r cli พิมพ์รายงานที่อ่านได้ เปรียบเทียบกับรูปแบบ CI ที่คุณส่งโทเค็นอย่างชัดเจนเพราะไม่มีสิ่งใดถูกจัดเก็บไว้:

apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t 605067 -e 1629989 -r junit,cli

คำสั่งเดียวกัน สถานการณ์เดียวกัน แหล่งการยืนยันตัวตนต่างกัน นั่นคือความแตกต่างทั้งหมดระหว่างการยืนยันตัวตนในเครื่องและ CI และส่วนที่เหลือของคู่มือนี้เกี่ยวกับการทำให้ส่วน CI ถูกต้อง สำหรับการอ้างอิงแฟล็กทั้งหมดที่อยู่เบื้องหลังการรันเหล่านี้ คู่มือ Apidog CLI ฉบับสมบูรณ์ ครอบคลุมทุกตัวเลือก

ขั้นตอนที่ 6: จัดการโทเค็นเป็นความลับใน CI

นี่คือจุดที่ทีมมักจะผิดพลาด การแก้ไขคือกฎเดียว: โทเค็นจะอยู่ในที่เก็บความลับของระบบ CI ของคุณ และมันจะเข้าถึงคำสั่งในรูปแบบของตัวแปรสภาพแวดล้อม มันจะไม่ปรากฏในไฟล์ที่ถูก commit, คำนิยาม pipeline ที่ถูกตรวจสอบเข้าสู่ repo, หรือในบันทึกการสร้าง

อย่าเข้าสู่ระบบภายใน CI และอย่าเขียนโทเค็นลงในไฟล์ที่ runner สร้าง ใช้รูปแบบ --access-token แบบต่อคำสั่ง โดยดึงมาจากความลับที่ถูกปิดบังไว้ ทุกตัวอย่างด้านล่างนี้มีรูปแบบเดียวกัน โดยความลับจะถูกตั้งชื่อเพียงครั้งเดียวในแพลตฟอร์ม และอ้างอิงเป็น $APIDOG_ACCESS_TOKEN ในขั้นตอนการรัน

GitHub Actions

จัดเก็บโทเค็นภายใต้ Settings ของ repository ใน Secrets and variables จากนั้นเปิดเผยให้ขั้นตอนผ่าน env:

- name: รันสถานการณ์ทดสอบ API
  run: |
    apidog run \
      --access-token "$APIDOG_ACCESS_TOKEN" \
      -t 605067 \
      -e 1629989 \
      -r junit,cli
  env:
    APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

GitHub จะปิดบังความลับในบันทึกโดยอัตโนมัติ และการส่งผ่าน env จะช่วยให้มันไม่ปรากฏในบรรทัดคำสั่งที่มองเห็นได้ ความล้มเหลวที่พบบ่อยที่สุดที่นี่คือการไม่ตรงกันของชื่อ: คีย์ env, การอ้างอิง ${{ secrets.X }}, และความลับที่คุณสร้างใน Settings ทั้งหมดต้องใช้ชื่อเดียวกัน เวิร์กโฟลว์ทั้งหมด รวมถึงรายงาน artifacts อยู่ใน Apidog CLI ใน GitHub Actions

GitLab CI

จัดเก็บ APIDOG_ACCESS_TOKEN เป็นตัวแปร CI/CD ที่ถูกปิดบังและป้องกัน ภายใต้ Settings ห้ามเก็บไว้ในไฟล์ .gitlab-ci.yml จากนั้นอ้างอิงโดยตรง เนื่องจาก GitLab จะฉีดตัวแปรโปรเจกต์เข้าสู่สภาพแวดล้อมของ job:

api-tests:
  stage: test
  image: node:20
  script:
    - npm install -g apidog-cli
    - apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t 605067 -e 1629989 -r junit,cli

การทำเครื่องหมายตัวแปรว่า “masked” จะบอก GitLab ให้ลบมันออกจากบันทึกงาน; การทำเครื่องหมายว่า “protected” จะป้องกันไม่ให้มันไปอยู่ใน branch ที่ไม่ได้รับการป้องกัน ดังนั้น fork หรือ feature branch จะไม่สามารถดึงข้อมูลออกไปได้

Jenkins

จัดเก็บโทเค็นเป็น Jenkins credential จากนั้นผูกมันในบล็อก environment เพื่อให้พร้อมใช้งานเป็นตัวแปรโดยไม่ต้องพิมพ์ออกมาเลย:

pipeline {
  agent any
  environment {
    APIDOG_ACCESS_TOKEN = credentials('apidog-access-token')
  }
  stages {
    stage('API tests') {
      steps {
        sh 'apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r junit,cli'
      }
    }
  }
}

Jenkins จะปิดบังข้อมูลรับรองที่ผูกไว้ด้วยวิธีนี้ในคอนโซลเอาต์พุต หากคุณสร้าง pipeline ทั้งหมดรอบขั้นตอนนี้นั้น Apidog CLI ใน CI/CD pipeline ครอบคลุมโครงสร้างโดยรอบ

รูปแบบนี้เหมือนกันในทุก runner: ความลับที่ถูกปิดบังในแพลตฟอร์ม, ตัวแปรสภาพแวดล้อมในคำสั่ง, และแฟล็ก --access-token ที่อ่านค่าจากมัน นั่นคือระเบียบวินัยเดียวกันกับที่คุณจะใช้กับข้อมูลรับรองใดๆ ใน pipeline และคุ้มค่าที่จะอ่าน แนวทางปฏิบัติที่ดีที่สุดในการจัดการ API key หากคุณจัดการมากกว่าหนึ่ง

การหมุนเวียนและการเพิกถอนโทเค็น

โทเค็นไม่ได้อยู่ตลอดไป หมุนเวียนมันตามกำหนดเวลาและเพิกถอนทันทีที่อาจมีการรั่วไหล

ในการหมุนเวียน ให้สร้างโทเค็นใหม่ใน Apidog อัปเดตความลับในทุกระบบ CI ที่ใช้มัน และรัน pipeline เพื่อยืนยันว่าโทเค็นใหม่ใช้งานได้ จากนั้นเพิกถอนโทเค็นเก่าจากที่เดิมที่คุณสร้างมัน ในเครื่อง ให้รัน apidog logout ตามด้วย apidog login ด้วยโทเค็นใหม่ ลำดับมีความสำคัญ: อัปเดต CI ก่อนที่คุณจะเพิกถอน มิฉะนั้นคุณจะสร้างไม่สำเร็จระหว่างสองขั้นตอน

เพิกถอนทันทีหากโทเค็นปรากฏในที่ที่ไม่ควร เช่น บันทึก, ภาพหน้าจอ, commit, เทอร์มินัลที่ใช้ร่วมกัน การเพิกถอนจะทำให้โทเค็นไม่ถูกต้องทุกที่ในคราวเดียว ดังนั้น pipeline ใดๆ ที่ยังคงใช้ค่าเก่าจะล้มเหลวอย่างดัง ซึ่งเป็นสัญญาณที่คุณต้องการ การสร้างที่ล้มเหลวสามารถกู้คืนได้; ข้อมูลรับรองสดในบันทึกสาธารณะไม่สามารถกู้คืนได้ สำหรับนิสัยที่กว้างขึ้น แนวทางปฏิบัติที่ดีที่สุดในการหมุนเวียน API key ครอบคลุมความถี่

กับดักที่ละเอียดอ่อนอย่างหนึ่ง: การสร้างโทเค็นใหม่ใน Apidog จะทำให้โทเค็นก่อนหน้านี้ไม่ถูกต้อง หากคุณสร้างใหม่และลืมอัปเดตความลับ CI pipeline นั้นจะเริ่มล้มเหลวด้วยข้อผิดพลาดการยืนยันตัวตน แม้ว่าไม่มีอะไรใน YAML เปลี่ยนแปลง เมื่อการสร้างที่เคยผ่านกลับไม่สามารถยืนยันตัวตนได้ และคุณไม่ได้แตะไฟล์ workflow สิ่งแรกที่ต้องตรวจสอบคือโทเค็นที่สร้างขึ้นใหม่

เมื่อการยืนยันตัวตนล้มเหลว

ข้อผิดพลาดในการยืนยันตัวตนมักจะเกิดจากสาเหตุไม่กี่ประการ นี่คือวิธีแยกแยะมัน

“No access token found.” CLI ไม่พบทั้งแฟล็ก --access-token และการเข้าสู่ระบบที่จัดเก็บไว้ ในเครื่อง ให้รัน apidog login ใน CI ให้ยืนยันว่าความลับถูกป้อนและแฟล็ก --access-token กำลังอ่านค่าจากมัน; ตัวแปรสภาพแวดล้อมที่ว่างเปล่าจะให้ข้อความเดียวกันนี้

“Invalid access token” หรือข้อผิดพลาดในการยืนยันตัวตนกลางการรัน โทเค็นผิด, หมดอายุ, หรือถูกเพิกถอน รัน apidog whoami เพื่อตรวจสอบโทเค็นที่จัดเก็บไว้ หรือ apidog whoami --access-token YOUR_TOKEN เพื่อตรวจสอบโทเค็นเฉพาะ หากทั้งสองอย่างไม่สามารถแก้ไขเป็นบัญชีของคุณได้ ให้สร้างโทเค็นใหม่และเข้าสู่ระบบอีกครั้ง

ทำงานได้ในเครื่อง แต่ล้มเหลวใน CI ความไม่ตรงกันแบบคลาสสิก เครื่องของคุณมีการเข้าสู่ระบบที่จัดเก็บไว้ ดังนั้นการรันในเครื่องจึงสำเร็จ; CI runner ไม่มีอะไรจัดเก็บไว้และพึ่งพิงความลับทั้งหมด ยืนยันว่าชื่อความลับตรงกันทุกประการระหว่างการตั้งค่าแพลตฟอร์มและคำสั่ง และค่าถูกบันทึกโดยไม่มีช่องว่างท้ายหรือขึ้นบรรทัดใหม่ ซึ่งง่ายที่จะเกิดขึ้นเมื่อวาง

“Access denied” ในสถานการณ์เฉพาะ โทเค็นถูกต้อง แต่บัญชีที่อยู่เบื้องหลังไม่สามารถเข้าถึงโปรเจกต์นั้นได้ ตรวจสอบ ID โปรเจกต์และสถานการณ์ และยืนยันว่าบัญชีของโทเค็นมีสิทธิ์เข้าถึงโปรเจกต์นั้น นี่เป็นปัญหาด้านการอนุญาต ไม่ใช่การยืนยันตัวตน; CLI พิสูจน์ว่ามันเป็นใคร เซิร์ฟเวอร์แค่ไม่อนุญาตให้บัญชีนั้นรันสถานการณ์นั้น

โทเค็นไปถึงคำสั่งแต่ build ยังคงรั่วไหล หากคุณเคยเห็นโทเค็นดิบในบันทึก แสดงว่าคุณกำลัง echo มันบางที่ ซึ่งมักจะเป็นบรรทัด debug ที่พิมพ์คำสั่งทั้งหมดหรือสภาพแวดล้อม ปิดบังมัน: พิมพ์ความยาวของโทเค็นเพื่อยืนยันว่ามันถูกป้อนค่า ไม่ใช่ค่าของมัน แพลตฟอร์ม CI ส่วนใหญ่จะแก้ไขความลับที่รู้จักโดยอัตโนมัติ แต่ echo ด้วยมือของคำสั่งทั้งหมดสามารถทำให้สิ่งนี้ล้มเหลวได้

การยืนยันตัวตนเข้ากับเวิร์กโฟลว์ที่ใหญ่ขึ้นได้อย่างไร

การยืนยันตัวตนคือประตูเล็กๆ ที่ทำเพียงครั้งเดียวที่ทำให้ทุกสิ่งทุกอย่างที่ตามมาเป็นไปได้ เมื่อ CLI สามารถพิสูจน์ว่ามันเป็นใคร การรันสถานการณ์ Apidog ก็กลายเป็นคำสั่งเดียว ไม่ว่าจะเป็นในเครื่องภายในลูปแก้ไข-ทดสอบของคุณ ใน CI ทุกครั้งที่มีการ push และแม้กระทั่งภายใน AI coding agent ที่รันการทดสอบให้คุณ รูปแบบสุดท้ายนั้นน่าสนใจหากคุณทำงานกับ agents: วิธีใช้ AI agents สำหรับการทดสอบ API แสดงให้เห็นว่า CLI ที่เข้าสู่ระบบช่วยให้ agent รันสถานการณ์ของคุณและอ่านผลลัพธ์ได้อย่างไร และ Apidog MCP server เชื่อมต่อ specs ของคุณกับ agents เหล่านั้นโดยตรง

โมเดลทางความคิดนั้นง่าย เข้าสู่ระบบเพียงครั้งเดียวบนเครื่องของคุณด้วย apidog login ตรวจสอบด้วย apidog whoami และปล่อยให้โทเค็นที่จัดเก็บไว้ดำเนินการรันในภายหลังทั้งหมด ใน CI ให้ข้ามการเข้าสู่ระบบ เก็บโทเค็นไว้ในความลับที่ถูกปิดบัง และส่งมันแบบต่อคำสั่งด้วย --access-token หมุนเวียนตามกำหนดเวลา เพิกถอนเมื่อมีข้อสงสัย และอัปเดต CI ก่อนที่คุณจะเพิกถอน นั่นคือเรื่องราวการยืนยันตัวตนทั้งหมด และเมื่อจัดการสิ่งนี้แล้ว CLI ก็จะจางหายไปในพื้นหลังซึ่งเป็นที่ที่ test runner ที่ดีควรอยู่

คุณยังคงสร้างสถานการณ์ด้วยภาพใน Apidog และ CLI จะรันมันในที่ที่ไม่มีมนุษย์เฝ้าดู ดาวน์โหลด Apidog เพื่อตั้งค่าสถานการณ์แรกของคุณ จากนั้นชี้ runner ไปที่มัน สำหรับทุกสิ่งที่ runner สามารถทำได้เมื่อได้รับการยืนยันตัวตนแล้ว คู่มือ Apidog CLI ฉบับสมบูรณ์ คือข้อมูลอ้างอิงที่คุณควรเปิดไว้

button