โซลูชันคีย์ลิขสิทธิ์ในเว็บแอปพลิเคชันวิธีที่ดีที่สุดคืออะไร


14

ฉันถูกนิ่งงันโดยคำขอจากผู้จัดการของฉัน ฉันทำงานเพื่อเริ่มต้นเล็ก ๆ และเราพัฒนาเว็บแอปพลิเคชั่นในอัตราคงที่ด้วยข้อตกลงการบำรุงรักษาสำหรับ บริษัท ขนาดใหญ่มาก รู้เรื่องสยองขวัญเกี่ยวกับวิธีที่ บริษัท ขนาดใหญ่จะจ่ายเงินค่าของพวกเขาไปยังวินาทีสุดท้ายที่เราตัดสินใจว่าเราต้องการที่จะปกป้องตัวเองโดยสามารถใบอนุญาตเว็บแอปพลิเคชันนี้ในแบบที่ถ้าเราไม่ได้รับเงินซอฟต์แวร์ไม่ทำงานอีกต่อไป

ฉันเคยเห็นสิ่งนี้ทำมาก่อนสำหรับแอปพลิเคชันเดสก์ท็อป แต่นี่จะเป็นเว็บแอปพลิเคชันที่พวกเขาจะโฮสต์ภายในและจะไม่สามารถเข้าถึงได้จากอินเทอร์เน็ต

อะไรคือวิธีที่ดีที่สุดในการทำเช่นนี้เราต้องการให้มีขนาดเล็กและต้องการความสามารถในการต่ออายุคีย์ใบอนุญาตที่พวกเขาเผยแพร่

มีใครทำอะไรที่คล้ายกันบ้างไหม? พวกเราหมดความคิดหรือเปล่า? ใครบ้างที่มีข้อเสนอแนะที่ดีกว่า?


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

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

จากนั้นเพียงทำให้มันช้าลงอย่างเจ็บปวด 2 สัปดาห์หลังจากการชำระเงินถึงกำหนด

@ Thorbjørnฮ่า ๆ !! ^ _ ^ สิ่งที่ดึงดูดเช่นนี้ก็คือโครงการนี้เป็นผู้นำการสูญเสียที่จะลองและต่อรองกับธุรกิจเพิ่มเติมกับ บริษัท นี้ คุณภาพสูงสุดมีความสำคัญมากที่สุด ในขณะเดียวกันเราไม่ต้องการเมาอย่างสมบูรณ์ในขณะที่เรากำลังค้นหาหม้อน้ำผึ้ง
maple_shaft

@maple ฟังดูเหมือนแผนธุรกิจที่ไม่ดี จากนั้นฝากเงินไว้กับนักบัญชีและอย่าพิจารณาส่งมัลแวร์

คำตอบ:


9

มีหลายวิธีที่จะใช้บางสิ่งเช่นนี้ แต่นี่เป็นวิธีที่ไม่ควรทำยากเกินไป:

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

จากนั้นเป็นประจำซอฟต์แวร์ของคุณเริ่มดาวน์โหลดไฟล์นี้ (ภาษาฝั่งเซิร์ฟเวอร์ส่วนใหญ่มีให้สำหรับสิ่งนี้) จากนั้นค้นหาไฟล์เพื่อแฮชของรหัสสัญญาอนุญาตที่ติดตั้ง หากพบว่าแอปพลิเคชันรู้ว่าควรจะตายจนกว่าจะลบบัญชีดำ

MD5 หรือความลับที่คล้ายกันรวมถึงความลับควรเพียงพอสำหรับสิ่งนี้ คุณอาจได้รับนักเล่นที่ดีกว่าและให้แอปพลิเคชันส่งคำขอไปยังเว็บไซต์ของคุณและคุณค้นหาในฐานข้อมูลได้ทันที แต่ไฟล์ (สำหรับสิ่งที่ฉันคิดว่าจะเป็นรายการสั้น ๆ ) หวังว่าจะยังคงมีขนาดเล็กและอาจ วิธีที่ง่ายที่สุด

