Въпреки че има много решения на трети части за този проблем, нито едно от тях наистина не работи така, както трябва. Днес реших да напиша пълно ръководство стъпка по стъпка, за да разреша този проблем веднъж завинаги 🎉

Заден план

Има множество безплатни или платени „услуги за формуляри“ там, включително SendGrid, Mailgun, Pepipost или дори Jumprock, които самият аз използвах за известно време, но повечето от тези услуги не работят добре с fetch ​​или XMLHttpRequest поради проблеми, свързани с CORS, така че ще откриете, че изпращате имейли чрез HTML формуляри, в крайна сметка пренасочвайки потребителите си към предишната страница след това.

Това е повече от добре, ако живеете през 90-те, но в ерата на SPA и PWA те са лесно остарели или дори безполезни, тъй като нямате пълен контрол върху жизнения цикъл на изпратения имейл, следователно вие не може да запази състоянието на страницата ви, тъй като се дължи на пренасочвания.

В този сценарий, където дори скритите „вградени рамки“ като цел на публикация не биха работили, нашият Service Worker също ще има трудности при обработването на имейл заявки.

Тъй като не съм от този тип хора, които приемат грозни компромиси в областта на програмирането, намерих лесно и евтино решение да поддържам уебсайтовете си едновременно статични и способни да ми изпращат прости имейли, чрез малки помощни програми, които правят едно нещо, и (надявам се 😅) го направи добре.

Първоначално планирах сам да създам такава услуга и да предложа справедливи планове за всички, но пейзажът за изпращане на имейли е сложен и пълен със скрити предупреждения, така че след като открих решението за моите нужди, реших да помогна на всички останали с подобни нужди чрез тази публикация.

Услугите, които харесвам и използвам

Сигурен съм, че има различни алтернативи, които могат да предоставят подобни резултати, но услугите, които съм използвал и харесвам най-много, са следните:

  • iwantmyname е услугата за регистрация и обработка на домейни, която използвам от не знам колко години. Убийствено лесен за използване, не ви създава главоболия, когато искате да спрете подновяването на домейн, и не само има много справедливи цени за различни домейни, но също така предлага всичко необходимо за конфигуриране на трети части DNS манипулатори или услуги.
  • GitHub или GitLab са безпроблемните хранилища, които да използвате, за да проследите всичките си промени, да върнете назад, да публикувате чрез кукички и така нататък, и така нататък. И двете ви позволяват да публикувате статични уебсайтове безплатно и двете предлагат частни хранилища, за да запазите вашата „бъркотия“ в тайна, но тук ще използваме всички необходими предпазни мерки, за вероятно никога няма да има нужда от частно хранилище. Имайте предвид, че ако дори не е необходимо да изпращате имейли от статичния си сайт, iwantmyname има страхотна документация за лесно насочване на всеки домейн към статичното ви GitLab/Hub хранилище, така че това вече е прекрасно решение, което струва нула. Добавете Cloudflare към този микс и вашият статичен сайт също ще има безплатно HTTPS.
  • zeit now v2 е най-лесният начин да публикувате всеки статичен уебсайт безплатно, като също така предоставя лесни функции без сървър, за да надхвърлите статичното. Вашият сайт наистина може да се мащабира по всяко време, но за да започнете да публикувате всичко, от което се нуждаете, е public/ папка с всички статични активи, които искате, и now CLI за публикуване на тези активи на живо. Аз лично не се интересувам много от всички рамки, които предлага извън кутията, тъй като heresy-ssr не е една от тези 😜, но това със сигурност е още един плюс за тази платформа, за който трябва да проучите малко повече. Zeit сега също мащабира своите платени планове и всъщност не ви заключва, което го прави печеливш за повечето случаи на обичайна употреба.
  • Amazon Simple Email Service (SES) очевидно е най-евтиният имейл доставчик в мрежата, така че дори ако вашият сайт има огромен обем имейли, можете да преминете към платен план по всяко време, и надхвърлят всяка първоначална граница на безплатния план. Честно казано, аз не харесвам несъществуващите устойчиви политики на Amazon и ако имаше нещо подобно евтино, но екологично, бих преминал веднага към тази услуга вместо това и това важи за всеки друг SaaS, който използвам , или предлагайте, ежедневно.

⚠ Относно сигурността

Преди да продължа по-нататък, бих искал да подчертая, че повечето информация, използвана за конфигуриране на всичко, за което ще говоря, никога не трябва да се разкрива.

