Cách khắc phục thông báo lỗi "Địa chỉ không hợp lệ" của Safari khi sử dụng URL Scheme dự phòng

Tại sao Safari hiển thị thông báo địa chỉ không hợp lệ (invalid address) đối với URL scheme? Safari có thể hiển thị lỗi “invalid-address” hoặc “cannot-open-page” khi trang web điều hướng đến một custom URL scheme mà hệ thống không thể ánh xạ tới trình xử lý sẵn có. Để giải quyết vấn đề này, bạn cần chuyển đổi sang sử dụng Universal Links đã xác thực hoặc triển khai các phương thức dự phòng dựa trên thao tác của người dùng để điều hướng người dùng chưa cài đặt ứng dụng đến cửa hàng ứng dụng (App Store).

Cảnh báo “Safari không thể mở trang vì địa chỉ không hợp lệ” có thể xuất hiện khi Safari trên di động cố gắng điều hướng đến một custom URL scheme trên thiết bị không có ứng dụng đích hoặc không có trình xử lý phù hợp. Việc khắc phục lỗi này bao gồm chuyển đổi từ các URI scheme cũ sang Universal Links đã xác thực, hoặc triển khai kiến trúc dự phòng tuân thủ thao tác người dùng để điều hướng người dùng chưa cài ứng dụng đến App Store mà không gây ra lỗi giao thức không được xử lý.

Tại sao Safari hiển thị lỗi địa chỉ không hợp lệ trên Custom Schemes

Nguyên nhân gốc rễ: Cách WebKit phản hồi với các giao thức URI chưa đăng ký

Khi người dùng tương tác với một liên kết trên trang web di động, công cụ kết xuất của trình duyệt sẽ đánh giá giao thức URI để xác định giao thức vận chuyển hoặc trình xử lý ứng dụng thích hợp. Trong Apple Safari, được vận hành bởi công cụ WebKit, các giao thức web tiêu chuẩn như http:// và https:// được xử lý nội bộ bởi trình tải tài nguyên mạng.

Khi một trang web yêu cầu Safari điều hướng đến một custom URI scheme (ví dụ: myapp://product/detail/1024), hệ điều hành sẽ cố gắng tìm kiếm một ứng dụng đã cài đặt có đăng ký scheme cụ thể đó trong cấu hình bundle CFBundleURLTypes. Nếu ứng dụng đích có mặt, iOS có thể khởi chạy ứng dụng gốc. Tuy nhiên, nếu ứng dụng chưa được cài đặt trên thiết bị, scheme đó không thể được phân giải qua DNS hoặc các lớp vận chuyển web tiêu chuẩn. Vì Safari không sở hữu trình xử lý web nội bộ cho các custom scheme, việc cố gắng điều hướng đến một giao thức tùy chỉnh chưa được xử lý có thể hiển thị hộp thoại cảnh báo rằng Safari không thể mở trang vì địa chỉ không hợp lệ.

Rào cản Sandbox: Tại sao JavaScript không thể truy vấn trạng thái cài đặt ứng dụng

Các nhà phát triển frontend thường cố gắng vượt qua cảnh báo này bằng cách viết JavaScript phía client để kiểm tra xem ứng dụng đã được cài đặt hay chưa trước khi kích hoạt scheme. Theo kiến trúc bảo mật và quyền riêng tư của hệ điều hành Apple, phương pháp kiểm tra này hoàn toàn không khả dụng đối với nội dung web.

Mobile Safari thực thi sự cô lập sandbox nghiêm ngặt giữa nội dung web và hệ điều hành máy chủ. JavaScript trên trang web bị cấm truy vấn các registry hệ thống tệp cục bộ, kiểm tra các gói ứng dụng đã cài đặt hoặc kiểm tra xem một custom URI scheme có trình xử lý đang hoạt động hay không. Vì trình duyệt không thể thăm dò trạng thái cài đặt trước, việc thực thi một custom scheme chưa được xử lý trên thiết bị không có ứng dụng phù hợp có thể gây ra cảnh báo lỗi của WebKit.

Ảnh hưởng đến trải nghiệm người dùng: Cách các cảnh báo hệ thống làm tăng tỷ lệ thoát (bounce rate) trên trang landing page

Việc gặp phải một thông báo hệ thống cho biết “địa chỉ không hợp lệ” làm suy giảm lòng tin của người dùng và làm gián đoạn phễu chuyển đổi:

• Lo ngại về bảo mật: Người dùng có thể hiểu các cảnh báo “địa chỉ không hợp lệ” là dấu hiệu của trang web bị lỗi, phần mềm không đáng tin cậy hoặc cảnh báo bảo mật.
• Gián đoạn phễu: Cảnh báo yêu cầu người dùng phải xác nhận và đóng hộp thoại chặn trước khi tương tác lại với trang, làm tăng tỷ lệ người dùng rời bỏ ngay lập tức.
• Chuyển hướng cửa hàng bị phân mảnh: Nếu cảnh báo không được xử lý xuất hiện đồng thời với các tập lệnh chuyển hướng cửa hàng thứ cấp, quá trình chuyển sang App Store sẽ trông rời rạc và thiếu chuyên nghiệp.

Tại sao các giải pháp thay thế cũ thất bại trên các phiên bản WebKit hiện đại

Hạn chế của việc sử dụng Iframe ẩn trong Safari hiện đại

Trong các phiên bản iOS trước đây, các nhà phát triển thường triển khai việc thăm dò bằng iframe ẩn. Một tập lệnh sẽ tiêm một phần tử <iframe> vô hình vào DOM và đặt nguồn của nó là custom scheme (myapp://), trong khi chạy một bộ hẹn giờ JavaScript đồng thời. Mục đích là ứng dụng đã cài đặt sẽ khởi chạy mà không cần điều hướng cửa sổ cấp cao nhất, trong khi ứng dụng chưa cài đặt sẽ thất bại âm thầm bên trong khung hình đó.

Trong các trình duyệt di động hiện đại, phương pháp này không còn đáng tin cậy:

• WebKit hiện đại áp dụng các hạn chế về điều hướng và sandbox có thể giới hạn việc chuyển giao giao thức bên ngoài từ iframes, đặc biệt là các khung được đặt trong sandbox.
• Cố gắng tải các scheme chưa đăng ký bên trong iframes vẫn có thể kích hoạt hộp thoại lỗi cấp trình duyệt hoặc thất bại âm thầm mà không cung cấp phương thức dự phòng sạch sẽ.
• Vì việc thăm dò bằng iframe không nhất quán giữa các phiên bản iOS và bối cảnh sandbox, nó không nên được coi là một cơ chế đáng tin cậy để đánh giá sự hiện diện của ứng dụng.

Các chuỗi điều hướng window.location dựa trên bộ hẹn giờ: Tại sao các trình duyệt hiện đại hạn chế chuyển hướng tự động

Một kỹ thuật cũ khác liên quan đến việc thực thi chuỗi dựa trên bộ hẹn giờ sử dụng window.location.href:

// Anti-pattern cũ: Dễ lỗi và bị hạn chế trong các trình duyệt hiện đại
window.location.href = "myapp://product/detail";
setTimeout(function() {
    window.location.href = "https://apps.apple.com/app/id123456789";
}, 2000);

Cách tiếp cận này tạo ra nhiều chế độ thất bại về trải nghiệm người dùng và kỹ thuật:

1. Cảnh báo đồng thời: Nếu ứng dụng không được cài đặt, Safari có thể hiển thị cảnh báo “địa chỉ không hợp lệ” khi đánh giá custom scheme, buộc người dùng phải đóng cảnh báo trong khi bộ hẹn giờ nền khởi tạo điều hướng thứ cấp.
2. Chuyển hướng ngoài ý muốn: Nếu ứng dụng được cài đặt và mở thành công, trình duyệt có thể vẫn thực thi bộ hẹn giờ đang chờ khi quay lại Safari, chuyển hướng người dùng đến App Store một cách không cần thiết khi họ quay lại trình duyệt.

Chính sách kích hoạt người dùng và điều hướng trình duyệt

Các trình duyệt di động hiện đại thực thi chính sách kích hoạt người dùng (user-activation) nhằm hạn chế các điều hướng không được nhắc nhở. WebKit giới hạn các chuyển hướng cửa sổ tự động và chuyển giao giao thức bắt nguồn từ bộ hẹn giờ nền, callback bất đồng bộ hoặc tập lệnh on-load mà không có tương tác người dùng gần đây.

Việc chuyển giao tự động mà không có tương tác người dùng trực tiếp sẽ kém dự đoán hơn và có thể bị chặn tùy thuộc vào bối cảnh trình duyệt. Để điều hướng đáng tin cậy, việc chuyển giao ứng dụng gốc nên bắt nguồn trực tiếp từ một thao tác người dùng rõ ràng, chẳng hạn như nhấn vào một phần tử tương tác.

Tại sao Universal Links được Apple thiết kế như một giải pháp ưu tiên

Để loại bỏ các chế độ thất bại của các URL scheme độc quyền, Apple đã giới thiệu Universal Links trong iOS 9. Universal Links thay thế các custom scheme (myapp://) bằng các URL web HTTPS tiêu chuẩn, đã xác thực (https://app.example.com/product/1024).

Bằng cách neo deep linking vào cơ sở hạ tầng HTTPS tiêu chuẩn, Apple đã loại bỏ chế độ thất bại của giao thức chưa đăng ký. Nếu ứng dụng được cài đặt, liên kết và đủ điều kiện trong bối cảnh điều hướng hiện tại, iOS sẽ định tuyến liên kết trực tiếp đến các trình xử lý gốc; nếu ứng dụng không được cài đặt, Safari sẽ tiếp tục điều hướng URL HTTPS như một tài nguyên web bình thường, tải trang web hoặc phương thức dự phòng cửa hàng mà không có cảnh báo giao thức.

Cách Universal Links loại bỏ cảnh báo địa chỉ không hợp lệ

Nền tảng HTTPS: Loại bỏ chế độ thất bại của giao thức chưa đăng ký

Sự khác biệt chính giữa một custom URL scheme và một Universal Link nằm ở cách ngăn xếp mạng của trình duyệt đánh giá URL được yêu cầu:

• Custom Scheme (myapp://): Một giao thức không tiêu chuẩn. WebKit không thể phân giải nó qua DNS hoặc vận chuyển web tiêu chuẩn. Nếu không có ứng dụng đăng ký nào xử lý scheme này, yêu cầu có thể hiển thị lỗi địa chỉ không hợp lệ.
• Universal Link (https://app.example.com): Một URL HTTPS tiêu chuẩn, đầy đủ điều kiện. WebKit phân giải và tải các địa chỉ HTTPS một cách tự nhiên.

Vì một Universal Link về cơ bản là một URL web hợp lệ, Safari không bao giờ gặp phải giao thức chưa đăng ký. Nếu việc chuyển giao ứng dụng gốc không xảy ra, Safari chỉ đơn giản là tải nội dung web được lưu trữ tại địa chỉ đó.

Mối liên kết hai chiều: Điều phối quyền ứng dụng gốc với tệp AASA được lưu trữ

Universal Links thiết lập điều hướng đã xác thực thông qua mối liên kết giữa tệp nhị phân của ứng dụng di động và tên miền trang web:

1. Quyền ứng dụng (Entitlement): Ứng dụng iOS khai báo quyền Associated Domains chứa chuỗi tên miền mục tiêu: applinks:app.example.com.
2. Khai báo máy chủ: Tên miền trang web lưu trữ tệp JSON tại https://app.example.com/.well-known/apple-app-site-association (AASA). Tệp này chỉ định các Mã định danh ứng dụng được ủy quyền và các thành phần khớp đường dẫn.
3. Phân giải cấp hệ điều hành: Khi người dùng cài đặt ứng dụng, iOS sẽ xác thực mối liên kết tên miền. Khi một liên kết liên quan được nhấn, hệ điều hành sẽ đánh giá liệu một ứng dụng đủ điều kiện có thể xử lý đích đến hay không.

Giáng cấp web nhẹ nhàng: Điều gì xảy ra khi ứng dụng không được cài đặt

Khi người dùng chưa cài ứng dụng nhấn vào một Universal Link:

1. Hệ điều hành iOS đánh giá URL dựa trên registry các liên kết đã xác thực của nó.
2. Không tìm thấy ứng dụng đã cài đặt nào khớp với tên miền, iOS ủy quyền liên kết cho Safari dưới dạng điều hướng web tiêu chuẩn.
3. Safari tải trang web được lưu trữ tại URL đó mà không hiển thị bất kỳ cảnh báo lỗi hệ thống nào.
4. Trang web được lưu trữ có thể hiển thị nội dung sản phẩm phù hợp, hiển thị CTA tải xuống từ App Store hoặc điều phối việc khôi phục tham số trì hoãn.

Quản lý vấn đề điều hướng cùng tên miền trong Safari bằng cách sử dụng tên miền phụ chuyên biệt

Khi triển khai Universal Links trên các trang web, các nhóm phải tính đến hành vi điều hướng cùng tên miền của Safari, như được ghi trong Tài liệu Nhà phát triển của Apple về Cho phép ứng dụng và trang web liên kết đến nội dung của bạn.

Nếu người dùng duyệt một trang web được lưu trữ trên https://example.com/promo và nhấn vào một Universal Link trỏ đến chính tên miền đó (https://example.com/product/1024), Safari cho rằng người dùng dự định tiếp tục duyệt trang web và tải trang web thay vì mở ứng dụng gốc.

Việc sử dụng một máy chủ định tuyến được liên kết riêng biệt sẽ tránh được trường hợp tiếp tục cùng tên miền đã được ghi nhận và cho phép Universal Link được đánh giá để điều hướng gốc khi liên kết tên miền của nó hợp lệ:

• Lưu trữ trang web chính trên tên miền gốc hoặc tên miền phụ web: https://www.example.com.
• Cấu hình định tuyến Universal Link thông qua một tên miền phụ chuyên biệt, được liên kết riêng biệt: https://app.example.com.

Việc nhấn qua các ranh giới tên miền phụ khác biệt thỏa mãn các heuristic điều hướng của Safari, hỗ trợ việc thực thi trực tiếp ứng dụng gốc.

Triển khai chuyển giao Web-to-App linh hoạt với SDK JavaScript

Kiến trúc các phương thức dự phòng đa tầng: Universal Links trước, dự phòng rõ ràng sau

Các kiến trúc web-to-app trong môi trường sản xuất triển khai chuỗi chuyển hướng đa tầng:

• Tầng 1 (Universal Links): Nút kêu gọi hành động (CTA) chính gọi một Universal Link đã xác thực trỏ đến tên miền phụ được liên kết. Trên các thiết bị đã cài đặt ứng dụng, điều này cho phép điều hướng gốc mà không gặp cảnh báo lỗi custom-scheme không xác định.
• Tầng 2 (Dự phòng Web theo ngữ cảnh): Nếu ứng dụng không được cài đặt, Universal Link sẽ điều hướng mượt mà đến trang landing page web, hiển thị nút tải xuống App Store.
• Tầng 3 (Dự phòng Custom Scheme): Ở những nơi các custom scheme cũ (myapp://) được duy trì cho các phiên bản hệ điều hành cũ hoặc các container nhúng cụ thể, hãy gọi chúng như một phương thức dự phòng, vốn thường nên bắt nguồn từ tương tác người dùng rõ ràng thay vì các tập lệnh tự động.

Sử dụng Page Visibility API như một tín hiệu ngăn chặn heuristic

Khi triển khai bộ hẹn giờ dự phòng cùng với các custom scheme, các tập lệnh phía client đánh giá xem tài liệu có bị mất hiển thị ở tiền cảnh hay không để hủy các lệnh chuyển hướng cửa hàng đang chờ. Vì JavaScript không thể trực tiếp kiểm tra việc thực thi quy trình gốc, các kiến trúc frontend sử dụng Tiêu chuẩn HTML WHATWG về Page Visibility.

Khi một tab trình duyệt chuyển sang nền sau sau khi chuyển giao bên ngoài, tập lệnh sẽ phát hiện sự thay đổi hiển thị:

// Độ trễ dự phòng minh họa; hãy hiệu chỉnh dựa trên yêu cầu UX của ứng dụng
var fallbackTimer = setTimeout(function() {
    if (!document.hidden) {
        // Tài liệu vẫn hiển thị ở tiền cảnh; tiếp tục với CTA dự phòng
        window.location.href = "https://apps.apple.com/app/id123456789";
    }
}, 2000);

document.addEventListener("visibilitychange", function() {
    if (document.hidden) {
        // Tài liệu trở nên bị ẩn; xóa bộ hẹn giờ dự phòng đang chờ
        clearTimeout(fallbackTimer);
    }
});

Sự thay đổi hiển thị cho biết tài liệu đã trở nên bị ẩn, đóng vai trò như một tín hiệu ngăn chặn hữu ích để tránh các lệnh chuyển hướng cửa hàng sai lệch. Tuy nhiên, sự thay đổi hiển thị không chứng minh rằng một ứng dụng mục tiêu cụ thể đã mở thành công, vì các hành động của người dùng như chuyển tab, thu nhỏ trình duyệt hoặc khóa thiết bị cũng kích hoạt các chuyển đổi trạng thái nền. Độ trễ 2000ms là một heuristic minh họa và không nên được coi là một ngưỡng giao thức tiêu chuẩn.

Ràng buộc thao tác người dùng vào các neo Universal Link lũy tiến

Đối với định tuyến liên kết trực tiếp, các nhà phát triển frontend ràng buộc các phần tử neo lũy tiến trực tiếp với các điểm cuối Universal Link đã xác thực. Khi có nhấp chuột của người dùng, trình duyệt sẽ điều hướng liên kết HTTPS, cho phép iOS chặn lộ trình.

Trong các phễu thu hút người dùng nâng cao, các nền tảng như OpoInstall hỗ trợ khôi phục tham số trì hoãn như một kênh thu thập phụ trợ riêng biệt. Bằng cách ghi lại ngữ cảnh web tại thời điểm nhấp và tương quan nó với các tín hiệu khởi chạy sau khi cài đặt thông qua các SDK hook gốc, ứng dụng gốc có thể truy xuất các tham số chiến dịch tùy chỉnh khi khởi chạy lần đầu mà không cần thay đổi quy trình xác thực URL Universal Link tiêu chuẩn. Xem lại tài liệu tích hợp SDK để biết chi tiết về việc tích hợp các trình lắng nghe thuộc tính trì hoãn (deferred attribution listeners) cùng với các trình xử lý Universal Link gốc.

[Người dùng nhấn nút CTA Web]
             │
             ▼
[Đánh giá Primitive Định tuyến]
   ┌─────────┴─────────┐
   ▼                   ▼
[Custom Scheme: myapp://] [Universal Link: https://]
   │                           │
   ▼                           ▼
[Safari cố gắng phân giải]   [OS đánh giá mối liên kết]
├─ App phân giải -> App mở  ├─ App đã cài + Hợp lệ -> App gốc
└─ Không có trình xử lý / Bị chặn -> └─ Chưa cài đặt ->
   Có thể hiển thị cảnh báo    Tải Web Landing nhẹ nhàng
   hệ thống "Địa chỉ không     │
   hợp lệ"                   ▼
                              [Hiển thị App Store hoặc Dự phòng Web]

Triển khai phía Client: Định tuyến Universal Link và xử lý dự phòng

Cấu hình các tập lệnh chuyển hướng Universal Link hiện đại trong HTML/JavaScript frontend

Việc triển khai frontend cấu trúc một phần tử neo tương tác gắn trực tiếp vào một URL Universal Link đã xác thực trên tên miền phụ liên quan, cung cấp phương thức dự phòng tăng cường lũy tiến nếu việc thực thi tập lệnh bị chặn.

Tiếp nhận iOS gốc trong các kiến trúc vòng đời dựa trên Scene

Đối với các ứng dụng iOS dựa trên scene, các Universal Links được Safari gửi đến được xử lý thông qua vòng đời UIWindowSceneDelegate: scene(_:willConnectTo:options:) khi khởi chạy lạnh và scene(_:continue:) khi ứng dụng đang chạy hoặc bị treo trong bộ nhớ. Việc triển khai gốc xác thực rằng NSUserActivity đến có loại hoạt động là NSUserActivityTypeBrowsingWeb, trích xuất webpageURL và xác thực lộ trình.

Việc triển khai kỹ thuật dưới đây minh họa cách cấu hình neo lũy tiến frontend và xử lý các URL Universal Link đến một cách an toàn trong Swift gốc.

// Web: Chuyển giao Universal Link Frontend với Dự phòng Neo Lũy tiến
// Cấu hình đích đến HTTPS Universal Link sạch sẽ với việc làm sạch tham số query phía client.
(function() {
    var ctaButton = document.getElementById("openAppBtn");
    if (!ctaButton) return;

    // 1. Trạng thái ban đầu: Universal Link đã xác thực trên tên miền phụ chuyên biệt tránh việc Safari tiếp tục cùng tên miền
    var targetBaseUrl = "https://app.example.com/detail/1024";

    // 2. Trích xuất và làm sạch các tham số query động từ URL trang hiện tại
    var urlParams = new URLSearchParams(window.location.search);
    var rawId = urlParams.get("id") || "";
    var rawPromo = urlParams.get("promo_code") || "";
    var rawSource = urlParams.get("utm_source") || "web_landing";

    var idRegex = /^[A-Za-z0-9_-]{1,64}$/;
    var targetId = idRegex.test(rawId) ? rawId : "";
    var promoCode = idRegex.test(rawPromo) ? rawPromo : "";
    var utmSource = idRegex.test(rawSource) ? rawSource : "web_landing";

    var finalUrl = targetBaseUrl + "?utm_source=" + encodeURIComponent(utmSource);
    if (targetId.length > 0) {
        finalUrl += "&id=" + encodeURIComponent(targetId);
    }
    if (promoCode.length > 0) {
        finalUrl += "&promo_code=" + encodeURIComponent(promoCode);
    }

    // Tăng cường lũy tiến: neo href cung cấp điều hướng Universal Link trực tiếp, không có cảnh báo
    if (ctaButton.tagName.toLowerCase() === "a") {
        ctaButton.setAttribute("href", finalUrl);
    } else {
        ctaButton.addEventListener("click", function(e) {
            e.preventDefault();
            window.location.assign(finalUrl);
        });
    }
})();

// iOS: SceneDelegate.swift - Xử lý Universal Link & Làm sạch Lộ trình
// Ví dụ tích hợp tham khảo. Xác minh chữ ký phương thức và định tuyến dựa trên kiến trúc đã triển khai của bạn.
import UIKit

struct ValidatedAppRoute {
    let path: String
    let queryParams: [String: String]
}

class AppRouteValidator {
    private static let allowedHosts = Set(["app.example.com"])
    private static let allowedPathPrefixes = ["/detail/", "/promo/"]
    private static let allowedKeys = Set(["id", "promo_code", "utm_source"])

    static func validate(url: URL) -> ValidatedAppRoute? {
        guard let scheme = url.scheme?.lowercased(), scheme == "https" else {
            return nil
        }
        guard let host = url.host?.lowercased(), allowedHosts.contains(host) else {
            return nil
        }

        let path = url.path
        guard allowedPathPrefixes.contains(where: { path.hasPrefix($0) }) else {
            return nil
        }

        var sanitizedParams: [String: String] = [:]
        var seenKeys = Set<String>()

        if let components = URLComponents(url: url, resolvingAgainstBaseURL: false),
           let queryItems = components.queryItems {
            let validChars = CharacterSet(charactersIn: "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_-")
            for item in queryItems {
                // Xác thực fail-closed: từ chối URL nếu có các khóa query không xác định
                guard allowedKeys.contains(item.name), !seenKeys.contains(item.name) else {
                    return nil
                }
                seenKeys.insert(item.name)

                let value = item.value ?? ""
                if value.count <= 64 && value.rangeOfCharacter(from: validChars.inverted) == nil {
                    sanitizedParams[item.name] = value
                } else {
                    return nil
                }
            }
        }

        return ValidatedAppRoute(path: path, queryParams: sanitizedParams)
    }
}

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?

    func scene(
        _ scene: UIScene,
        willConnectTo session: UISceneSession,
        options connectionOptions: UIScene.ConnectionOptions
    ) {
        guard let _ = (scene as? UIWindowScene) else { return }

        // Xử lý khởi chạy lạnh qua Universal Link
        if let userActivity = connectionOptions.userActivities.first(where: { $0.activityType == NSUserActivityTypeBrowsingWeb }),
           let webpageURL = userActivity.webpageURL {
            processIncomingUniversalLink(url: webpageURL)
        }
    }

    func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
        // Xử lý khôi phục ấm (warm resume) qua Universal Link
        if userActivity.activityType == NSUserActivityTypeBrowsingWeb,
           let webpageURL = userActivity.webpageURL {
            processIncomingUniversalLink(url: webpageURL)
        }
    }

    private func processIncomingUniversalLink(url: URL) {
        // Thực thi việc lọc allowlist và làm sạch nghiêm ngặt trên Universal Link đến
        if let route = AppRouteValidator.validate(url: url) {
            DispatchQueue.main.async {
                AppNavigator.shared.navigateTo(path: route.path, params: route.queryParams)
            }
        } else {
            DispatchQueue.main.async {
                AppNavigator.shared.navigateToDefaultHome()
            }
        }
    }
}

// Điều phối viên điều hướng cụ thể cho ứng dụng (không phải API SDK)
class AppNavigator {
    static let shared = AppNavigator()

    func navigateTo(path: String, params: [String: String]) {
        // Thực thi chuyển đổi view controller UI nội bộ dựa trên đường dẫn và tham số query
    }

    func navigateToDefaultHome() {
        // Dự phòng an toàn về màn hình chính khi deep link bị sai lệch hoặc không nhận dạng được
    }
}

Làm sạch các tham số đến: Thực thi lọc allowlist nghiêm ngặt trên các lộ trình gốc

Theo Hướng dẫn kiểm thử bảo mật ứng dụng di động OWASP về các Deep Link không an toàn, tất cả các tham số được gửi qua Universal Links phải được coi là đầu vào không đáng tin cậy:

• Xác thực đường dẫn: Xác minh rằng đường dẫn URL khớp với danh sách allowlist được ủy quyền của các view controller (/detail/, /promo/).
• Lọc query: Thực thi các khóa query nằm trong allowlist (id, promo_code, utm_source) và loại bỏ các khóa không mong đợi.
• Độ dài & Giới hạn ký tự: Hạn chế các giá trị tham số trong các bộ ký tự chữ và số ($\le 64$ ký tự).

Ma trận định giao thức Deep Linking Safari và giảm thiểu lỗi

Danh sách kiểm tra phòng ngừa lỗi và so sánh giao thức toàn diện

Việc chọn đúng giao thức deep linking là rất quan trọng để ngăn ngừa các lỗi điều hướng WebKit. Ma trận dưới đây so sánh các cơ chế deep linking chính trên các hành vi lỗi và yêu cầu nền tảng:

So sánh URL Schemes, Universal Links và Smart App Banners trên các hành vi lỗi

Tóm tắt và Khung quyết định

Cảnh báo “Safari không thể mở trang vì địa chỉ không hợp lệ” là một hệ quả vận hành của việc sử dụng các URI scheme tùy chỉnh trên các thiết bị không có trình xử lý ứng dụng tương ứng. Việc dựa vào kỹ thuật thăm dò iframe ẩn cũ hoặc chuỗi bộ hẹn giờ tự động tạo ra sự mong manh trong điều hướng và làm tổn hại các phễu chuyển đổi web-to-app.

Chuyển đổi sang Universal Links đã xác thực sẽ loại bỏ chế độ thất bại của giao thức tùy chỉnh chưa đăng ký và cung cấp một lộ trình dự phòng HTTPS đáng tin cậy. Bằng cách kết hợp các liên kết HTTPS đã xác thực với các mẫu tích hợp web tuân thủ thao tác người dùng, các nhóm kỹ thuật giảm thiểu các cảnh báo trình duyệt gây gián đoạn, bảo toàn các tham số marketing qua các lần tải xuống cửa hàng và hỗ trợ trải nghiệm onboard đáng tin cậy trên các phễu web di động.

Để tìm hiểu cách triển khai Universal Links và truyền tham số tự động, hãy xem lại tài liệu tích hợp SDK.

Tài liệu liên quan

• Khái niệm: Custom URL Scheme, Universal Links, Chuyển hướng Web to App, Giảm thiểu lỗi WebKit, Khôi phục Scene
• Công nghệ: Apple WebKit, iOS UIKit, Apple App Site Association (AASA), OpoInstall Web JS SDK
• Tiêu chuẩn: IETF RFC 3986 Uniform Resource Identifier, Đặc tả tên miền liên kết của Apple, Hướng dẫn kiểm thử bảo mật ứng dụng di động OWASP (MASTG)
• API: UIApplication.shared.open, UIWindowSceneDelegate.scene(_:continue:), WHATWG HTML Page Visibility
• Tài liệu chính thức & Tham chiếu:
  • Tài liệu nhà phát triển Apple về Định nghĩa Custom URL Scheme cho ứng dụng của bạn
  • Tài liệu nhà phát triển Apple về Cho phép ứng dụng và trang web liên kết đến nội dung của bạn
  • Ghi chú kỹ thuật của Apple TN3155 về Gỡ lỗi Universal Links
  • Tiêu chuẩn HTML WHATWG về Page Visibility
  • Hướng dẫn kiểm thử bảo mật ứng dụng di động OWASP về các Deep Link không an toàn