ส่วนที่ยากขึ้นคือการทำให้แอปพลิเคชันไม่ทำงาน ท้ายที่สุดคุณต้องเก็บมันไว้ที่ไหนสักแห่งภายในซึ่งหมายความว่าถ้ามันชัดเจนเกินไปมันอาจล้มล้างได้ง่ายและถึงแม้ว่ามันจะไม่ชัดเจนจนเกินไปก็สามารถย้อนกลับได้อย่างง่ายดายโดยการกู้คืนตารางที่เหมาะสม / file (s) ดังนั้นฉันขอแนะนำวิธีที่สองของการป้องกันเช่นกัน

วิธีนี้จะเก็บ "สด" หรือ "ตาย" (หรือสิ่งที่คล้ายกันพอ) ในตารางหรือไฟล์ แต่แฮชอีกครั้ง สิ่งนี้จะต้องถูกแฮชด้วยเกลือและเวลาของคุณ ทุกครั้งที่แอปพลิเคชันของคุณรันให้ตรวจสอบค่านี้ด้วย "สด" + เกลือ + การประทับเวลาเวอร์ชันที่แฮชแล้วอนุญาตช่วงเวลาที่ถูกต้อง (เช่นหนึ่งวันสองวันหนึ่งสัปดาห์หนึ่งเดือน ฯลฯ ) โปรดจำไว้ว่าช่วงที่ใหญ่กว่านั้นประสิทธิภาพที่ยากขึ้นจะได้รับผลกระทบ) ตราบใดที่สิ่งต่าง ๆ ตรงกัน (หรือพบการแข่งขัน) แอพยังมีชีวิตอยู่ มิฉะนั้นแม้ว่าค่าในไฟล์พิเศษหรือตารางคือ "สด" มันจะยังคงตายหากมีความพยายามที่จะกู้คืนจากการสำรองข้อมูลเพราะการประทับเวลาจะอยู่นอกเกณฑ์ของคุณ

โดยสรุป (สิ่งนี้ถือว่าคุณมีวิธีการตรวจสอบความถูกต้องของรหัสใบอนุญาตเช่นการตรวจสอบหรือวิธีอื่น ๆ )

  • CheckBlacklist
    • แปลงไลเซนส์คีย์เพื่อแฮชด้วยเกลือ
    • ขอไฟล์บัญชีดำจากเซิร์ฟเวอร์
    • แฮชของฉันอยู่ในไฟล์หรือไม่
    • ถ้าใช่ให้เก็บแฮชของ "DEAD" + salt + timestamp (ตัดให้เป็นวันไม่ต้องเก็บชั่วโมง + วัน + นาที)
    • ถ้าไม่ใช่ให้เก็บแฮชของ "สด" + salt + timestamp (trunc'd)
  • IsKeyAlive
    • สร้างแฮชจาก "สด" + เกลือ + การประทับเวลาที่ถูกตัดทอน
    • โหลดแฮช DeadAlive
    • พวกเขาเห็นด้วยไหม
    • ถ้าใช่เราก็ยังมีชีวิตอยู่ ส่งคืน TRUE
    • ถ้าไม่เช่นนั้นเราอาจจะตาย แต่เราอาจยังอยู่ในหน้าต่างเวลา:
      • ลบวันจากการประทับเวลาและทำแฮชซ้ำ
      • เราเห็นด้วยไหมตอนนี้
      • ใช่? ส่งคืน TRUE
      • เพิ่มวันไปที่เวลาประทับและทำแฮชซ้ำ
      • เราเห็นด้วยไหมตอนนี้
      • ใช่? ส่งคืน TRUE
    • ณ จุดนี้เราอยู่นอกช่วงเวลาที่ไม่ตรงกัน ส่งคืน FALSE (ฆ่าแอป)

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


+1 สำหรับคำตอบที่ซับซ้อนอย่างยิ่ง O_o ฉันอาจจะผิด แต่ฉันไม่คิดว่าสิ่งนี้จะต้องค่อนข้างซับซ้อน ฉันไม่ได้แจกจ่าย Microsoft Office นี่เป็นแอปพลิเคชันที่สร้างขึ้นเองสำหรับลูกค้ารายเดียว ปัญหาเดียวกันยังคงอยู่ที่นี่ที่เซิร์ฟเวอร์ที่โฮสต์แอปพลิเคชันนี้อาจไม่สามารถสื่อสารกับบริการภายนอกได้ ฉันไม่เข้าใจว่าทำไมการเข้ารหัสแฮชและเกลือจึงมีความจำเป็นจริงๆ สิ่งที่เราต้องการอย่างแท้จริงคือสวิตช์ฆ่า
maple_shaft

ขอบคุณ ;-) เหตุผลที่ฉันแนะนำให้ใช้แฮชคือเพื่อให้ไม่มีใครดมกลิ่นการจราจรและ / หรือดูรหัส / ตาราง / ไฟล์ที่ลูกค้าของคุณสามารถบอกได้ว่าเกิดอะไรขึ้นในโลกนี้ แฮชหมายถึงไม่มีอะไรที่ไม่มีทั้งสองฝ่ายเข้ามาและลูกค้าไม่น่าจะเข้าใจว่าแฮชนั้นเป็นตัวแทนของคีย์ใบอนุญาตของพวกเขา (ถ้ามันถูกส่งในที่ชัดเจนพวกเขาจะรู้ทันที) ในทำนองเดียวกันก็ลดความจำเป็นในการทำการเข้ารหัสหรือ SSL ใด ๆ ในไฟล์บัญชีดำของคุณ - แฮชด้วยตัวเองหมายถึง zip
Kerri Shotts

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

