วิธีหลีกเลี่ยงการบล็อกเบราว์เซอร์ของ WeChat ในการทำ Web to App Routing

จะหลีกเลี่ยงการบล็อกเบราว์เซอร์ของ WeChat เพื่อเปิดแอปได้อย่างไร? การเปิดแอปจากเบราว์เซอร์ภายในแอป (in-app browser) ของ WeChat จำเป็นต้องมีหน้าเปลี่ยนเส้นทางจากเว็บไปแอปที่สามารถรับรู้สภาพแวดล้อมของคอนเทนเนอร์ (container-aware) ซึ่งทำหน้าที่ตรวจจับสภาพแวดล้อมการเรียกดูและแสดงตัวเลือกการเปิดใช้งานที่ผู้ใช้เป็นผู้ริเริ่มและได้รับการสนับสนุนจากแพลตฟอร์ม บน iOS Universal Link ที่รองรับอาจเปิดแอปที่ติดตั้งไว้ได้เมื่อเบราว์เซอร์โฮสต์อนุญาต บน Android Intent URI ที่ผ่านการทดสอบแล้วอาจให้บริการเบราว์เซอร์ภายนอกหรือการส่งต่อแอป พร้อมกับหน้าดาวน์โหลด HTTPS ปกติเป็นตัวสำรอง ไม่มี URL การเปลี่ยนเส้นทางใดที่สามารถรับประกันได้ว่า WeChat จะอนุญาตให้ส่งต่อได้ในทุกเวอร์ชันของไคลเอนต์

การบล็อกเบราว์เซอร์ภายในแอปเกิดขึ้นเมื่อแพลตฟอร์มโซเชียลแบบปิดจำกัดไม่ให้คอนเทนเนอร์เว็บแบบฝังสามารถเรียกใช้ custom URL scheme ของบุคคลที่สามหรือดำเนินการดาวน์โหลดไฟล์แพ็กเกจโดยตรง การจัดการกับข้อจำกัดเหล่านี้ในเส้นทางเว็บไปแอปจำเป็นต้องปรับใช้สถาปัตยกรรมการส่งผ่านที่รับรู้คอนเทนเนอร์ ซึ่งใช้ประโยชน์จาก Universal Links ที่แพลตฟอร์มรองรับบน iOS และการส่งต่อเบราว์เซอร์ที่ผู้ใช้เป็นผู้ริเริ่มบน Android พร้อมทั้งรักษาความสมบูรณ์ของพารามิเตอร์แคมเปญไว้

อุปสรรคของระบบนิเวศแบบปิด: ทำความเข้าใจการทำแซนด์บ็อกซ์ของเบราว์เซอร์ภายในแอป

กำแพงทางเทคนิค: วิธีที่ WeChat ดักจับ Custom URL Schemes และการดาวน์โหลดตามอำเภอใจ

แอปพลิเคชันรับส่งข้อความบนมือถือ โดยเฉพาะ Tencent WeChat (MicroMessenger) ฝังคอนเทนเนอร์การเรนเดอร์เว็บที่ปรับแต่งเองไว้ภายในแอปพลิเคชันไคลเอนต์ เมื่อผู้ใช้แตะลิงก์เว็บภายในเซสชันแชท ฟีดช่วงเวลา (moment feed) หรือบัญชีทางการ ลิงก์นั้นจะโหลดภายในเบราว์เซอร์ภายในของ WeChat แทนที่จะส่งต่อคำขอไปยังเบราว์เซอร์เริ่มต้นของระบบปฏิบัติการ (เช่น Mobile Safari หรือ Google Chrome)

ขึ้นอยู่กับเวอร์ชันไคลเอนต์ของ WeChat, ระบบปฏิบัติการ และนโยบายการนำทางของโฮสต์ custom URL scheme ที่ลงทะเบียนโดยแอปพลิเคชันภายนอกอาจถูกดักจับหรือบล็อก นอกจากนี้ คำขอให้ดาวน์โหลดไฟล์ APK โดยตรงยังอาจถูกจำกัด ทำให้ไม่สามารถดำเนินการดาวน์โหลดหรือติดตั้งตามที่คาดไว้ได้ นักพัฒนาควรตรวจสอบพฤติกรรมการส่งต่อที่รองรับบนอุปกรณ์ที่เป็นตัวแทนและเตรียมทางเลือก HTTPS ที่เข้าถึงได้