Има и други неща, които трябва да обмислите занапред, така че, моля, уверете се, че сте прочели следния контролен списък за сигурност до края:

  • Идентификационните данни никога не трябва да се публикуват във вашето хранилище. Ако направите това случайно, освен ако хранилището не се пази в тайна завинаги и може би дори в такъв случай, изтрийте вашето хранилище и започнете от нулата, като не забравяте никога повече да не пробутвате нищо поверително там.
  • Изпращането на имейл чрез JavaScript е абсолютно същото като изпращането на имейл чрез който и да е формуляр на уеб страница. Да, някой трол може да започне да ви изпраща произволни имейли и няма много какво да направите там. Обаче техниките, описани в тази публикация, никога няма да позволят на посетителите на вашия уебсайт да знаят имейла на местоназначението, което вместо това е проклятие за всеки <a href="/bgmailto:...">. Съответно, като се има предвид, че сега взема мерки срещу DoS и като се има предвид, че вашият имейл никога не е изложен на посетители, тези техники могат да се считат за по-добри, по отношение на нежелан спам, от mailto: връзки, но също толкова склонни към DoS, колкото всяка друга жива форма.
  • Ако маркирате имейли, които получавате от собствените си сайтове, като спам, вие носите отговорност за собствените си проблеми с имейлите и репутацията на сайта. Просто недей!
  • дори ако предложената JS библиотека използва всяка възможна защитна техника, за да избегне намесата на скриптове от трети части в нейната логика, се препоръчва да използвате модули и пакети, за да я импортирате или да съхранявате такава променлива в частен обхват, както е показано по-късно, така че да не се достига лесно чрез конзола. Това може да помогне за намаляване на троловите атаки.
  • ако сте защитили JS библиотеката, но не искате всеки робот на тази планета да спами вашия имейл с ненужни глупости, можете да регистрирате reCAPTCHA за вашия сайт , както е документирано по-късно, или друго подобно решение и изпращайте имейли само след успешни резултати. Това не е задължително да ви предпази от DoS атаки, но със сигурност ще филтрира повечето роботи, които ще се опитат да изпратят всеки формуляр, който намерят в интернет.
  • Накрая, но не на последно място, избрах името /api/paperboy в моите примери, за да го запазя просто и разбираемо, но трябва по-добре да наименувате функционалните си файлове без сървър, като използвате нещо по-малко предвидимо, като изхода, произведен чрез npx uuid команден ред, така че да не се задействат имейли само с натискане на /api/paperboy

Като имаме предвид всички тези точки, вече сме готови да конфигурираме нашия уебсайт 👍

Софтуерът, от който се нуждаете

Всичко обяснено в тази публикация предполага, че имате инсталиран следния софтуер и можете да го използвате чрез конзола/терминал:

Технически не се нуждаете от редактор, за да работите с проекта, но разбира се всеки, когото харесате, вероятно ще бъде полезен.

Вземете своя домейн

Регистрирането на домейн не само прави вашия статичен сайт лесен за достигане чрез URL, но също така го прави подходящ за повечето услуги, включително имейли или reCAPTCHA. Zeit now също предлага лесен интерфейс за конфигуриране, стига да можете да промените домейна DNS, така че вече да не бъде вашата услуга за домейн, обработваща тези, но zeit now вместо това.

За по-голяма простота ще говоря за домейна static.email или your.site в тази публикация, но всеки път, когато споменавам един от тях, имам предвид домейна, който сте закупили .

Както споменахме по-горе, най-важното нещо, което услугата за регистриране на домейни трябва да предлага, е възможността да променяте или актуализирате сървърите на имена, така че по-късно да можете да поставите тези, предоставени от вашата хостинг услуга, в този случай zeit сега.

Един домейн има цена, която варира от разумно ниска до изключително висока, но това не зависи от услугата, която използвате, а по-скоро бизнесът зад такъв домейн определя цената.

Средно можете да имате доста добри домейни за около $12 на година, което не би трябвало да е голяма работа както за любители, така и за професионалисти.

Създайте свой проект, базиран на Git

Можете или да създадете празно хранилище чрез GitHub или GitLab и след това да го клонирате локално, или просто да създадете папка с име на домейна, който сте купили, и да въведете следното, след като влезете в такава папка.

git init

