Xác thực HTTP trong ứng dụng web iOS 7 không phản hồi

Question

Tổ chức của tôi có ứng dụng web hoạt động hoàn hảo trong iOS 6. Bạn truy cập trang web, trang web sẽ cho bạn biết thêm trang vào màn hình chính của bạn và bùng nổ, một ứng dụng web HTML5 đẹp mắt đã được thêm vào màn hình chính.

Vì chúng tôi đang xử lý dữ liệu nhạy cảm, ứng dụng web đã sử dụng xác thực HTTP (thông qua hộp thoại xác thực WebKit gốc) để xác thực người dùng/thẻ. Nó hoạt động mà không có một hitch cho đến khi iOS 7. Bây giờ khi ai đó cố gắng để triệu tập hộp thoại auth HTTP, không có gì xảy ra. Rõ ràng là đang cố gắng để tải thứ gì đó, vì trình xoay tròn trong thanh trạng thái xuất hiện, nhưng không có hộp thoại nào xuất hiện, về cơ bản phá vỡ "ứng dụng".

Có bất cứ ai khác chạy vào điều này? Đây có phải là thứ mà bạn cho là lỗi trên đầu của Apple không? Có cách giải quyết nào không?

Answer 1

Tôi có cùng một vấn đề chính xác. Xác thực cơ bản đã hoạt động với các phiên bản iOS trước nhưng không phải với iOS 7 kết hợp với các ứng dụng web được thêm vào màn hình chính. Tôi nghĩ rằng điều này có thể liên quan đến vấn đề của hộp thoại được mô tả here.

Hộp thoại chuẩn không hoạt động, chẳng hạn như cảnh báo, xác nhận hoặc nhắc.

Dấu nhắc đăng nhập được hiển thị để xác thực người dùng có thể bị chặn (không hoạt động hoặc không hiển thị) và đó là lý do ứng dụng web không vượt qua giai đoạn xác thực.

Tôi cho rằng Apple sẽ phải khắc phục lỗi này trong bản phát hành trong tương lai.

Chỉnh sửa: Sau khi nâng cấp lên xác thực cơ bản iOS 7.0.3 đột nhiên bắt đầu hoạt động trở lại cũng ở chế độ ứng dụng web trên màn hình chính. Lời nhắc đăng nhập được hiển thị và mọi thứ hoạt động như mong đợi.

Answer 2

Công ty của tôi chạy vào mùa thu năm ngoái, bắt đầu với iOS 6 và những gì chúng tôi có thể xác định được rằng đó là lỗi Apple Safari chính hãng như một phần trong "cải tiến" bảo mật. Không có lời giải thích thực sự nào từ họ vì lý do cơ bản, nhưng đây là những gì chúng ta thấy trong các trình gỡ lỗi và các gói sniffers.

Trong hoạt động bình thường, trình duyệt Safari sẽ yêu cầu một trang (hoặc một đối tượng trong trang) từ máy chủ trên GET. Nếu nội dung đó được bảo vệ bằng Danh sách điều khiển truy cập, trong trường hợp của chúng tôi Apache Basic Auth và đó là yêu cầu đầu tiên trên máy chủ đó trong phiên, máy chủ sẽ phản hồi với tiêu đề phản hồi 401 HTTP cho khách hàng (trình duyệt) nó cần phải yêu cầu một lần nữa, lần này thêm một tiêu đề auth cơ bản có ủy nhiệm ủy quyền. Trình duyệt sau đó trình bày hộp thoại đăng nhập cho người dùng, nơi họ có thể nhập người dùng và vượt qua thông tin đăng nhập và gửi hoặc hủy yêu cầu. Khi gửi, khách hàng sẽ yêu cầu lại với các thông tin đăng nhập đó trong tiêu đề xác thực.

Giả sử thông tin đăng nhập được chấp nhận trên yêu cầu GET thứ hai, nội dung thích hợp sẽ được trả về phản hồi và tài liệu trong trình duyệt sẽ tiếp tục tải phần còn lại của trang (giả sử đó là trang bạn yêu cầu). Nếu bạn có nội dung được nhúng nằm trên một máy chủ lưu trữ khác và máy chủ lưu trữ đó yêu cầu xác thực cho nội dung đó, quá trình được lặp lại khi trang tải.