ความเป็นจริงของคอนเทนเนอร์: การทำแซนด์บ็อกซ์ของ Apple WebKit เทียบกับการใช้งาน Android XWeb

สถาปัตยกรรมทางเทคนิคเบื้องหลังของเบราว์เซอร์ภายในแอปมีความแตกต่างกันอย่างมากในแต่ละระบบปฏิบัติการ ซึ่งกำหนดพฤติกรรมการดักจับที่แตกต่างกัน:

• สภาพแวดล้อม iOS: บน iOS ทาง WeChat จะฝังเฟรมเวิร์ก WKWebView ของ Apple แม้ว่า WebKit จะบังคับใช้การทำแซนด์บ็อกซ์กระบวนการมาตรฐานของ iOS แต่ WeChat ก็ใช้งานตัวดักจับ WKNavigationDelegate ที่ปรับแต่งเอง เมื่อหน้าเว็บร้องขอการดำเนินการนำทางที่เกี่ยวข้องกับสคริปต์โปรโตคอลแบบกำหนดเอง WebKit จะมอบหมายการตัดสินใจให้กับแอปพลิเคชันโฮสต์ ซึ่งช่วยให้คอนเทนเนอร์สามารถจัดการคำขอที่ไม่ใช่ HTTP/HTTPS ตามนโยบายแพลตฟอร์มของตนได้
• สภาพแวดล้อม Android: บน Android เบราว์เซอร์แบบฝังของ WeChat อาจจำกัดการดาวน์โหลดไฟล์ APK โดยตรงหรือการจัดการการดาวน์โหลดภายนอก ทั้งนี้ขึ้นอยู่กับเวอร์ชันของไคลเอนต์ นโยบายความปลอดภัยของโฮสต์ และลักษณะการตอบสนอง ดังนั้นลิงก์ APK จึงอาจไม่สามารถเริ่มกระบวนการดาวน์โหลดตามที่คาดไว้ได้ นักพัฒนาควรตรวจสอบการตอบสนองบนอุปกรณ์ที่เป็นตัวแทนและเตรียมเบราว์เซอร์ภายนอกที่ได้รับการอนุมัติหรือสำรองข้อมูลผ่าน HTTPS ในส่วนที่รองรับ

ต้นทุนของแรงเสียดทานจากการทำด้วยตนเอง: การประเมินอัตราการสูญเสียผู้ใช้จากข้อความแจ้งในเมนุมุมขวาบน

เพื่อหลีกเลี่ยงการบล็อกของเบราว์เซอร์ภายในแอป แคมเปญการตลาดแบบเดิมมักพึ่งพาเลเยอร์โมดัลคงที่ที่แสดงลูกศรชี้ไปที่มุมขวาบนของหน้าจอพร้อมคำแนะนำ: “แตะปุ่มเมนูแล้วเลือก ‘เปิดในเบราว์เซอร์’ (Open in Browser)”

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

เหตุใด WebViews ของการรับส่งข้อความโซเชียลจึงระงับ Custom URL Schemes

ความปลอดภัยและการควบคุมการผูกขาด: การป้องกันฟิชชิ่ง, การคลิกแจ็กกิ้ง และการรั่วไหลของการรับส่งข้อมูล

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

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

กลไกทางเทคนิค: วิธีที่ shouldOverrideUrlLoading และนโยบายการนำทางของ WebKit ดรอปสคริปต์

ในระดับโค้ด การบล็อกเบราว์เซอร์ภายในแอปจะดำเนินการผ่านตัวแทนการดักจับการนำทางแบบเนทีฟที่มีให้โดยเฟรมเวิร์กของระบบปฏิบัติการเบื้องหลัง:

ในการใช้งาน WebView ของ Android แอปพลิเคชันโฮสต์จะเขียนทับการเรียกกลับ (callback) shouldOverrideUrlLoading ภายใน WebViewClient:

// ตัวแทนเชิงแนวคิดของการดักจับเว็บวิวภายในแอป
@Override
public boolean shouldOverrideUrlLoading(WebView view, String url) {
    if (url.startsWith("http://") || url.startsWith("https://")) {
        // อนุญาตการนำทางเว็บมาตรฐานภายในคอนเทนเนอร์
        return false; 
    }
    // บล็อกโปรโตคอลที่ไม่ใช่มาตรฐาน (custom URL schemes เช่น myapp://)
    Log.w("InAppBrowser", "ดักจับสคริปต์ของบุคคลที่สาม: " + url);
    return true; // ขัดจังหวะการส่งมอบโปรโตคอลของระบบ
}

บน iOS วิธีการ WKNavigationDelegate webView(_:decidePolicyFor:decisionHandler:) จะดำเนินการตรวจสอบที่เทียบเท่ากัน หากสคริปต์ URL ที่ร้องขอไม่ตรงกับ http หรือ https ตัวจัดการการตัดสินใจจะเรียกใช้ WKNavigationActionPolicy.cancel ซึ่งป้องกันไม่ให้ iOS ส่ง URI ไปยังตัวจัดการโปรโตคอลของระบบ

ข้อจำกัดการดาวน์โหลด APK โดยตรง: เหตุใด URL ของ APK แบบเนทีฟจึงแสดงหน้าจอว่างเปล่าในคอนเทนเนอร์โซเชียล

เมื่อเบราว์เซอร์มาตรฐานพบ URL ที่ให้บริการไฟล์ APK เบราว์เซอร์จะตรวจสอบส่วนหัวการตอบสนอง HTTP Content-Disposition: attachment หรือส่วนหัว Content-Type และส่งสตรีมไบต์ขาเข้าให้กับコンポーネント (องค์ประกอบ) การดาวน์โหลดของระบบตามนโยบายการดาวน์โหลดของตน

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

ผลกระทบต่อการระบุแหล่งที่มาทางการตลาดและการมีส่วนร่วมกับแอปปลายทาง

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

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

สถาปัตยกรรมทางเทคนิคสำหรับการเปลี่ยนผ่านเบราว์เซอร์ภายในแอปที่เป็นไปตามข้อกำหนด

โทโพโลยีการเปลี่ยนเส้นทางสองขั้นตอน: ผู้ใช้คลิก ──> หน้าเปลี่ยนเส้นทาง ──> เปิดระบบ

เพื่อจัดการเส้นทางการนำทางที่รองรับในขณะที่เคารพนโยบายของโฮสต์ สถาปัตยกรรมวิศวกรรมการเติบโตจึงปรับใช้โทโพโลยีการเปลี่ยนเส้นทางผ่านสองขั้นตอน

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

[ผู้ใช้แตะลิงก์ในแชทโซเชียล] ──> โดเมนส่งผ่าน (ตรวจสอบคอนเทนเนอร์)
                                         │
                                         ├──> iOS: Universal Link ที่มีสิทธิ์ ──> แอปหรือสำรองข้อมูลผ่าน HTTPS
                                         │
                                         └──> Android: Intent Handoff ที่รองรับ ──> ดาวน์โหลดภายนอกหรือสำรองข้อมูล

การตรวจสอบคอนเทนเนอร์ฝั่งไคลเอนต์: การตรวจจับสตริง User-Agent ของ MicroMessenger

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

Tencent WeChat แทรกโทเค็น MicroMessenger พร้อมกับข้อมูลเมตาของเวอร์ชันลงในสตริง User-Agent ทั้งบนแพลตฟอร์ม iOS และ Android:

• ตัวอย่าง User-Agent ของ WeChat บน iOS: ... MicroMessenger/8.0.38(0x1800262c) NetType/WIFI Language/en ...
• ตัวอย่าง User-Agent ของ WeChat บน Android: ... Mobile Safari/537.36 MMWEBID/8821 MicroMessenger/8.0.37.2380(0x2800255b) ...

