בדרך כלל, http://localhost
מתנהג כמו HTTPS למטרות פיתוח. עם זאת, יש כמה מקרים מיוחדים, כמו שמות מארחים מותאמים אישית או שימוש בקובצי cookie מאובטחים בדפדפנים, שבהם צריך להגדיר במפורש את אתר הפיתוח כך שיפעל כמו HTTPS על מנת לייצג בצורה מדויקת את אופן הפעולה של האתר בסביבת הייצור. (אם באתר בסביבת הייצור לא נעשה שימוש ב-HTTPS, כדאי להגדיר עדיפות למעבר ל-HTTPS).
בדף הזה מוסבר איך להפעיל את האתר באופן מקומי באמצעות HTTPS.
להוראות קצרות, ראו עיון מהיר ב-mkcert.**
הפעלת האתר שלך באופן מקומי באמצעות HTTPS באמצעות mkcert (מומלץ)
כדי להשתמש ב-HTTPS באמצעות אתר הפיתוח המקומי ולגשת אל https://localhost
או אל https://mysite.example
(שם מארח מותאם אישית), צריך אישור TLS שחתום על ידי ישות שהמכשיר והדפדפן סומכים עליה. רשות אישורים (CA) מהימנה.
לפני יצירת חיבור HTTPS, הדפדפן בודק אם האישור של שרת הפיתוח חתום על ידי CA מהימן.
כדי ליצור את האישור ולחתום עליו, מומלץ להשתמש ב-mkcert, רשות אישורים בפלטפורמות שונות. תוכלו לקרוא עוד אפשרויות שימושיות במאמר הפעלת האתר באופן מקומי באמצעות HTTPS: אפשרויות אחרות.
במערכות הפעלה רבות יש ספריות ליצירת אישורים, כמו openssl. עם זאת, הם מורכבים יותר ופחות אמינים מ-mkcert, והם לא בהכרח חוצי-פלטפורמות, ולכן צוותי המפתחים גדולים יותר יכולים לגשת אליהם פחות.
הגדרה
התקנת mkcert (פעם אחת בלבד).
פועלים לפי instructions להתקנת mkcert במערכת ההפעלה. לדוגמה, ב-macOS:
brew install mkcert brew install nss # if you use Firefox
יש להוסיף את mkcert לרשויות האישורים המקומיות ברמה הבסיסית.
בטרמינל, מריצים את הפקודה הבאה:
mkcert -install
הפעולה הזו יוצרת רשות אישורים מקומית (CA). רשות האישורים המקומית, שנוצרה על ידי mkcert, מהימנה רק באופן מקומי במכשיר.
יוצרים אישור לאתר, חתום על ידי mkcert.
בטרמינל, עוברים לספריית הבסיס של האתר או לספרייה שרוצים לשמור בה את האישור.
לאחר מכן, מפעילים את הפקודה:
mkcert localhost
אם משתמשים בשם מארח מותאם אישית כמו
mysite.example
, מריצים את הפקודה:mkcert mysite.example
הפקודה הזו מבצעת שתי פעולות:
- יוצר אישור לשם המארח שציינת.
- עכשיו mkcert יחתום על האישור.
האישור שלך מוכן עכשיו וחתום על ידי רשות אישורים שבה הדפדפן נותן אמון באופן מקומי.
הגדירו את השרת לשימוש ב-HTTPS באישור ה-TLS שיצרתם.
הפרטים לביצוע פעולות אלה תלויים בשרת שלכם. הנה כמה דוגמאות:
👩🏻 💻 עם הצומת:
server.js
(החלפת{PATH/TO/CERTIFICATE...}
ו-{PORT}
):const https = require('https'); const fs = require('fs'); const options = { key: fs.readFileSync('{PATH/TO/CERTIFICATE-KEY-FILENAME}.pem'), cert: fs.readFileSync('{PATH/TO/CERTIFICATE-FILENAME}.pem'), }; https .createServer(options, function (req, res) { // server code }) .listen({PORT});
👩🏻 💻 באמצעות http-server:
מפעילים את השרת באופן הבא (מחליפים את
{PATH/TO/CERTIFICATE...}
):http-server -S -C {PATH/TO/CERTIFICATE-FILENAME}.pem -K {PATH/TO/CERTIFICATE-KEY-FILENAME}.pem
-S
מפעיל את השרת עם HTTPS, ואילו-C
מגדיר את האישור ו--K
מגדיר את המפתח.👩🏻 💻 באמצעות שרת פיתוח React:
עורכים את
package.json
באופן הבא ומחליפים את{PATH/TO/CERTIFICATE...}
:"scripts": { "start": "HTTPS=true SSL_CRT_FILE={PATH/TO/CERTIFICATE-FILENAME}.pem SSL_KEY_FILE={PATH/TO/CERTIFICATE-KEY-FILENAME}.pem react-scripts start"
לדוגמה, אם יצרתם אישור ל-
localhost
בספריית השורש של האתר:|-- my-react-app |-- package.json |-- localhost.pem |-- localhost-key.pem |--...
לאחר מכן הסקריפט
start
אמור להיראות כך:"scripts": { "start": "HTTPS=true SSL_CRT_FILE=localhost.pem SSL_KEY_FILE=localhost-key.pem react-scripts start"
👩🏻 💻 דוגמאות נוספות:
פותחים את
https://localhost
או אתhttps://mysite.example
בדפדפן כדי לוודא שאתם מפעילים את האתר באופן מקומי באמצעות HTTPS. לא יוצגו אזהרות בדפדפן כי הדפדפן סומך על mkcert כרשות אישורים מקומית.
מסמך עזר מהיר של mkcert
כדי להפעיל את אתר הפיתוח המקומי באמצעות HTTPS:
-
הגדרת mkcert.
אם עדיין לא עשיתם זאת, מתקינים את mkcert, למשל ב-macOS:
brew install mkcert
לקבלת הוראות ל-Windows ול-Linux, עיינו במאמר על התקנת mkcert.
לאחר מכן, יוצרים רשות אישורים מקומית:
mkcert -install
-
יוצרים אישור מהימן.
mkcert {YOUR HOSTNAME e.g. localhost or mysite.example}
הפעולה הזו יוצרת אישור תקף שחותם mkcert באופן אוטומטי.
-
מגדירים את שרת הפיתוח לשימוש ב-HTTPS ובאישור שיצרתם בשלב 2.
עכשיו אפשר לגשת אל https://{YOUR HOSTNAME}
בדפדפן, ללא אזהרות
</div>
הפעלת האתר באופן מקומי באמצעות HTTPS: אפשרויות נוספות
בהמשך מפורטות דרכים נוספות להגדיר את האישור. בדרך כלל השיטות מסובכות או מסוכנות יותר משימוש ב-mkcert.
אישור עם חתימה עצמית
תוכלו גם להחליט לא להשתמש ברשות אישורים מקומית כמו mkcert, ובמקום זאת לחתום על האישור בעצמכם. לגישה הזו יש כמה טעויות:
- הדפדפנים לא סומכים עליכם כרשות אישורים, ולכן יוצגו להם אזהרות שצריך לעקוף באופן ידני. ב-Chrome אפשר להשתמש בדגל
#allow-insecure-localhost
כדי לעקוף את האזהרה הזו באופן אוטומטי ב-localhost
. - האפשרות הזו לא בטוחה אם אתם עובדים ברשת לא מאובטחת.
- התהליך הזה לא בהכרח קל או מהיר יותר משימוש ברשות אישורים מקומית כמו mkcert.
- אישורים בחתימה עצמית לא יפעלו בדיוק כמו אישורים מהימנים.
- אם לא משתמשים בשיטה הזו בהקשר של דפדפן, צריך להשבית את אימות האישורים לשרת. אם לא תפעילו אותה מחדש בסביבת הייצור, זה יגרום לבעיות אבטחה.
אם לא מציינים אישור, אפשרויות ה-HTTPS של שרת הפיתוח של React's ו-Vue ייצרו אישור בחתימה עצמית. זו דרך מהירה, אבל היא כוללת אותן אזהרות בדפדפן ושגיאות אחרות שקשורות לאישורים בחתימה עצמית. למרבה המזל, אפשר להשתמש באפשרות ה-HTTPS המובנית ב-frameworks של ממשק הקצה, ולציין אישור מהימן מקומי שנוצר באמצעות mkcert או אישור דומה. למידע נוסף ראו את הדוגמה mkcert עם React.
אם פותחים את האתר שפועל באופן מקומי בדפדפן באמצעות HTTPS, הדפדפן יבדוק את האישור של שרת הפיתוח המקומי. המערכת מזהה שחתמת על האישור בעצמך, ובודקת אם נרשמת כרשות אישורים מהימנה. מאחר שלא זוהתה טעות, הדפדפן לא יכול לתת אמון באישור, ומוצגת אזהרה שמציינת שהחיבור שלך לא מאובטח. הפעולה עדיין תיצור חיבור HTTPS אם תמשיך, אבל יצירת החיבור נעשית על אחריותך בלבד.
אישור חתום על ידי רשות אישורים רגילה
ניתן גם להשתמש באישור שחתום על ידי רשות אישורים רשמית. יכולות להיות לכך כמה סיבוכים:
- יש יותר משימות הגדרה מאשר כשמשתמשים בשיטת CA מקומית, כמו mkcert.
- עליכם להשתמש בשם דומיין תקין שנמצא בשליטתכם. במילים אחרות, לא ניתן להשתמש ברשויות אישורים רשמיות עבור השירותים הבאים:
localhost
ושמות דומיינים שמורים אחרים כמוexample
אוtest
.- שמות דומיין שאינם בשליטתך.
- דומיינים לא חוקיים ברמה העליונה. למידע נוסף, ניתן לעיין ברשימת הדומיינים התקינים ברמה העליונה.
היפוך שרת proxy
אפשרות נוספת לגשת לאתר שפועל באופן מקומי באמצעות HTTPS היא באמצעות שרת proxy הפוך כמו ngrok. הסיכונים האלה כוללים:
- כל מי ששיתפתם איתו את כתובת ה-URL של שרת ה-proxy ההפוך יכול לגשת לאתר הפיתוח המקומי שלכם. כך תוכלו להדגים את הפרויקט ללקוחות, אבל היא יכולה גם לאפשר לאנשים לא מורשים לשתף מידע רגיש.
- בחלק משירותי ה-proxy ההפוך מחייבים שימוש, ולכן התמחור עשוי להיות גורם משמעותי בבחירת השירות.
- אמצעי אבטחה חדשים בדפדפנים יכולים להשפיע על אופן הפעולה של הכלים האלה.
סימון (לא מומלץ)
אם משתמשים בשם מארח מותאם אישית כמו mysite.example
ב-Chrome, אפשר להשתמש בדגל כדי לאלץ את הדפדפן להתייחס לדפדפן mysite.example
כמאובטח. הימנעו מכך מהסיבות הבאות:
- אתם צריכים להיות בטוחים ב-100% ש-
mysite.example
תמיד מפנה לכתובת מקומית. אחרת, יש סיכון להדלפת פרטי הכניסה לסביבת הייצור. - הסימון הזה פועל רק ב-Chrome, כך שלא ניתן לנפות באגים בדפדפנים שונים.
אנחנו מודים לך מאוד על תרומתך ועל המשוב לכל הבודקים והשותפים – במיוחד ריאן סלבי, פיליפו ולסורדה, מיליקה מיהאג'ליג'ה ורואן מרווד. 🙌