1
CheckBlacklist: license-server.example.com: no route to hostอะไรนะ เซิร์ฟเวอร์สิทธิ์การใช้งานอาจไม่มีอยู่ในอนาคต - และอย่าบอกฉันว่า บริษัท ของคุณจะยังมีชีวิตอยู่ในอีกยี่สิบปีที่ผ่านมาซึ่งค่อนข้างเป็นไปไม่ได้ทางสถิติ
Piskvor ออกจากอาคาร

1
มีวิธีมากมายในการหลีกเลี่ยงปัญหานี้รวมถึงการไม่ใช้เซิร์ฟเวอร์ของคุณเอง ใช้ Amazon หรือ Google หรืออะไรทำนองนั้น อีกทางหนึ่งคือสร้าง "ความน่าเชื่อถือ" เพื่อตรวจสอบเพื่อที่ว่าหากโฮสต์ไม่ทำงานผู้ใช้สามารถใช้แอปต่อไปได้ ดังที่ฉันพูดถึงในโพสต์มีหลายล้านวิธีที่มันสามารถล้มเหลวได้และเป็นสาเหตุที่แท้จริงว่าทำไมฉันถึงตรวจสอบแบบนี้ ฉันอยากจะเชื่อใจลูกค้ามากกว่ามากับเช็คประเภทนี้ (คีย์ใบอนุญาตด้วยตัวเองฉันจะไป แต่บัญชีดำมันไม่คุ้มค่าความพยายาม IMO.)
Kerri Shotts

4

คำตอบอื่น ๆ ได้ทำหน้าที่ได้ดีในด้านเทคนิค แต่โปรดพิจารณาด้านกฎหมายด้วย

คุณมีสิทธิ์บล็อกแอพของพวกเขาหากพวกเขาไม่จ่ายเงินหรือไม่? หากคุณไม่ได้กล่าวถึงสิ่งนี้ไว้ล่วงหน้าในสัญญาคุณอาจไม่มีสิทธิ์ทำเช่นนั้นแม้ว่าการชำระเงินจะหมดอายุ (เช่นคุณไม่จำเป็นต้องมีสิทธิ์ขายคืนสิ่งที่คุณขาย) นอกจากนี้หลายประเทศมีกฎหมายพิเศษที่ห้ามการ "จัดการโปรแกรมคอมพิวเตอร์" - สิ่งที่คุณทำอาจได้รับการพิจารณาเช่นนี้และอาจทำให้คุณต้องรับผิดทางอาญา

ดังนั้นฉันขอแนะนำให้ปรึกษาเรื่องนี้กับทนายความก่อนเพื่อหลีกเลี่ยงการลงไปในน้ำร้อน

