Các tùy chọn để kiểm tra nhân viên dịch vụ qua HTTP


93

Tôi muốn kiểm tra nhân viên dịch vụ nhưng tôi có thiết lập máy chủ ảo và dường như tôi không thể bật https trên localhost.

Làm cách nào tôi có thể đưa url máy chủ ảo cục bộ vào danh sách trắng để kiểm tra nhân viên dịch vụ bất cứ khi nào tôi thử và đăng ký công nhân dịch vụ trên máy chủ cục bộ? Chrome cho biết cần có https để kích hoạt nhân viên dịch vụ. Làm thế nào tôi có thể vượt qua hạn chế này ít nhất là cho thử nghiệm cục bộ.

Câu trả lời:


136

Nói chung, bạn cần cung cấp cả trang và tập lệnh service worker của mình qua HTTPS để sử dụng service worker. Cơ sở lý luận được mô tả tại Ưu tiên nguồn gốc an toàn cho các tính năng mới mạnh mẽ .

Có một ngoại lệ đối với yêu cầu HTTPS để tạo điều kiện phát triển cục bộ: nếu bạn truy cập trang và tập lệnh của service worker qua http://localhost[:port]hoặc qua http://127.x.y.z[:port], thì service worker sẽ được bật mà không cần thực hiện thêm bất kỳ hành động nào.

Trong các phiên bản gần đây của Chrome, bạn có thể khắc phục yêu cầu này làm hạn chế sự phát triển cục bộ thông qua chrome://flags/#unsafely-treat-insecure-origin-as-secure, như được giải thích trong câu trả lời này .

Firefox cung cấp chức năng tương tự , thông qua devtools.serviceWorkers.testing.enabledcài đặt.

Xin lưu ý rằng chức năng này chỉ nhằm mục đích tạo điều kiện thuận lợi cho việc kiểm tra mà nếu không sẽ không thể diễn ra và bạn phải luôn có kế hoạch sử dụng HTTPS khi cung cấp phiên bản sản xuất của trang web của mình. Đừng yêu cầu người dùng thực thực hiện các bước để bật các cờ đó!


cảm ơn jeff sẽ thử nó ngay lập tức. chắc chắn tôi đang sử dụng điều này chỉ để thử nghiệm .. cần một giải pháp tuyệt vọng trong thời gian này ... !! Tôi biết không phải là thực hành lý tưởng .. nhưng lần khinh thường kêu gọi coi thường biện pháp ... !! bạn có thể vui lòng cho tôi trở lại 4 điểm khó kiếm được của tôi ... !! tôi sẽ xóa câu hỏi nếu bạn cảm thấy nó không thích hợp và nó sẽ khuyến khích hành vi sai
Aman Satija

1
bằng cách sử dụng service worker trong localhost, nhưng khi cố gắng tìm nạp tệp sw.js từ máy chủ, nó hiển thị net :: ERR_INSECURE_RESPONSE,
sp1rs

1
Cảm ơn! Tôi đã cập nhật nội dung chính để đọc devtools.serviceWorkers.testing.enabled.
Jeff Posnick

5
Đối với bất kỳ ai gặp khó khăn trong việc tìm kiếm ở trên - mở FF - công cụ dev - bánh xe răng cài đặt - cài đặt nâng cao - bật sw qua http. Sau đó, bạn có thể đi tới about: debugging # worker trong url hoặc tools - web dev - service worker trong thanh công cụ. Khởi động công nhân!
Sten Muchow

Câu trả lời của @StenMuchow đang phù hợp với tôi trong chrome mac và windows
Mohamed Hussain

51

Nếu bạn muốn gỡ lỗi nhân viên dịch vụ của thiết bị di động được cắm vào để kiểm tra hành vi thực của một ứng dụng web tiến bộ, thì các tùy chọn khởi động ssl chrome sẽ không hữu ích và bạn chắc chắn không cần mua chứng chỉ.

@ chris-ruppel đã đề cập đến việc cài đặt phần mềm proxy, nhưng thực sự có một cách dễ dàng hơn là sử dụng chuyển tiếp cổng :