На този етап вие сте настроени да извършвате промени във вашия статичен уебсайт, със смислени регистрационни файлове и възможност за връщане назад по всяко време.

Първият проектен файл

Тъй като сигурността трябва да бъде основната ни грижа по отношение на всичко, което се озовава онлайн, първият файл, който трябва да създадем в папката на нашия домейн, е .gitignore с поне следното съдържание:

node_modules/
.env

Обикновено добавям и файл package-lock.json в такъв списък, за да избегна споделянето на съдържанието му с бъдещото си аз или други, които допринасят за проекта.

Моля, имайте предвид, че името на файла трябва да бъде точно .gitignore, което е gitignore „разширението“ на файл без име.

Пакетът package.json

Можете или да въведете npm init -y в папката на домейна, или просто да копирате и поставите следното съдържание във файл package.json.

{
  "private": true,
  "scripts": {
    "local": "http-server ./public"
  },
  "devDependencies": {
    "http-server": "^0.11.1"
  },
  "dependencies": {
    "dotenv": "^8.1.0",
    "static.email.ses": "^0.1.3"
  }
}

След това трябва да въведете npm i, за да инсталирате обикновени и dev зависимости, което ще създаде node_modules папки, вече игнорирани от хранилището.

Публичната папка

Въвеждането на npm run local в тази папка ще завърти локален сървър, за да тества вашия статичен сайт, но той очаква да намери папка ./public/ с малко съдържание.

Заради тази демонстрация ще създадем папка, която също съдържа папки css и js, където ще поставим файл по-късно.

mkdir -p public/{css,js}

Ако сте в Windows и без Bash shell, използвайте мишката или друга команда, която знаете, за да създадете public със също public/css и public/js папки вътре.

index.html

За да можете да тествате нашия най-основен статичен сайт, с възможност по-късно да изпращате имейли, създайте index.html файл в публичната папка.

Този индекс съдържа следните външни зависимости:

  • основния CSS файл за стилизиране на съдържанието на страницата
  • помощникът static.email JS, използван за изпращане на имейли
  • основния JS файл, използван за стартиране на формуляра или нещо друго

CSS

Използвах следното съдържание за моя файл public/css/index.css:

JS

Както бе споменато в параграфа за сигурност и тъй като в момента не използвам модули или пакети, за да го опростя, когато включим библиотеката StaticEmail като глобална променлива, трябва да се опитаме да избегнем непрекъснатото изтичане в глобалния обхват. Следният код, който трябва да бъде записан в public/js/index.js, също ще използва формуляра на страницата, за да може да изпраща имейли при изпращане.

Демонстрация на локалния сървър

Ако сме направили всичко както трябва, трябва да можем да достигнем до http://localhost:8080/ след като напишем следното:

npm run local

Получената страница трябва да изглежда някак подобно на тази:

За да спрете работата на сървъра по всяко време, използвайте комбинацията Ctrl+c или Command+c, ако сте на Mac.

Можете да тествате формуляра!

Помощната програма static.email ще се провали, ако сървърът не отговори със статус 200.

Повечето често срещани грешки обаче се предават като съобщение, за да можем да разберем дали сървърът, като този, създаден чрез http-server, не може да се справи с публикувани данни, връщайки 405 вместо 200.

В края на краищата статичният уебсайт обикновено никога не може да приеме публикувани данни, но тъй като сървърът би върнал много конкретно съобщение за грешка, кодът може да се справи с него и да реши да фалшифицира успех, неуспех или и двете, както е за примерния код.

function (error) {
  // this check is to make code testable via http-server
  if (
    error.message === 'Method Not Allowed'
    // handle 405 errors as either OK (75%) or errors
    // if you don't want errors, comment the following line
    && Math.random() < .75
  )
    thanks();
  else {
    alert(error);
    contact.submit.disabled = false;
  }
}

Чувствайте се свободни да коментирате реда && Math.random() < .75 във файла public/js/index.js, ако искате винаги да виждате успешно изпращане, или променете кода, за да се справите по-добре с възможни грешки, тъй като те винаги могат да се случат в реалния свят.

След като попълните и двете полета, трябва да видите обратна връзка като:

Вашият първи ангажимент

Тъй като вече разполагаме с всички основни неща, за да започнем да разработваме нашия статичен сайт, може би е подходящ момент да ангажираме всичко, което сме направили досега, така че в крайна сметка да можем да върнем назад, в случай че се провалим с други постепенни промени.

git add .
git commit -m 'basic static site ready'

Винаги можете да прочетете историята на ангажиментите, като напишете git log.

Стартирайте на живо със Zeit сега

Услугата zeit.co сега е както лесна за използване, така и има „изключително конкурентни цени“, като се започне от безплатния план, който позволява 5000 заявки на ден до всяка безсървърна функция, предлагаща неограничена честотна лента за активи, обслужвани чрез CDN.

Нашата публична папка е мястото, където се намират тези активи и 5000 заявки на ден трябва да са повече от достатъчни за всеки малък до среден бизнес.

Но не се страхувайте, започвайки от $0,99 на месец, можете лесно да увеличите мащаба, така че вместо да купувате пакет цигари, където в Обединеното кралство е до £12,5 всяка, можете да „пушите други фирми“ за същата цена, изразходвана за цяла година.

Сега Влезте

Ако все още не използвате now ежедневно, можете да започнете сега, като следвате тяхната страница с документация за започване на работа или просто напишете следното:

npm i -g now
now login

login вероятно ще поиска вашия имейл адрес, който може да бъде всеки, който използвате ежедневно, като например GMail, Outlook и други.

За по-голяма простота ще използвам [email protected] като псевдоним за вашия имейл адрес, но за да потвърдите правилно вашето влизане, вашият имейл адрес трябва да е валиден, тъй като ще има връзка за насрещна проверка, изпратена на адреса, който предоставяте.

Сега стартирайте на живо

След като успешно влезете с сега, всичко, което трябва да направите от папката на вашия домейн, е да напишете:

now

CLI ще копира във вашия клипборд достъпен URL, който вече ще показва вашия сайт: не се колебайте да го посетите, тъй като той трябва да показва точно същата страница, на която сте били проверка локално, с изключение на това, че изпращането на формуляра винаги ще бъде неуспешно, защото няма наличен API (все още).

Това е добра първа стъпка, за да проверите, че вашата настройка сега работи според очакванията, всичко, което трябва да направим на този етап, е да насочим домейна към текущото внедряване.

Сега използвайте домейна

Ако влезете през уеб интерфейса и стигнете до раздела за домейни, трябва лесно да добавите закупения домейн към вашия проект, който е посочен по име на папка, така че да не може да бъде по-лесно да разберете кой то е.

Изберете вашата папка, дори ако името не отразява домейна, който сте закупили, и щракнете върху продължи, за да свържете домейна, който сте купили, с такава папка.

Ще получите инструкции как да актуализирате вашите DNS стойности, за да сочат към zeit.world, и след като ги актуализирате чрез страницата за администратор на iwantmyname, само въпрос на минути, ако не и секунди, е преди вашият домейн да бъде достъпен.

Сега публикувайте в продукцията

След като домейнът е конфигуриран, всичко, което е необходимо, за да стане достъпен чрез https://static.email или какъвто и да е домейн, който сте закупили, е да въведете следното:

now --prod

След минута или по-малко трябва да можете да посетите домейна, който все още трябва да представя същата страница, която сте виждали досега.

Сега добавете функция без сървър

Преди да можем наистина да изпращаме имейли, трябва да създадем крайна точка, способна да приема заявки от нашия сайт.

mkdir -p api

Създайте папка api във вашия проект за домейн, не в този public, и поставете следното съдържание във файла api/paperboy.js:

module.exports = (request, response) => {
  if (request.method === 'POST')
    response.status(200).send('OK');
  else
    response.status(400).send('Bad Request');
};

Това е всичко, сървърът вече може да отговори на библиотеката StaticEmail с 200 и ще върне 400 за всяка заявка, която не е публикация.

Това е най-основната функционалност, която можем да имаме, за да започнем да тестваме нашата функция без сървър чрез статичния сайт, който сме изградили досега.

Запазете файла и въведете now --prod отново, за да го видите на живо. На този етап формулярът трябва да работи всеки път, освен ако сайтът не е достъпен поради мрежови условия и трябва да прочетете Bad Request, ако посетите /api/paperboy директно.

Ако всичко работи според очакванията, ние сме много близо до възможността да използваме формуляра по смислен начин. Всичко, което липсва, е услуга, която ще ни позволи да изпращаме имейли чрез нашата функция без сървър.

Можем също така да извършим всички промени, както се справяме страхотно досега.

git add .
git commit -m 'the site is "now" live'

Amazon Simple Email Service (SES)

Това вероятно е най-сложната част от нашето пътуване, тъй като включва различни операции, свързани със сигурността, които (за съжаление) не могат да се конкурират с лекотата zeit now, предлагана досега.

Това е и времето, когато ще поставим съдържание във файла .env, тъй като ще бъде много удобно да се позовавате на него за всяка настояща или бъдеща промяна.

В края на тази част такъв файл трябва да изглежда като следния, с правилната информация, присвоена на всяка променлива:

[email protected]
AWS_SES_REGION=your-aws-region
AWS_SES_ACCESS_KEY=your-aws-iam-access-key
AWS_SES_SECRET_KEY=your-aws-iam-secret-key

Не забравяйте, че файлът .env не трябва да се създава в папката public, а само в главната папка на вашия домейн и ще бъде безопасно игнориран от двете операции git, както е дефинирано по-рано чрез файла .gitignore, но също така ще бъде игнориран от now CLI операции ... разбра ли? Да започваме!

Създай профил

Ако не сте правили това преди, трябва да влезете в Amazon SES.

След като направите това, влезте в конзолата си и потърсете Simple Email Service, след което отидете в този раздел.

Изберете регион

Не съм сигурен в кой момент ще бъдете помолени да изберете регион за вашите услуги, но всеки регион близо до вашата страна трябва да е достатъчно добър.

Ако не намерите такъв регион, просто изберете един от Съединените щати, тъй като сървърите на zeit now вероятно така или иначе са близо до тези региони и внедряването може да обхваща множество региони.

Запишете избрания регион във вашия .env файл след запис AWS_SES_REGION=.

Добавете своя домейн

Щракнете върху домейни в менюто отляво, след което върху Потвърдете нов домейн.

Добавете записа за проверка на домейна сега

Проверката е необходима, така че Amazon SES да знае, че имейлите, идващи от [email protected], имат известен обект зад себе си.

За да добавите този запис за проверка на домейн в zeit сега, трябва да въведете следното от папката на вашия домейн:

now dns add your.site _amazonses TXT yadaYadayAdayaDayadA

където your.site е вашият действителен домейн, а yadaYadayAdayaDayadA е действителната стойност, предоставена от Amazon.

Можете да използвате същата команда, за да добавите евентуално друг ключ, но те няма да бъдат нито необходими, нито обхванати в тази публикация.

За да можете да получавате имейли на собствения си адрес, това трябва да бъде потвърдено.

Потвърдете имейл адреса си

Процедурата за това е доста проста: отивате в секцията Имейл адреси и щракнете върху бутона Потвърдете нов имейл адрес.

Проверката е доста проста: ще получите имейл на адрес [email protected] и трябва да потвърдите, че сте получили такъв имейл.

Това трябва да е достатъчно, за да видите следващия път, когато проверите страницата на SES, че имейлът ви е потвърден.

Запишете имейла си във вашия .env файл след запис AWS_SES_TO=.

Управление на самоличността и достъпа (IAM)

Това е последната част от информацията, която трябва да потвърдите, този път за всяко взаимодействие, което ще имате от вашия сайт към всяко обаждане на Amazon SES.

Първо, трябва да достигнете правилната страница, където ще трябва да щракнете върху бутона Добавяне на потребител.

Ще се окажете в режим от 5 стъпки и можете просто да игнорирате третата стъпка, тъй като не е необходимо да настройвате имейли на този етап.

Етап 1

Поставете произволно име като Потребителско име, но за да поддържате нещата организирани, предлагам да въведете домейна, който сте купили.

Не забравяйте също да поставите отметка в квадратчето Програмен достъп, тъй като това позволява обмен с вашия сайт.

Стъпка 2

Щракнете върху бутона Прикачване на съществуващи правила директно и филтрирайте правилата, като напишете SES в него. Проверете пълния достъп до Amazon SES, за да се уверите, че можете да изпращате имейли, и не се колебайте да пренебрегнете стъпка 3.

Стъпка 4

Прегледайте въведените досега данни, особено Потребителското име и Управляваната политика.

Стъпка 5

Ако всичко е минало гладко, трябва да прочетете съобщение за успех 🎉

Ако разгледате такова съобщение, ще намерите стойностите, които да запазите във вашия .env файл, а именно ID на ключа за достъп и Тайния ключ за достъп.