Đây là nơi bị hỏng. Nếu bạn nhúng cuộc gọi đến các đối tượng từ tổng số hơn 2 máy chủ trên cùng một trang, yêu cầu xác thực cơ bản, dấu nhắc xác thực thứ 3 trên trang đó bị chặn, do đó trình duyệt quay mãi mãi để bạn nhập thông tin xác thực trên lời nhắc mà bạn không bao giờ thấy . Trình duyệt Safari của bạn hiện đã bị treo trên dấu nhắc xác thực bị trì hoãn, trên tab này và bất kỳ tab nào khác, ngay cả khi tải lại và bạn sẽ không nhận được lời nhắc khác trừ khi và cho đến khi bạn đóng trình duyệt hoặc khởi động lại thiết bị của mình.

Điều này không ảnh hưởng đến Chrome, chỉ Safari và cả trên iPhone và iPad có iOS 6 trở lên. Tôi có phiên bản iOS mới nhất kể từ khi viết bài này (7.0.6), và vấn đề vẫn còn đó.

Chúng tôi đã có một giải pháp thay thế vào năm ngoái, nơi chúng tôi sẽ tạo một trang nội bộ có một mảng của mỗi máy chủ được nhúng, sau đó chúng tôi sẽ lặp lại với khung nội tuyến nhúng cuộc gọi đến favicon.ico tại vị trí của máy chủ đó . Điều đó đã hoạt động cho đến gần đây, hiện tại, có lẽ vì tính năng iOS 7 của các tab nền bị đóng băng, các lời nhắc auth sẽ bị đóng băng một lần nữa.

Dưới đây là mẫu JavaScript:

hosts=["store","profile","www","secure-store","images","m","modules"]; 
devhost=location.hostname; 
var i=0; 
while (hosts[i]) 
{ 
newhost=devhost.replace('store.mydomain',hosts[i]+'.mydomain'); 
document.write("<iframe Xhidden seamless=seamless width=0 height=0 src=http://"+newhost+"/favicon.ico><img height='16' width='20' alt='NOT' title='NOT AUTHENTICATED' src=http://"+newhost+"/favicon.ico> Authenticated on "+newhost+"</a></br></iframe>"); 
document.write("<img height='16' width='20' alt='NOT' title='NOT AUTHENTICATED' src="+(newhost.indexOf('secure')>0?'https://':'http://')+newhost+"/favicon.ico> Authenticated on "+newhost+"</a></br>"); 
i++; 
} 

Tập thứ hai trong document.write sẽ cung cấp một dấu hiệu thị giác trong đó chủ nhà đã được xác thực, như favicon của họ bây giờ được hiển thị. Nó cũng cho phép bạn biết máy chủ nào có thể bị trì hoãn vì biểu tượng của nó bị thiếu.

Vì giải pháp này ngừng hoạt động trên iOS 7, giải pháp rườm rà duy nhất mà chúng tôi có là mở trước một tab riêng biệt cho mỗi favicon (trực tiếp trong URL), nhập auth, quay lại, chuyển đến một trong danh sách và lặp lại cho đến khi bạn đã lưu trữ tất cả thông tin đăng nhập xác thực cho tất cả các máy chủ được sử dụng trên trang. Tại thời điểm đó, bạn có thể tải trang gốc vì tín dụng của bạn hiện đã được lưu vào bộ nhớ cache. Cruddy, và hoàn toàn không hợp lý cho một người tiêu dùng cuối cùng, nhưng là những gì chúng tôi cần làm để kiểm tra các trang web đằng sau CDN công cộng, vì chúng tôi cần bảo vệ tài sản trên trang web phát triển đó bằng ACL.

Tính đến hôm nay, chúng tôi vẫn đang tìm ra cách giải quyết tốt hơn. Không phải là vấn đề trên Android, Windows hoặc bất kỳ iOS nào khác.

Chắc chắn hoạt động tốt hơn khi Jobs còn sống.

Hy vọng một số điều này sẽ hữu ích.