ตัวอย่างโค้ดการใช้งานด้านล่างนี้แสดงวิธีตรวจสอบคอนเทนเนอร์โซเชียลภายในแอปโดยใช้กฎ User-Agent แบบฮิวริสติก และดำเนินการเปลี่ยนเส้นทางผ่านแบบมีเงื่อนไขอย่างปลอดภัย:

<!-- สคริปต์การตรวจจับเว็บวิวภายในแอปและการเปลี่ยนเส้นทางฝั่งฟร้อนท์เอนด์ -->
<!-- ไฟล์: transit_router.html -->

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>กำลังเปลี่ยนเส้นทางแอปพลิเคชัน...</title>
    
    <style>
        body {
            font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif;
            background-color: #f8f9fa;
            color: #333;
            text-align: center;
            padding: 40px 20px;
        }
        .loading-card {
            background: #ffffff;
            border-radius: 12px;
            padding: 24px;
            box-shadow: 0 4px 12px rgba(0,0,0,0.05);
            max-width: 400px;
            margin: 0 auto;
        }
        .btn-download {
            display: inline-block;
            background-color: #007aff;
            color: #ffffff;
            padding: 12px 24px;
            border-radius: 24px;
            text-decoration: none;
            font-weight: 600;
            margin-top: 16px;
        }
        .link-fallback {
            display: block;
            margin-top: 16px;
            font-size: 13px;
            color: #666;
            text-decoration: underline;
        }
    </style>
</head>
<body>

    <div class="loading-card">
        <h2>กำลังเปิดแอปพลิเคชัน...</h2>
        <p id="status-text">กำลังตรวจจับสภาพแวดล้อมเบราว์เซอร์และเตรียมการนำทาง</p>
        <!-- ลิงก์หลักที่เข้าถึงได้โดยเจ้าของเดียว ปลายทาง href อัปเดตแบบไดนามิกด้วยพารามิเตอร์คิวรีที่ผ่านการสุขาภิบาลแล้ว -->
        <a id="app-launch-btn" class="btn-download" href="https://app.example.com/download">เปิดแอปพลิเคชัน</a>
        <!-- ลิงก์สำรอง HTTPS สำรองที่มองเห็นได้หากการจ่าย Intent ถูกปฏิเสธโดยคอนเทนเนอร์โฮสต์ -->
        <a id="browser-fallback-link" class="link-fallback" href="https://app.example.com/download">ไปยังหน้าดาวน์โหลดต่อ</a>
    </div>

    <!-- รวม SDK เว็บ JS อย่างเป็นทางการของ OpoInstall (ตรวจสอบสำหรับรุ่นที่ปรับใช้ของคุณ) -->
    <script src="https://web.cdn.opoinstallcloud.com/openinstall.js"></script>
    <script>
    (function() {
        // ขั้นตอนที่ 1: การตรวจจับคอนเทนเนอร์ไคลเอนต์แบบฮิวริสติก
        var ua = navigator.userAgent || "";
        var isInWeChat = /MicroMessenger/i.test(ua);
        var isAndroid = /Android/i.test(ua);
        var isIOS = /iPhone|iPad|iPod/i.test(ua);

        var statusText = document.getElementById("status-text");
        var launchBtn = document.getElementById("app-launch-btn");
        var fallbackLink = document.getElementById("browser-fallback-link");

        // ขั้นตอนที่ 2: การสุขาภิบาลอินพุตที่สอดคล้องกับ OWASP สำหรับพารามิเตอร์คิวรี
        function getSanitizedQueryParams() {
            var allowedKeys = new Set([
                "utm_source",
                "utm_medium",
                "utm_campaign",
                "inviter_id",
                "promo_code"
            ]);

            var result = Object.create(null);
            
            try {
                var query = new URLSearchParams(window.location.search);
                var validPattern = /^[A-Za-z0-9_.-]{1,64}$/;

                query.forEach(function(value, key) {
                    if (allowedKeys.has(key) && validPattern.test(value)) {
                        if (!Object.prototype.hasOwnProperty.call(result, key)) {
                            result[key] = value;
                        }
                    }
                });
            } catch (e) {
                return Object.create(null);
            }

            return result;
        }

        // ตัวช่วย: แปลงพจนานุกรมคีย์-ค่าที่ผ่านการสุขาภิบาลแล้วกลับเป็นสตริงคิวรี URL ที่ปลอดภัย
        function buildQueryString(params) {
            var parts = [];
            for (var key in params) {
                if (Object.prototype.hasOwnProperty.call(params, key) && params[key]) {
                    parts.push(encodeURIComponent(key) + "=" + encodeURIComponent(params[key]));
                }
            }
            return parts.length > 0 ? "?" + parts.join("&") : "";
        }

        var campaignData = getSanitizedQueryParams();
        var sanitizedQueryString = buildQueryString(campaignData);

        // ขั้นตอนที่ 3: กำหนดค่าเป้าหมายสำรองพื้นฐานพร้อมพารามิเตอร์คิวรีที่ผ่านการสุขาภิบาล
        var baseFallbackUrl = "https://app.example.com/download" + sanitizedQueryString;

        // ตรวจสอบให้แน่ใจว่าลิงก์สำรองรองที่มองเห็นได้ชี้ไปที่ปลายทาง HTTPS ที่ได้รับอนุมัติ
        if (fallbackLink) {
            fallbackLink.href = baseFallbackUrl;
        }

        if (launchBtn) {
            if (isInWeChat) {
                if (statusText) {
                    statusText.innerText = "ตรวจพบโซเชียลคอนเทนเนอร์ แตะด้านล่างเพื่อเปิดแอปพลิเคชันหรือดาวน์โหลด";
                }

                if (isAndroid) {
                    // กำหนดค่าตัวอย่าง Intent URI ที่กำหนดเป้าหมายไปที่ Chrome พร้อม URL สำรอง HTTPS ที่ผ่านการสุขาภิบาล
                    var encodedFallback = encodeURIComponent(baseFallbackUrl);
                    launchBtn.href = "intent://app.example.com/open" + sanitizedQueryString + "#Intent;scheme=https;package=com.android.chrome;S.browser_fallback_url=" + encodedFallback + ";end";
                } else if (isIOS) {
                    // กำหนดเป้าหมายโดเมนโฮสต์ที่แตกต่างกันซึ่งลงทะเบียนสำหรับ Universal Links บน iOS
                    launchBtn.href = "https://link.example.com/app/open" + sanitizedQueryString;
                } else {
                    launchBtn.href = baseFallbackUrl;
                }
            } else {
                launchBtn.href = baseFallbackUrl;
            }
        }

        // ขั้นตอนที่ 4: เริ่มต้น SDK เว็บ JS ของ OpenInstall สำหรับการนำเข้าพารามิเตอร์แบบไดนามิก
        // SDK รายงานความพร้อม ความคงอยู่ของพารามิเตอร์และความสามารถในการลิงก์เชิงลึกแบบเลื่อนเวลา
        // ขึ้นอยู่กับการเผยแพร่ SDK และการผสานรวมแอปพลิเคชันที่ปรับใช้
        //  href ของ HTML ที่กำหนดค่าในขั้นตอนที่ 3 ยังคงเป็นเจ้าของการนำทางเพียงรายเดียว
        if (typeof OpenInstall === "function") {
            try {
                new OpenInstall({
                    appKey: "OPOINSTALL_APPKEY_PLACEHOLDER",
                    data: campaignData,
                    onready: function() {
                        // คอลแบปความพร้อมของ SDK
                        // ห้ามเขียนทับ launchBtn.onclick ที่นี่ การนำทางยังคงเป็นเจ้าของเดียวโดย  href
                    }
                });
            } catch (err) {
                console.error("ข้อผิดพลาดในการเริ่มต้น OpenInstall SDK:", err);
                //  href ที่กำหนดค่าในขั้นตอนที่ 3 ยังคงใช้งานได้และไม่มีสิ่งกีดขวาง
            }
        }
    })();
    </script>
</body>
</html>

Origin Web Domain:      https://www.example.com/landing
Universal Link Target:  https://link.example.com/app/open (ซับโดเมนหรือโดเมนที่แตกต่างกัน)

<!-- การกำหนดค่า Android Intent Scheme & ไวยากรณ์ตัวกรอง Manifest -->
<!-- ไฟล์: android_intent_routing.html -->

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>ไวยากรณ์การกำหนดเส้นทาง Android Intent</title>
</head>
<body>

    <!-- ตัวอย่าง 1: Android Intent URI กำหนดเป้าหมายไปที่เบราว์เซอร์ระบบ Chrome พร้อมการสำรองข้อมูล HTTPS -->
    <!-- หมายเหตุ: การระบุ package=com.android.chrome จะกำหนดเป้าหมายไปที่ Google Chrome อย่างชัดเจน -->
    <!-- ไวยากรณ์: intent://[host]/[path]#Intent;scheme=[scheme];package=[package];S.browser_fallback_url=[fallback];end -->
    <a href="intent://app.example.com/details?inviter_id=USR_1024#Intent;scheme=https;package=com.android.chrome;S.browser_fallback_url=https%3A%2F%2Fapp.example.com%2Fdownload%3Finviter_id%3DUSR_1024;end">
        เปิดในเบราว์เซอร์ Chrome
    </a>

    <!-- ตัวอย่าง 2: Intent URI เปิดโปรโตคอลกำหนดเองของแอปเนทีฟพร้อมการสำรองข้อมูล -->
    <a href="intent://product/456#Intent;scheme=myapp;package=com.example.app;S.browser_fallback_url=https%3A%2F%2Fapp.example.com%2Fdownload;end">
        เปิดแอปเนทีฟหรือดาวน์โหลด
    </a>

</body>
</html>

<!-- การกำหนดค่าอ้างอิง: ไวยากรณ์ตัวกรอง Intent ของกิจกรรม AndroidManifest.xml (XML) -->
<!-- วางองค์ประกอบกิจกรรมนี้ไว้ภายในองค์ประกอบ <application> ของ AndroidManifest.xml ของคุณ: -->

<activity
    android:name="com.example.app.RoutingActivity"
    android:exported="true"
    android:launchMode="singleTask">
    
    <!-- ตัวกรอง Intent ของ Custom URL Scheme -->
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="myapp" android:host="product" />
    </intent-filter>

    <!-- ตัวกรอง Intent ของ Android App Links (การตรวจสอบโดเมน HTTPS) -->
    <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="https" android:host="app.example.com" />
    </intent-filter>
</activity>

สรุปและกรอบการตัดสินใจในการนำไปใช้งาน

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

วัสดุที่เกี่ยวข้อง

• แนวคิด: Web to App, การทำแซนด์บ็อกซ์ของเบราว์เซอร์ภายในแอป, Quick Installation, External Browser Handoff

• เทคโนโลยี: WeChat XWeb Engine, iOS WKWebView, Apple Universal Links, Android Intent Filters

• มาตรฐาน: W3C HTML5 Navigation Timing, IETF RFC 3986 URI Syntax, OWASP Mobile Top 10

• API: ไวยากรณ์ Android Intent.ACTION_VIEW, Apple WebKit Navigation Delegate, OpoInstall m.wakeupOrInstall Web API

• เอกสารอย่างเป็นทางการและการอ้างอิง:

  • บันทึกทางเทคนิคสำหรับนักพัฒนา Apple TN3155: การดีบัก Universal Links

  • คู่มือสำหรับนักพัฒนา Chrome: Android Intents กับ Chrome

  • คู่มือสำหรับนักพัฒนา Google Android: Intents และ Intent Filters

  • ชีตชีต OWASP: การเปลี่ยนเส้นทางและการส่งต่อที่ไม่ได้ตรวจสอบ

  • ศูนย์เอกสาร OpoInstall

  • ศูนย์ดาวน์โหลด OpoInstall SDK