Запишете тези две във вашия .env файл, като AWS_SES_ACCESS_KEY= и AWS_SES_SECRET_KEY= записи.

Най-накрая можете да запазите файла .env и да излезете от конзолата на Amazon.

Сега добавете всички тайни

Всички подробности, необходими за комуникация с услугата AWS SES от zeit сега, са налични, но тъй като сега не изпраща файла .env, трябва да използваме неговия механизъм, за да съхраняваме всяка тайна, която бихме искали да използваме и в производството.

now secrets add aws_ses_to [email protected]
now secrets add aws_ses_region your-aws-region
now secrets add aws_ses_access_key your-aws-iam-access-key
now secrets add aws_ses_secret_key your-aws-iam-secret-key

Всички стойности трябва да са тези, които вече сте записали във файла .env и след като добавите всички тези тайни, трябва да кажете сега как да ги извлечете.

Копирайте следното съдържание JSON във файл now.json в основата на папката на вашия сайт:

{
  "env": {
    "AWS_SES_TO": "@aws_ses_to",
    "AWS_SES_REGION": "@aws_ses_region",
    "AWS_SES_ACCESS_KEY": "@aws_ses_access_key",
    "AWS_SES_SECRET_KEY": "@aws_ses_secret_key"
  }
}

Те ще инструментират now, за да предадат, като променливи на средата, тайната, съхранена за нашия акаунт now.

Моля, имайте предвид, че след като започнете да работите с първия си статичен имейл, по-добра практика е да добавяте префикс към всяка тайна с името на сайта, така че да можете да използвате една и съща конфигурация в повече от един сайт.

Пример:

now secrets add your_site_aws_ses_access_key your-aws-iam-access-key
now secrets add your_site_aws_ses_secret_key your-aws-iam-secret-key

В този случай единственият файл, който трябва да се промени за всеки отделен сайт, ще бъде now.json:

...
"AWS_SES_ACCESS_KEY": "@your_site_aws_ses_access_key",
"AWS_SES_SECRET_KEY": "@your_site_aws_ses_secret_key",
...

Можете обаче да запазите един и същ регион и дестинационен имейл за всички сайтове, но поне трябва да е ясно как евентуално да промените и тези, и то чрез същата процедура.

Актуализирайте The Paperboy 🗞

Файлът api/paperboy.js в момента е безполезен, ако не и за тестване дали функциите без сървър работят и работят, но сега, когато имаме всички подробности, от които се нуждаем, можем да напишем по-добър код, който ще използва всички тайни, за да се случи:

// use the .env if present, do nothing otherwise
require('dotenv').config();
// the utility to handle StaticEmail requests
const {create} = require('static.email.ses');
// secrets revealed via dotenv or now
const {
  AWS_SES_TO: to,
  AWS_SES_REGION: region,
  AWS_SES_ACCESS_KEY: accessKeyId,
  AWS_SES_SECRET_KEY: secretAccessKey
} = process.env;
// the serverless function that now will use
module.exports = create({
  site: 'your.site',  // put your domain here
  sender: 'Your Site',// any sender name
  to,
  region,
  accessKeyId,
  secretAccessKey
});

Запазете горното съдържание в api/paperboy.js и въведете още веднъж:

now --prod

Поздравления 🎈🎉

Най-накрая можете да посетите сайта си и да видите, че формулярът вече трябва да работи според очакванията, изпращайки на тайния имейл адрес, който сте избрали, всичко, което въведете в полето за текст.

Ако случаят е такъв, можете да отпразнувате първия си статичен уебсайт с възможност за изпращане на имейли и да го наречете за ден, защото току-що сте настроили нещо, което други хора продават, харчейки досега само пари за собствения си домейн, което е нещо, което бихте направили така или иначе сте похарчили за, ако сте били сериозни за вашия сайт.

Чувствайте се свободни да промените всяка част от уебсайта, включително формуляра, стига да използвате StaticEmail библиотека в пясъчна среда чрез модули, пакети или затваряне.

… само още едно нещо …

Сега използвайте reCAPTCHA

Докато zeit сега предоставя 5000 заявки на ден към нашите функции без сървър, Amazon SES ни дава, при безплатен план, ограничение от 200 имейла на ден.