Giả sử bạn kết nối và gỡ lỗi thiết bị của mình bằng Chrome:

  • Trong "Thiết bị từ xa" của Chrome Dev Tools, hãy mở "Cài đặt" và thêm quy tắc "Chuyển tiếp cổng" .
  • Nếu thiết lập localhost của bạn đang chạy trên localhost: 80,
  • chỉ cần thêm một quy tắc "Cổng thiết bị 8080" (có thể là bất kỳ cổng không có ký hiệu> 1024)
  • và địa chỉ cục bộ "localhost: 80" (hoặc mytestserver.sometestdomainwithoutssl.company:8181 hoặc bất cứ thứ gì)

Sau khi làm điều đó, bạn có thể gọi URL " http: // localhost: 8080 " trên thiết bị di động của mình và nó sẽ được trả lời bởi "localhost: 80" trên PC / máy chủ thử nghiệm thực tế của bạn . Hoạt động hoàn hảo với nhân viên dịch vụ như thể nó là máy cục bộ của bạn đang chạy trên điện thoại di động của bạn.

Cũng hoạt động cho nhiều chuyển tiếp cổng và các miền đích khác nhau miễn là bạn nhớ sử dụng các cổng không đặc quyền trên thiết bị di động của mình. Xem ảnh chụp màn hình: Xem ảnh chụp màn hình để biết một số cổng đã định cấu hình sẽ gọi PC khi được gọi trên thiết bị di động

Nguồn của thông tin này là tài liệu về thiết bị từ xa của google: https://developers.google.com/web/tools/chrome-devtools/remote-debugging/local-server (nhưng kể từ tháng 4 năm 2017, không rõ lắm để đọc thông tin này câu trả lời đơn giản của nó)


Có vẻ hứa hẹn nhưng không hiệu quả với tôi. Chỉ nói "Không thể truy cập trang web này" khi cố gắng truy cập localhost trên Android 5.0.2 sau khi thiết lập chuyển tiếp cổng.
Jackson

Vì vậy, bạn không cần https trên localhost? SW sẽ hoạt động tốt?
Machado

2
Tốt mà phải là câu trả lời được chấp nhận, nó làm việc
Miquel

Nhanh và dễ! Đừng quên bật và chấp nhận USB Debugging trên điện thoại của bạn và cắm nó vào PC qua USB. Cảm ơn anh bạn!
Marcos R

Nhưng chỉ dành cho http, nếu bạn yêu cầu tài nguyên qua https, chúng sẽ không được lưu vào bộ nhớ đệm.
Legends

24

Tôi thường muốn gỡ lỗi và kiểm tra trên thiết bị thực. Một phương pháp tôi đã nghĩ ra liên quan đến việc định tuyến lưu lượng mạng của điện thoại thông qua Charles Proxy trong quá trình phát triển cục bộ. Không giống như tất cả các giải pháp dành riêng cho Chrome, điều này hoạt động với mọi trình duyệt trên điện thoại của bạn.

  1. Chạy Charles trên máy tính xách tay của tôi (cũng phục vụ trang web của tôi với Service Worker). Khi Charles đang chạy, hãy lưu ý IP / cổng cho Bước 2.
  2. Định cấu hình thiết bị di động để sử dụng máy tính xách tay của tôi làm proxy.
    • Đối với Android, chỉ cần chạm và giữ vào WiFi của bạn trong cài đặt> Sửa đổi mạng > Cài đặt nâng cao > Proxy . Sử dụng Thủ công để đặt IP / cổng.
    • Đối với iOS, hãy nhấp vào biểu tượng (i)> phần HTTP Proxy . Chọn Thủ công , sau đó đặt IP / cổng.
  3. localhostGiờ đây, việc truy cập trên thiết bị di động của tôi cho phép Nhân viên Dịch vụ được đăng ký và thử nghiệm.

4
Tôi cũng đang đối mặt với vấn đề đó, cảm ơn rất nhiều. Để kiểm tra thiết bị di động, điều đó là hoàn toàn không thể nếu không có proxy. bài viết này cần nhiều phiếu bầu.
Phyo Arkar Lwin

1
@ chris-ruppel Trên thực tế, có một cách để thực hiện việc này mà không cần thêm phần mềm proxy bằng cách sử dụng Công cụ Chrome Dev để tạo chuyển tiếp cổng thiết bị từ xa. Tôi đã thêm một câu trả lời chi tiết trong chủ đề này.
Christopher Lörken

