Имам тайна, която спестява на клиентите ми много пари, поддържа уебсайта им защитен и има вградени резервни копия.
Тайната: Правя уебсайта им статичен. След това го съхранявам и хоствам с GitHub и използвам Cloudflare, за да го обслужвам през HTTPS и да го направя бърз. Моите клиенти плащат само името на домейна си, но получават много повече, отколкото някога са се пазарили.
Статичните сайтове са невероятно бързи, тъй като няма време за обработка на сървъра. Също така, чрез ангажиране на кодова база от статични активи в хранилището на git, връщането на промените просто става въпрос за връщане към предишен коммит. Архивите са git push
далеч и по същество обслужвате целия си уебсайт от кеша, което означава, че сървърът ви почти никога няма да трябва да обработва заявка отново.
Изграждане на сложен потребителски интерфейс?
С появата на интерфейсни рамки, като React и неговите роднини, можете да създавате магически преживявания с нищо повече от HTML / CSS и JavaScript. Ще трябва да отделите вашата back-end логика от вашия front-end, но дори Ruby on Rails се доставя с API режим сега.
Винаги, когато получа договор за изграждане на уебсайт, обмислям дали статичният сайт е достатъчен, за да отговори на нуждите на моя клиент и в много случаи е така.
Чудите ли се какви случаи на употреба имам предвид? Страхотен! Нека обсъдим някои ситуации, когато може да искате да разгледате статично съдържание, и да обясним как този подход може да спести както на вас, така и на клиента ви.
Уебсайтовете за брошурен софтуер са предназначени да предоставят информация за бизнес и не се променят значително през целия им живот. Динамичното приложение очевидно е прекалено умело за такива сайтове и тъй като тези сайтове остават неподдържани в продължение на години, като получават малко, ако има някакви актуализации, те обикновено са лесни цели за хакери, добре, хак.
Статичните HTML шаблони са значително по-евтини от техните аналози на CMS и са по-лесни за ощипване в бъдеще. Разработчиците, помолени да актуализират такива сайтове, не изискват специализирани познания за конкретна CMS. Като правило винаги правя статични уеб сайтове за сайтове с брошури.
Бонус: Малкият бизнес обича да не плаща периодични месечни хостинг такси. Разбира се, хостингът не е огромна цена, но клиентите просто не трябва да си правят труда да плащат нищо друго освен домейна, което е страхотно.
Показвате ли едно прекрасно, страхотно ново приложение, което разчита на модерни фронтови рамки?
Вашето приложение вече е предимно статично. Направете няколко допълнителни стъпки, за да изолирате всяка логика от страна на сървъра в отделно приложение и да се възползвате напълно от това, че приложението ви се обслужва изцяло от кеша на Cloudflare.
Вашето заявление ще бъде достъпно по всяко време.
Това е трудна продажба. Трудно е да се убедят хората, че статични сайтове могат да се използват за блогове, но прочетете ме - не съм излязъл от дълбокия край.
Блоговете не са нищо повече от съдържание, изобразено с шаблони. Просто не се нуждаете от пълноценно приложение, което да анализира всяка заявка и да изобразява нова страница. Статичният сайт е идеален за този случай на употреба.
Обмисли Джекил . Вие го давате Течност шаблони и съдържание на Markdown и ги комбинира заедно в статичен уебсайт. Не се изисква обработка в движение и блогът ви изведнъж се чувства значително по-бързо.
Този работен процес е особено полезен, защото страниците на GitHub поддържат Jekyll компилации. Изведнъж, публикациите в блога могат да се предоставят с искания за изтегляне и цялото ви съдържание се съхранява в контрола на версиите. Не-разработчиците все още могат да допринасят за публикации в Markdown, като публикуват своите публикации чрез Stackedit .
Всъщност използвам Stackedit, за да съставя тази публикация точно сега!
Освен това, ако искате коментари за публикациите в блога си, Дискусия ви дава мощна система за коментари, като вмъкнете фрагмент от JavaScript.
Тази страница, която четете, също използва Disqus.
GitHub Pages е отговорът на GitHub на страниците на проекта и ви позволява да обслужвате всеки статичен уебсайт направо от вашето хранилище. Тъй като страниците на GitHub поддържат персонализирани домейни, можете да хоствате статичен уебсайт на страниците на GitHub безплатно, с разполагания направо от Git.
Стига говори, нека го видим в действие!
Продължих напред и направих приложение за реакция на една страница който извлича и показва текущия обменен курс за пакистанската рупия от публичен API. Нека да разгърнем това на GitHub Pages.
Първо, нека създадем ново хранилище на GitHub.
Страниците на GitHub се обслужват от клон, наречен gh-pages
така че нека създадем такъв за моя проект.
$ git checkout -b gh-pages Switched to a new branch 'gh-pages'
И нека натиснем сайта нагоре:
$ git remote add origin [email protected] :amingilani/price-check.git $ git push -u origin gh-pages Counting objects: 27, done. Delta compression using up to 8 threads. Compressing objects: 100% (25/25), done. Writing objects: 100% (27/27), 28.67 KiB | 0 bytes/s, done. Total 27 (delta 3), reused 0 (delta 0) remote: Resolving deltas: 100% (3/3), done. To github.com:amingilani/price-check.git * [new branch] gh-pages -> gh-pages
И готово! На този етап уебсайтът ще бъде достъпен на https://amingilani.github.io/price-check
с безплатен SSL:
Важни неща, които трябва да се отбележат:
index.html
файл във вашия проект gh-pages
клонUSERNAME.github.io/REPOSITORY-NAME
Обслужването на сайта извън GitHub е добре, но всеки достоен уебсайт се нуждае от персонализирано име на домейн. За щастие GitHub ви позволява Донесете собствения си домейн на партито!
Първо, нека създадем специален CNAME
файл и поставете нашето име на домейн там. Това ще позволи на GitHub да знае кое име на домейн да насочи към хранилището.
$ echo 'pricecheck.gilani.me' > CNAME $ git add . $ git commit -m 'Add a custom domain' ... $ git push ...
Второ, нека посочим a CNAME
за нашите поддомейн към DNS на GitHub при USERNAME.github.io
:
Внимание: Направете НЕ използвайте това за apex домейн! Добавяне на CNAME
запис в корена, домейнът ви ще деактивира вашия MX
и TXT
записи. Използвайте това само за вашия поддомейн. Apex домейните ще бъдат обсъдени по-късно.
На този етап нашият уебсайт трябва да работи на нашия потребителски домейн на HTTP:
Важни неща, които трябва да се отбележат:
*.github.io
домейн се обслужва чрез HTTPS.CNAME
запис на вашия апекс домейн, освен ако не искате да убиете имейлите си.Ограничения на страниците на GitHub:
Най-лесният начин да заобиколите това ограничение е да използвате www
като ваш поддомейн и пренасочете целия HTTP трафик от върха към www
. В моя пример бих пренасочил gilani.me
до www.gilani.me
, което сочи към статичния ми сайт, но не обичам да правя нещата по лесния начин.
Ако наистина искате да използвате апекс домейн, проверете дали вашият DNS доставчик ви позволява да зададете ANAME
записи. Те са (опростени) по средата между CNAME
записи, тъй като ви позволяват да сочите към домейни и A
записи, тъй като те не анулират други записи в същата зона.
Не ANAME
? Последната опция е да преминете към доставчик на DNS, който поддържа това: въведете Cloudflare. Cloudflare осигурява CNAME
сплескване на апекс домейни, което е еквивалентно на ANAME
запис. Най-добре е да превключите точно сега, тъй като ще разгледаме Cloudflare в следващия раздел.
TLDR : Превключете на безплатния DNS на Cloudflare и задайте CNAME
на вашия апекс домейн. Те правят нещо специално със своите CNAME
това го кара да работи.
Добре дошли в ерата след Сноудън. Всички наши най-лоши страхове от санкционирано от правителството шпионаж и хакване са потвърдени и светът се опитва да осигури данни при транзит и в покой.
Като модерен уеб администратор се очаква да предоставите поне SSL на уебсайта си с няма смесено съдържание .
Стигна се до точката, в която Google Chrome маркира обикновените HTTPS уебсайтове като несигурни и Google Търсене започва да облагодетелства HTTPS уебсайтовете по-благоприятно в класацията си . По-късно ще обсъдим още повече стратегии за осигуряване на сигурността на вашия преден край, но засега ще разгледаме само SSL.
За щастие вече имаме Нека шифроваме .
Това е изцяло автоматизиран сертифициращ орган (CA) с нестопанска цел, който ви позволява програмно да издавате краткосрочни 90-дневни SSL сертификати за всички контролирани от вас домейни. Това е бриз за използване; това е с отворен код; и проектът е подкрепен от множество компании, включително Mozilla и Electronic Frontier Foundation.
Cloudflare е услуга за защита на DNS, CDN и DDoS.
Той кешира уебсайта ви и го обслужва от потребители от географски близки сървъри, което прави уебсайта ви по-бърз. Той има допълнителното предимство да ви държи под ограничението на честотната лента на GitHub от 100 GB, защото дори ако уебсайтът ви стане безумно популярен, повечето заявки ще ударят кеша и никога няма да достигнат до сървъра.
На всичкото отгоре Cloudflare предлага услуга, наречена Универсален SSL където те ви издават безплатен SSL сертификат от своите партньори от CA, така че получавате HTTPS безплатно ... завинаги.
Знам какво си мислиш: Гилани, току-що ми каза колко страхотно е Let’s Encrypt. Защо говориш за Cloudflare? Е, всичко се свежда до простотата.
Като мисловно упражнение си представете създаването на множество кеш памет на Nginx и обратните прокси сървъри, като им давате всички валидни SSL сертификати и обслужвате потребителски уеб страници от най-близките им местоположения.
Това води до това, че вашият уебсайт се обслужва чрез SSL, дори ако първоначалният сървър няма SSL сертификат, въпреки че Cloudflare ви дава специални самоподписани сертификати, които можете да поставите на вашия първоначален сървър, за да осигурите връзката със сървърите на Cloudflare. Това е, което Cloudflare ви дава с безплатен план и дори не е нужно да подновявате сертификата си на всеки 90 дни.
Като свободна професия получавам клиенти, които искат сайт да работи и работи за своя бизнес възможно най-бързо. Те не разбират или не се интересуват от проблеми със сигурността, измъчвания на съвременната мрежа или криптиране по време на транзит. Някои клиенти се борят да разберат идеята за имена на домейни и им е досадно, когато трябва да платят 15 долара годишна такса „само за да поддържа уебсайта ми работещ“. Затова опитайте да им обясните защо трябва да плащат за клъстер от обратни прокси сървъри, защитаващи уебсайта им, който работи на самия безплатен хостинг.
Нека отново си изцапаме ръцете. Първото нещо, което трябва да направите, е да преминете към маршрутизиране на целия си трафик през Cloudflare:
След това, под Крипто, задайте нивото на SSL на „Пълно“.
Принудете „Автоматично пренаписване на HTTPS“, за да убиете предупреждения за смесено съдържание.
На този етап нашият уебсайт ще работи както по HTTP, така и по HTTPS. Нека принудим HTTPS за всичко в нашия домейн.
Готово. Нашият уебсайт винаги трябва да се зарежда през HTTPS със зелена оценка „Сигурно“ в Chrome.
какво се случва, когато една компания подаде глава 11
Има няколко неща, които не съм обсъждал по-горе и бих искал да отделя малко време, за да изясня няколко точки.
Проницателният сред вас ще посочи, че има няколко очевидни проблема със сигурността при тази настройка, а именно, че няма защитени HTTP заглавки като:
Content-Security-Policy
: зарежда скриптове и активи от бял списък с хостове и може да забрани вградените js.X-Frame-Options
: деактивира уебсайта Ви да се зарежда в рамка.И си прав. Страници в GitHub и дори Cloudflare не ви позволяват да персонализирате своите HTTP заглавки . Можете обаче да зададете CSP, като използвате HTML meta
етикет.
Просто поставете това във вашата уеб страница:
X-Frame-Options
В момента обаче няма практичен начин за задаване на iframe
заглавка на страници в GitHub, което означава, че нападателят може да зареди вашата уеб страница в специално създаден gh-pages
и издърпайте XSS атака. Ако сте посветени обаче, можете да заобиколите този проблем, като помолите потребителите да потвърдят паролата си или 2FA токена при всяко чувствително действие или като предадете CSRF токен при всяко удостоверено искане.
Основна загриженост за някои е, че чрез използването на безплатните публични хранилища в GitHub вашият уебсайт и изходният код са достъпни за всеки, който иска да го раздели или изтегли. Така че мисля, че загрижеността тук е объркана.
Статичното съдържание не е изходен код в смисъл, че не се компилира или обработва като скрипт, преди да бъде предоставено на потребителя. Вашият потребител ще получи точно същото статично копие на уебсайта, ако трябва да стартира уеб робот, насочен към вашия уебсайт. Въпреки че хостването на кода в хранилище на GitHub със сигурност улеснява изтеглянето на копие от вашия уебсайт, той не излага нищо, което вече не е било публично.
Идеите, представени в тази статия, не се ограничават до безплатен уеб хостинг на малки приложения.
Можете да изградите преден слой, базиран на модерна JavaScript рамка, да го свържете към широкомащабен облак-базиран Backend-as-a-a-service (BaaS), като Firebase и създавайте сложни приложения, без да се притеснявате за сървъри, ъптайм или друг проблем, свързан с инфраструктурата.
Създаване на нова вълнуваща уеб базирана игра ?! Разгледайте GameSparks , и вие сте добре да отидете.
Използването на Github Pages като „стандартна“ хостинг услуга, която се очаква да обработва уеб страници с висока честотна лента, не се препоръчва и не трябва да се прави. Добавянето на Cloudflare CDN върху GitHub Pages прави това решение да работи. Cloudflare е много повече от безплатна SSL услуга. Това е компания с глобален CDN, който предпазва уебсайта ви от пренапрежения и поддържа натоварването на страниците на GitHub сведено до минимум.В тази статия направих така, че да изглежда така, сякаш съм публикувал ръчно приложението си React в master
. Не съм правил такова нещо. Работих върху npm run deploy
и когато дойде време за разполагане, изтичах gh-pages
който стартира скрипт за компилация и изтласка компилацията до master
. Моля, вижте
|_+_|клон на хранилището ми, за да видите как работи.
Професионалисти:
Предупреждения:
Връзки: