Два правила і мертве посилання між ними

Ми вперше за довгий час як слід обійшли виробничий сайт: пройшли за кожним внутрішнім посиланням, перевірили кожну оголошену мовну альтернативу, звірили кожен блок структурованих даних, перевірили кожне зображення на альтернативний текст.

1776 сторінок, 1750 записів у карті сайту і рівно один дефект. Нуль сиріт, нуль ланцюжків переспрямувань, нуль помилок мовних альтернатив на 17218 оголошеннях, нуль недійсних блоків структурованих даних на 1642, нуль зображень без альтернативного тексту на 15463 і 920 зображень для соціального перегляду, що всі відповідають 200.

Тим одним дефектом було 18 адрес, що повертали 404: сторінки документації двох панелей для рахунків, усіма девʼятьма мовами. Кожна з тих 18 мала рівно одне внутрішнє посилання, що вказувало на неї, зі сторінки інтеграції того самого продукту тією самою мовою.

Обидві половини цього є навмисними. Саме це й робить це вартим запису.

Два правила

Деякі наші інтеграції сидять за перемикачем викочування. Коли перемикач вимкнено, постачальник зникає з каталогу, з карти сайту, з лічильників і з вибору типу в панелі, і все це виводять з однієї таблиці, тож немає другого списку, який можна забути.

Двоє з них не є цілком звичайними. Для FOSSBilling та Paymenter є модуль, який ви ставите в їхню панель, і сторінка на /integrations/fossbilling описує саме той модуль. Вона не є сторінкою про зʼєднання, яке ми пропонуємо; вона є сторінкою про річ, яку можна завантажити вже сьогодні. Тож є правило, що лишає ті дві сторінки інтеграцій стояти, коли постачальника за перемикачем сховано, і воно несе свою причину в джерелі.

Сторінка документації є протилежним випадком. /docs/fossbilling описує зʼєднання, а це є саме тим, що перемикач вимикає, тож вона зникає разом із постачальником.

Обидва правила є правильними. Один слаг, дві поверхні, дві відповіді, і в коді є дві функції, а не одна, що була б хибною в половині випадків.

Чого ніхто не перевірив, є те, що діється між ними. Сторінка, що вціліла, несла тематичне посилання на ту, що зникла.

Правило вже було записане

Функція, що породжує це посилання, розвʼязує шлях документації для слага інтеграції. Її власний коментар казав, ще до того, як усе це сталося, що посилання на посібник, якого не існує, є не тематичним посиланням, а мертвим.

Правило було там. Його міряли проти не того списку: проти набору сторінок документації, що існують у джерелі, а не набору, що відповідає в цій збірці. Ці два майже завжди є тим самим набором, а день, коли вони різняться, є днем, коли щось сховано.

Ремонт є одним рядком. Це не є цікавою частиною; цікавою частиною є те, що правильне правило, розписане в місці, якому воно належить, не є контролем. Проза в коментарі описує намір. Тримати вас за слово може лише те, що виконується.

Третій випадок, якого не знайшов би жоден обхід

Ми написали сторожу, а не просто полагодили рядок: для кожного слага інтеграції розвʼязаний шлях документації мусить бути тим, який ця збірка справді віддає. Її спершу довели червоною, і вона повідомила ті дві сторінки, що їх знайшов обхід.

Вона повідомила також третю: нашу інтеграцію сервера резервних копій, що є за іншим перемикачем. Її сторінку документації сховано, а посилання на неї будували точнісінько так само.

Причиною, з якої жоден обхідник ніколи не знайде тієї третьої, є те, що її сторінку інтеграції сховано теж. Мертве посилання жило на сторінці, що сама повертає 404, тож ззовні немає шляху до того, що є хибним. Воно виринуло б того дня, коли хтось увімкнув би той перемикач і випустив сторінку зі зламаним посиланням на ній, а ті дві події розділяли б тижні.

Обхідник може знайти дефекти лише на досяжних сторінках. Записане, це звучить очевидно, і про це легко забути, коли обхід повертається чистим, бо чистий обхід відчувається твердженням про код, а не про сторінки, які випадково були видимими.

У сторожі є ще один тест, що не робить нічого, крім як тримає перший чесним: він стверджує, що понад десять слагів справді розвʼязуються в сторінку документації. Без нього зміна, що змусила б розвʼязувач нічого не повертати для всього, дала б нуль мертвих посилань і взагалі нуль тематичних посилань, а ці двоє читаються однаково в зеленому запуску тестів.

Друга половина: сказати пошуковій системі, що щось змінилося

Той самий раунд додав канал подання, що є малою річчю з однією несподіванкою всередині.

Протокол є одним POST, що каже кільком пошуковим системам, що адреса змінилася. Володіння хостом доводять, віддаючи ключ як текстовий файл у корені. Наш ключ походить із оточення, а коли його немає, уся справа не робить нічого і каже про це один раз. Це є звичайним станом у розробці і в кожному тесті.

Дві подробиці варті повторення, бо обидві є пастками.

Файл ключа віддають через переписування, бо динамічний маршрут не може сидіти в корені поруч із мовним сегментом. Переписування, що збігалося б із будь-чим крапка txt у корені, ковтнуло б і файл robots. Цьому заважають дві речі: переписування виконують у фазі, що бачить лише запити, яким не відповів жоден справжній файл, а взірець ключа вимагає щонайменше восьми символів, тоді як robots має шість, а llms чотири. Нижня межа не є охайністю; вона є другим замком.

А подання висить на функції, що вже знає про зміну публічного вмісту, а не на розгортанні. Випуск, що зачіпає лише екран панелі, інакше оголошував би 1750 адрес зміненими щоразу, і це є добрим способом стати тим, кого ігнорують. Коли змінюється таблиця цін, два маршрути, що рендерять ціни, подають девʼятьма мовами, і це є 18 адресами.

Те, що виглядало хибним налаштуванням

Перше справжнє подання після розгортання, з виробничим ключем на місці, повернуло 403.

Файл ключа повертав 200 звідусіль, звідки ми пробували, зокрема з користувацьким агентом обхідника. Кожен складник був справним. Природним наступним кроком є піти й подивитися на налаштування краю, або на переписування, або на порядок фаз, і саме туди йде година.

Замість цього ми спробували дві менші речі. Подання однієї адреси повернуло 200 негайно. Те саме групове подання хвилиною пізніше теж повернуло 200, на обох кінцевих точках.

Тож ті 403 були ефектом першого контакту на їхньому боці, а не дефектом на нашому. Файл ключа ще не був завантажений і закешований службою-одержувачем на момент, коли надійшов перший груповий запит.

Ми записали це там, де живе рунбук, бо ця невдача є досконало сконструйованою, щоб відправити когось на полювання: код стану каже заборонено, що є твердженням про дозвіл, а все щодо дозволу було правильним. Перш ніж розслідувати невдачу авторизації на першому запиті, зробіть той самий запит ще раз. Це не коштує нічого і є найдешевшою гіпотезою у списку.

Є суміжна примітка для того, хто той ключ обертатиме: файл віддають із годиною кешування, тож обертання потребує очищення кешу або години терпіння, а протягом того вікна ті самі 403 означають щось геть інше.

Що ми б записали

1. 01Два правильні правила можуть породити дефект у шві між ними. Жоден із власників не є неправим, і жоден не дивиться.
2. 02Той самий ідентифікатор може мати дві поверхні з двома правильними відповідями. Дві функції, а не одна.
3. 03Правило в коментарі не є контролем. Наше було розписане і зміряне проти не того списку.
4. 04Те, що існує, і те, що відповідає, є різними наборами, і розходяться вони саме тоді, коли щось сховано.
5. 05Обхідник знаходить дефекти лише на досяжних сторінках. Наш не міг побачити третього випадку взагалі.
6. 06Сторожа знаходить примірник, який ще не випущено. Саме заради цього її й пишуть, замість полагодити рядок.
7. 07Дайте кожній стороже тест, що доводить, що вона дивиться. Нуль мертвих посилань і нуль посилань узагалі читаються однаково.
8. 08Нижня межа у взірці може бути межею безпеки. Вісім символів є тим, що тримає переписування подалі від файлу robots.
9. 09Оголошуйте зміни вмісту з того, що знає про зміну вмісту, ніколи з розгортання.
10. 10Повторіть, перш ніж діагностувати невдачу першого запиту. Заборона, що хвилиною пізніше стає успіхом, ніколи не була про дозвіл.

Для ясності про те, чим це є: обхід покрив 1776 сторінок проти виробництва і 1750 записів у карті сайту з 913 датами змін, жодна з яких не була в майбутньому, виправлення є одним рядком під охороною трьох тестів, спершу доведених червоними, шлях подання випробувано наскрізно проти підробленої кінцевої точки, зокрема пʼять шляхів невдачі, а прохід по окремій виробничій збірці завершився на 96 зелених. Не доведено: на час написання виправлення воно було зеленим на локальній виробничій збірці і ще не було підтверджене на виробництві, а дві родини маршрутів в обході не дали жодної сторінки, бо їхні реєстри є порожніми.

Із платформної роботи над Provibr. Що міграція рахунків може і чого не може перевезти, описано в Пʼятнадцять речей, що не їдуть, розгортання, чий крок зі схемою ніколи не виконався, описано в Міграція, яка ніколи не виконалася, а ще одна перевірка, що була зеленою, бо ніколи не дісталася, описана в Зелений, бо не міг туди дістатися.