Аз лично никога не съм получавал 200 имейла на ден, но тъй като съотношението тук е 25:1, вероятно трябва да направим нещо, за да избегнем на всяка цена нежеланите заявки, както правят тези спам роботи, когато намерят такива само формуляри или тролове, които нямат какво да правят освен да пишат глупости на формулярите ни.

И дори ако аз лично се проваля на някое предизвикателство, което reCAPTCHA предлага, когато аз съм този, който се опитва да изпрати някаква информация, услугата е безценна за филтриране на често срещани нежелани имейли.

Но не се страхувайте, всичко, което сте използвали досега, е готово да се справи с предизвикателствата и услугата reCAPTCHA v2.

Следното е предварителен преглед на това как ще изглежда нашият формуляр след прилагане на функцията „Аз не съм робот“:

РЕГИСТРИРАЙТЕ Вашия сайт

Влезте в reCAPTCHA website и посетете Admin console.

Щракнете върху иконата +, за да Регистрирате нов сайт, в случай че това не е първата страница, която намирате, ако никога преди не сте използвали тази услуга.

Попълнете полетата с вашата информация и се уверете, че сте избрали типа reCAPTCHA v2 и приемете условията за ползване на reCAPTCHA (след като ги прочетете).

Вашият формуляр трябва да изглежда така:

След като се съгласите и продължите напред, трябва да видите страница, която ви предоставя КЛЮЧ ЗА САЙТА и различен ТАЕН КЛЮЧ.

Сега добавете тайната

Подобно на това, което направихме преди, и двамата трябва да запазим втория ТАЕН КЛЮЧ в нашия .env файл:

RECAPTCHA_STATIC_EMAIL=yadaYadayAdayaDayadA

но също така го съхранявайте за zeit сега:

now secrets add recaptcha_static_email yadaYadayAdayaDayadA

Последно, но не на последно място, трябва да актуализираме файла now.json, за да изведем този ключ:

{
  "env": {
    "AWS_SES_TO": "@aws_ses_to",
    "AWS_SES_REGION": "@aws_ses_region",
    "AWS_SES_ACCESS_KEY": "@aws_ses_access_key",
    "AWS_SES_SECRET_KEY": "@aws_ses_secret_key",
    "RECAPTCHA_STATIC_EMAIL": "@recaptcha_static_email"
  }
}

Запазете .env и now.json и просто изчакайте минута, преди да внедрите в прод.

Надстройте The Paperboy 🗞

Не само секретният ключ трябва да е наличен в производството, но и модулът static.email.ses също трябва да го знае.

require('dotenv').config();
const {create} = require('static.email.ses');
const {
  AWS_SES_TO: to,
  AWS_SES_REGION: region,
  AWS_SES_ACCESS_KEY: accessKeyId,
  AWS_SES_SECRET_KEY: secretAccessKey,
  // grab the env variable and ...
  RECAPTCHA_STATIC_EMAIL: recaptcha
} = process.env;
module.exports = create({
  site: 'static.email',
  sender: 'Static Email',
  to,
  region,
  accessKeyId,
  secretAccessKey,
  // ... pass it along the static.email.sas module
  recaptcha
});

Запазете тези промени във файла api/paperboy.js и сте почти готови!

Надстройте оформлението

Трябва както да включим скрипта на Google, така и да намерим място, където да покажем предизвикателното поле за отметка.

Ето как трябва да изглежда вашият public/index.html сега:

Надстройте настройката на JS

Вече имаме всичко освен JS за инструментиране на reCAPTCHA.

Следвайте как трябва да изглежда новият public/js/index.js:

Моля, обърнете внимание на частта siteKey, където тази, която трябва да използвате, е тази в първото поле на страницата reCAPTCHA, която сме виждали преди.

повторно ПОЗДРАВЛЕНИЯ 🎈🎉

След като актуализирате тези няколко файла, както е предложено, вие сте готови да now --prod за последен път и трябва да видите предизвикателството да е зададено и имейлът да бъде изпратен само след като reCAPTCHA потвърди резултата, както вече е за https://static.email/, който показва на живо всичко, което сте направили и научили досега. Да, това е краят на нашето пътуване по отношение на изпращането на имейли от статичен уебсайт, сега сме в състояние да стартираме много проекти на възможно най-ниската цена.

Моля, не се колебайте да напишете отзивите си и благодаря, че ме последвахте до този момент ♥

P.S. е добър момент да се ангажирате още веднъж:

git add .
git commit -m 'success 🎉'