ในท้ายที่สุดมันอาจจะดีกว่าที่จะพึ่งระบบกฎหมาย หากพวกเขาไม่จ่ายเงินเจรจาและถ้าไม่ช่วยก็แค่ฟ้อง ในหลายประเทศการฟ้องร้องนั้นค่อนข้างเจ็บปวดและราคาถูกหากสถานการณ์สัญญามีความชัดเจน (ในเยอรมนีเช่นคุณสามารถรับMahnbescheid ได้น้อยกว่า 20 €)


ความสัมพันธ์แบบนี้ในการตอบคำถามของฉันเกี่ยวกับว่าเราเป็นถั่วหรือไม่ ฉันได้รับความประทับใจที่แตกต่างแม้ว่าฉันจะไม่มีทางเลือกและนี่คือสิ่งที่ผู้บังคับบัญชาของฉันยืนหยัดแม้ว่าจะไม่ได้อยู่ในสัญญา น่าเสียดายที่ฉันอาศัยและทำงานในสหรัฐอเมริกาซึ่งคุณไม่สามารถรับ บริษัท ใหญ่ ๆ ได้แม้ว่าคุณจะพูดถูก พวกเขามีทนายของทนายความที่จะฝังทุกสิ่งในเอกสารนานพอที่จะทำให้เราเลิกกิจการหากพวกเขาต้องการ
maple_shaft

ฉันเห็นด้วยกับ @sleske เกี่ยวกับการใช้ช่องทางกฎหมาย ตรวจสอบให้แน่ใจสัญญาเป็นเสียงแล้วฟ้องพวกเขาหากพวกเขาละเมิดข้อกำหนด หรืออย่างน้อยก็ขู่ว่าจะฟ้อง ในสิ่งที่ฉันได้เห็นจาก บริษัท ขนาดใหญ่พวกเขายินดีจ่ายผู้ขายเพื่อหลีกเลี่ยงการถูกฟ้องร้องหรือละเมิดสัญญา
RationalGeek

@maple_shaft: ไม่มีความคิดเกี่ยวกับสถานการณ์ทางกฎหมายในสหรัฐอเมริกา แต่ฉันหวังว่าสถานการณ์ทางกฎหมายจะไม่สิ้นหวังอย่างที่คุณวาด อย่างไรก็ตามถ้าคุณได้รับคำสั่งให้นำสิ่งนี้ไปใช้ฉันก็จะชี้ให้เห็นถึงปัญหาที่อาจเกิดขึ้น หากคุณยังคงก้าวไปข้างหน้า (เป็นลายลักษณ์อักษรแน่นอน) คุณทำทุกอย่างเท่าที่ทำได้
sleske

จะไม่มีปัญหาในการมีระบบการออกใบอนุญาตแบบ จำกัด เวลาซึ่งเมื่อใบอนุญาตหมดอายุแอพจะไร้ประโยชน์ มี บริษัท มากมายที่ทำธุรกิจทั้งใหญ่และเล็ก - อะโดบีตัวอย่างเช่น
James Snell

2

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


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

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

1

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

สิ่งนี้จะถือว่าคุณไม่ได้หันไปทางแหล่งที่มาเช่นกัน :)


เราจะไม่พลิกข้ามแหล่งที่มา เราจะควบคุมซอร์สโค้ดและแจกจ่ายการเผยแพร่และการแก้ไขข้อบกพร่องตามปกติเมื่อจำเป็น
maple_shaft

1
@maple_shaft: มีความเป็นไปได้ที่จะปฏิเสธการแก้ไขหรืออัปเดตใด ๆ จนกว่าจะได้รับการเรียกเก็บเงินเนื่องจากฉันสงสัยว่าการบำรุงรักษาจะถูกสร้างขึ้นเพื่อซื้อหรือขายครั้งแรกเป็นสิ่งต่อเนื่องโดยมีวันชำระเงินตามปกติ ( ตามปกติ แต่ไม่เสมอไปเป็นรายปี)
Vatine

ในการติดตาม @Vatine สำหรับโครงการก่อนหน้านี้ที่ไม่มีใบอนุญาตที่เข้มงวดเราได้ใช้ข้อบกพร่องเป็นจุดยกระดับเพื่อแยกการชำระเงิน ข้อบกพร่องบางอย่างอาจไม่เกิดอุบัติเหตุโดยสมบูรณ์
คริสโตเฟอร์ Bibbs

@maple_shaft - หากคุณมีลูกค้าเพียงคนเดียว การแก้ปัญหานั้นง่าย อย่าให้การอัปเดตสำหรับโปรแกรมดังกล่าวเว้นแต่ว่ายอดคงเหลือของพวกเขาคือ $ 0
Ramhound

1

เนื่องจากระบบโฮสต์อยู่ภายในโซลูชั่นหลายตัวที่กล่าวถึงข้างต้นเกี่ยวข้องกับการสื่อสารกับเซิร์ฟเวอร์ระยะไกลอาจไม่ทำงาน

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

โปรดทราบว่าหากคุณใช้ PHP โค้ดจะพร้อมใช้งานสำหรับผู้ใช้ในการแก้ไขดังนั้นไม่ว่าคุณจะใส่ความปลอดภัยประเภทใดผู้ใช้สามารถเข้าไปและลบมันได้อย่างง่ายดาย หากคุณใช้ ASP.NET หรือภาษาที่คอมไพล์อื่น ๆ นี่ไม่ใช่ข้อกังวลเนื่องจากไม่สามารถแก้ไขรหัสได้


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

ฉันเดาว่าแม้จะมีภาษาที่คอมไพล์แล้วส่วนใหญ่เช่นจาวาจาวาก็สามารถรวบรวมปรับปรุงอัพเดทคอมไพล์แล้วรวมเข้ากับสงครามได้ง่ายดังนั้นคนเราจะจัดการได้อย่างไร
Sudarshan

1

(การเปิดเผย - ฉันทำงานให้กับ Agilis Software ซึ่งเป็นผู้ให้บริการระบบจัดการสิทธิ์ใช้งาน)

ทางออกที่มีประสิทธิภาพมากที่สุดคือการเปิดใช้งานผลิตภัณฑ์อัตโนมัติด้วยสัญญาเช่าลิขสิทธิ์ สิ่งนี้ช่วยให้คุณ:

  • เปิดใช้งานสิทธิ์ใช้งานของลูกค้าโดยอัตโนมัติ ณ เวลาเปิดใช้งานแต่ละอินสแตนซ์จะถูกล็อคโดยอัตโนมัติตามพารามิเตอร์ที่คุณเลือกของระบบเป้าหมายและข้อ จำกัด สิทธิ์การใช้งานที่คุณตั้งไว้สำหรับแอปพลิเคชันของคุณ (เช่นการกำหนดค่าคุณสมบัติการตั้งค่าการทดลองโดยรวม
  • ตั้ง 'ช่วงเวลาการเช่า' ซึ่งเป็นช่วงเวลาที่มีผลใช้ได้สูงสุดของเหตุการณ์การเปิดใช้งานใด ๆ สำหรับลูกค้าที่มีเครดิตต้องสงสัยคุณสามารถตั้งค่านี้ให้พูดสองสัปดาห์ซึ่งหมายความว่าทุกสองสัปดาห์ที่แอปของคุณจะ 'โทรกลับบ้านโดยอัตโนมัติ' ในพื้นหลังเพื่อตรวจสอบใบอนุญาตอีกครั้ง หากพวกเขาค้างชำระกับการชำระเงินคุณสามารถปิดการใช้งานใบอนุญาตของพวกเขาในเซิร์ฟเวอร์ที่โฮสต์และมันจะหยุดทำงานในโทรศัพท์บ้านต่อไป
  • หากไม่มีการเชื่อมต่อเครือข่ายจากระบบเป้าหมายจะมีกระบวนการเปิดใช้งานบริการตนเองของผู้ใช้ผ่านการแลกเปลี่ยนไฟล์ที่เข้ารหัสที่เว็บเทอร์มินัลใด ๆ หากผู้ใช้ของคุณอยู่ในตำแหน่งนี้คุณอาจต้องการทำให้ช่วงเวลาการเช่าใช้เวลานานขึ้นเพื่อสร้างสมดุลระหว่างความไม่สะดวกกับความต้องการในการรับเงินของคุณ เมื่อพวกเขาจ่ายเงินคุณสามารถกำหนดช่วงเวลาการเช่าได้นานเท่าที่คุณต้องการ
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.