"Để kiểm tra thiết bị di động, điều đó là hoàn toàn không thể;" nhưng đó là một sự giám sát nhỏ. Chúng ta hãy hoan nghênh những người spec'd công nhân dịch vụ ...
Jackson

Chris, bạn có thể nói rõ hơn về "1. Chạy Charles trên máy tính xách tay của tôi" không? Người ta có thể cài đặt proxy Charles. Anh ta có máy chủ chạy tại localhost: 8080 trên máy tính của mình. Rồi sao? Bạn cũng nói "ghi chú IP / cổng". Ở đâu?
Jackson

1
@ChrisRuppel Tôi đã chuyển sang ngrok.com : Miễn phí, tạo một trang HTTPS công khai cho ứng dụng cục bộ của tôi và hoạt động như một sự quyến rũ! Lần chạy đầu tiên mất một lúc cho đến khi nó kết nối. Điều duy nhất tôi khuyên bạn là nên chuyển vùng nếu bạn không ở Hoa Kỳ ( ngrok.com/docs#config-options , tham số "khu vực").
Karsten Silz

10

Trong trường hợp của tôi, cách dễ nhất để kiểm tra pwa là sử dụng ngrok. https://ngrok.com/download đăng nhập, nhận mã thông báo của bạn và thiết lập nó!

Khi bạn chạy, ./ngrok http {your server port}hãy đảm bảo rằng bạn sử dụng https sẽ được hiển thị trong terminal sau khi bạn chạy lệnh này ở trên.


Bạn cũng có thể sử dụng https://surge.sh , nó là để lưu trữ một trang web tĩnh, nếu bạn truy cập vào đây: https://surge.sh/help/securing-your-custom-domain-with-ssl sẽ có thể xem cách thiết lập chứng chỉ ssl


Làm việc như người ở! Cảm ơn bạn đã giới thiệu tuyệt vời!
Karsten Silz

điều này cũng hữu ích, mặc dù tôi đang gặp khó khăn khi tạo báo cáo bằng cách sử dụng ngọn hải đăng
Cj Oyales

3

Như Jeff đã đề cập trong câu trả lời đầu tiên, bạn không cần https ở cấp localhost để kiểm tra Service worker. Nhân viên dịch vụ sẽ đăng ký và hoạt động tốt miễn là bạn truy cập vào miền localhost - không có HTTPS.

Khi bạn đã thử nghiệm ứng dụng của mình trên localhost và bạn muốn xem nó hoạt động như thế nào với https thực tế, thì cách đơn giản nhất là tải ứng dụng của bạn lên GitHub. Bạn có thể tạo miền công cộng miễn phí (và với HTTPS!).

Dưới đây là hướng dẫn: https://pages.github.com/


1
Câu hỏi tiếp theo sẽ là một câu hỏi dành cho Đề xuất phần mềm: Máy chủ web nào cho iOS và cho Android được khuyến nghị để thử nghiệm trên thiết bị di động bằng phương pháp localhost?
Damian Yerrick

Tôi đang sử dụng Máy chủ HTTP Erlang nhưng bất kỳ máy chủ nào cũng hoạt động. Trước đây tôi đã sử dụng máy chủ HTTP 200 từ Chrome mà bạn có thể truy cập từ Google Marketplace.
Miguel Guardo

3

Nếu bạn muốn kiểm tra service worker trên thiết bị khách không thể chạy máy chủ web trên localhost, kỹ thuật chung như sau:

  1. Đặt tên máy chủ của bạn.
  2. Cung cấp cho tên máy chủ này một chứng chỉ.
  3. Làm cho các IP tin tưởng CA đã cấp chứng chỉ này.

Nhưng nói thì dễ hơn làm. Trong một AMA tháng 11 năm 2016 trên Reddit, đại diện của Let's Encrypt thừa nhận rằng HTTPS trên mạng LAN riêng "là một câu hỏi thực sự khó và tôi nghĩ cho đến nay vẫn chưa có ai đưa ra câu trả lời thỏa đáng."

Các cách phổ biến để cấp cho máy tính của bạn một tên máy chủ liên quan đến việc cung cấp cho nó một địa chỉ IP nội bộ ổn định, không phải địa chỉ IP thay đổi hàng ngày hoặc mỗi khi bạn ngắt nguồn thiết bị cổng Internet của mình. Bạn sẽ cần phải định cấu hình máy chủ DHCP trên mạng của mình, thường là máy chủ trong cổng của bạn, để thiết lập "bảo lưu" liên kết một địa chỉ riêng cụ thể (thông thường trong 10/8hoặc 192.168/16) với địa chỉ MAC của thẻ Ethernet của máy trạm phát triển của bạn. Đối với điều này, hãy đọc hướng dẫn sử dụng cổng của bạn.

Bây giờ máy trạm phát triển của bạn có địa chỉ IP ổn định, có sự đánh đổi về thời gian / tiền bạc. Nếu bạn sẵn sàng tìm hiểu cách sử dụng DNS và OpenSSL nâng cao và cài đặt chứng chỉ gốc trên tất cả các thiết bị mà bạn định kiểm tra:

  1. Chạy một máy chủ DNS nội bộ trên mạng của bạn. Điều này có thể nằm trên cổng của bạn hoặc trên máy trạm phát triển của bạn.
  2. Định cấu hình máy chủ DNS của bạn có thẩm quyền cho một số TLD được tạo sẵn và đệ quy cho các TLD khác.
  3. Đặt tên ổn định cho địa chỉ IP riêng của máy trạm phát triển của bạn. Điều này đặt cho nó một cái tên nội bộ.
  4. Định cấu hình máy chủ DHCP của bạn để cung cấp địa chỉ của máy chủ DNS này cho các thiết bị khác đang thuê.
  5. Trên máy trạm phát triển của bạn, sử dụng OpenSSL để tạo cặp khóa cho tổ chức phát hành chứng chỉ riêng và máy chủ web.
  6. Sử dụng OpenSSL, cấp chứng chỉ gốc cho CA và chứng chỉ cho tên nội bộ của máy chủ web.
  7. Định cấu hình HTTPS trong máy chủ web trên máy trạm phát triển của bạn bằng chứng chỉ này.
  8. Cài đặt chứng chỉ gốc của CA làm chứng chỉ gốc đáng tin cậy trên tất cả các thiết bị.
  9. Trên tất cả các thiết bị, hãy truy cập tên nội bộ này.

Nếu bạn không thể thêm chứng chỉ gốc hoặc kiểm soát DNS cục bộ, chẳng hạn như nếu bạn định kiểm tra với các thiết bị do người khác sở hữu (BYOD) hoặc với các trình duyệt bị khóa khác không cho phép người dùng thêm chứng chỉ gốc đáng tin cậy, chẳng hạn như các trình duyệt chính bảng điều khiển trò chơi điện tử, bạn sẽ cần một tên miền đủ điều kiện (FQDN):

  1. Mua miền từ tổ chức đăng ký tên miền cung cấp DNS với API . Điều này có thể trực tiếp trong TLD hoặc từ một trong những nhà cung cấp DNS động đã đưa nó vào Danh sách Hậu tố Công khai. (Không thể chấp nhận các nhà cung cấp DNS động không phải PSL vì giới hạn tốc độ do Let's Encrypt áp đặt .)
  2. Trong tệp vùng của miền này, trỏ một Abản ghi tại địa chỉ IP riêng của máy trạm phát triển của bạn. Điều này cung cấp cho máy trạm phát triển của bạn một FQDN.
  3. Sử dụng Dehydrated , một ứng dụng khách ACME hỗ trợ dns-01thử thách, để lấy chứng chỉ cho FQDN này từ cơ quan cấp chứng chỉ Let's Encrypt.
  4. Định cấu hình HTTPS trong máy chủ web trên máy trạm phát triển của bạn bằng chứng chỉ này.
  5. Trên tất cả các thiết bị, hãy truy cập tên này.

1

Tôi nghĩ rằng cách dễ nhất để kiểm tra nhân viên dịch vụ là tìm một nhà cung cấp dịch vụ lưu trữ miễn phí. ngày nay, có rất nhiều trang web cung cấp dịch vụ lưu trữ miễn phí. bạn có thể dễ dàng lưu trữ ứng dụng của mình trên các máy chủ miễn phí này.

Tôi chủ yếu sử dụng herokunetlify . cái này miễn phí và dễ sử dụng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.