Админ лог и сертификат на сайт, не мога да реша проблем със сертификат

Стресираш ме ... Имах си просто обяснение за ситуацията което ме устройваше. DNS записи вече са минали authoritative DNS за главния домейн. Това е вече свършено. Мислех че трябва локално в сървъра само да върне моето IP името залепено за главния домеин да ми 'признае', и това става за минута???

Това мнение е било редактирано от avsrm на 13-04-2026, 10:28

DNS е мрежа от сървъри. Когато добавиш/редактираш нещо в един той казва на тези около него за промяната. Те казват на твзи около тях, те на тези около тях... това е процес на "спам" за обновяване на зони (това е тая "минута" за която говориш главните и подчинените съевъри се спамят взаимно). Отделно, самите сървъри кешират записи (рутерът ти, доставчикът ти, неговия доатавчик...). Така ти може да смениш адреса на сайтът но сървърите които са кеширали стария няма да си направят трудът да проверят за промяна в зоната или докато кеша не изтече или докато не получат нотификация за обновяване. Отделно, има кеширане и на ниво ОС.

Това са неща които не зависят от теб (е, можеш да посочиш време за което да ти се кешеират записите - например, ако си играеш с настройки на зоната сваляш времето на минимум, но пък това вдига натоварването на dns сървърите). Затова промените в DNS записите се виждат бавно в глобален мащаб и се правят горните изпълнения за да не се чудят клиентите какво става). Пак казвам, това не е фатално. Дори да не си предприел нищо, просто го знай като информация и ако получиш оплакване от клиент за странно поведение или необработена заявка (ако не си махнал статия хост) да си на ясно как да реагираш.

Това мнение е било редактирано от thrawn на 13-04-2026, 10:36

Проблемът е решен.
Използвах PHP достъп през free hosting, но се оказа, че директният достъп към API от самия сайт е ограничен. Затова изградих междинна архитектура със Supabase Free проект, който използвам за управление на лицензи, заявки и част от критичната логика.
Важният код и част от конфигурационните данни не се държат локално в приложението, а се заявяват от сървъра. При нужда сървърът връща криптирани данни към приложението, които се декриптират и използват само временно — в краткоживеещи променливи в RAM. Така се намалява рискът чувствителна логика да остане трайно записана на клиента.
Понеже Supabase Free не предоставя стандартен web hosting за административен панел, направих bridge между Supabase backend-а и админ панел, разположен на free hosting. Реално управлението на приложението, лицензите и заявките минава през Supabase, а визуалният административен интерфейс е изнесен към отделния хостинг.
Решението стана по-сложно от първоначално планираното, но вече работи. Следващата стъпка е да пусна около 100 free лиценза, за да тествам как ще се държи системата при повече заявки, като имам предвид ограниченията на free проекта.