LIMB
Всех приветствую, название как обычно с подвывертом, но тут всё буквально. WordPress, самый популярный движок на планете, 43% интернета, и когда речь заходит про "проверку" или "получение доступа", все как один бегут на wp-login.php. Брутят, подбирают, гоняют базы через WPScan, Hydra, что-нибудь самописное. И натыкаются на одно и то же, капча, rate-limit, Wordfence, двухфакторка, блокировка по IP после пяти попыток. Классика, замкнутый круг. А я сегодня расскажу, как зайти в WordPress вообще не прикасаясь к wp-login.php. Через парадную дверь, но чужую.
Попался мне на глаза один хостинг-провайдер, Flywheel. Если кто не в курсе, Flywheel (getflywheel.com), это managed WordPress hosting. То есть не просто сервер, куда ты заливаешь свой WP, а целая платформа, которая берёт на себя всё: установку, обновления, бэкапы, SSL, CDN, и самое вкусное, управление доступом. У них есть панель управления app.getflywheel.com, через которую ты можешь одним кликом залететь в wp-admin любого своего сайта. Без пароля от WP. Без логина от WP. Просто нажал кнопку, и ты внутри.
И вот что важно понимать. Flywheel это не просто "ещё один хостинг для одного сайтика". Их основная аудитория, это фрилансеры, веб-студии, и digital-агентства, которые ведут по 10-20-50 клиентских проектов одновременно. Вот представьте, дизайнер Ваня из Остина делает вордпрессы на заказ. У него 30 клиентов, у каждого свой сайт, у каждого свой wp-admin с отдельным логином. Помнить 30 паролей? Нереально. По этому Ваня заводит один аккаунт на Flywheel и складывает туда все 30 сайтов. Одна панель, один логин, все клиенты под одной крышей. Безопасно ли это? Ну, об этом сейчас поговорим. И кстати, прежде чем нырять в технику, хочу подсветить один момент, который мало кто осознаёт. Все, буквально все, кто работает с вордпрессами, долбятся в одну и ту же точку, wp-login.php. Тысячи людей, тысячи скриптов, тысячи брутфорсеров, все стучатся в одну дверь. И именно по этому эта дверь закрыта наглухо, Wordfence, капчи, бан по IP, кастомные урлы для входа, двухфакторка. Разрабы WP-плагинов безопасности уже давным давно на рефлексе затыкают wp-login.php, потому что туда лезут все подряд. А вот про хостинг-панели не думает практически никто. Это как с квартирой, все ставят бронированную входную дверь, а балкон на первом этаже оставляют открытым. Потому что "ну кто полезет через балкон". А мы полезем. И самое смешное, что конкуренция тут минимальная. Пока все толпой ломятся в wp-login и получают по рукам, мы спокойно заходим через боковую дверь, где нас никто не ждёт. Ни антиботы, ни плагины безопасности, ни fail2ban. Просто форма логина и Cloudflare, который, как мы сейчас покажем, не такая уж и крепость.
Первое, с чем мы столкнёмся при попытке зайти на app.getflywheel.com, это Cloudflare. Причём не какой-то там Page Rule или простенький JS Challenge, а полноценный Managed Challenge, он же "Just a moment..." с крутящейся вертушкой. Кто сталкивался, тот знает, обычный requests.get() тут идёт лесом. Cloudflare смотрит на TLS-fingerprint вашего клиента, на порядок расширений в ClientHello, на HTTP/2 фреймы, на canvas fingerprint если дело дойдёт до браузерного JS, и если что-то пахнет ботом, выдаёт 403 и крутящуюся вертушку до посинения.
И вот тут ключевой момент, и он проще чем вы думаете. Никаких Capsolver'ов, никаких платных сервисов для решения челленджей, никакой лишней головной боли. Всё что вам нужно, это две вещи: tls_client и хорошие резидентские прокси. Всё. Серьёзно, всё. Давайте разберу почему. tls_client, это Python-обёртка над Go-шной библиотекой, которая умеет имитировать TLS-fingerprint реальных браузеров. То есть когда Cloudflare смотрит на ваше TLS-рукопожатие, он видит не "Python/urllib3" (что палится за миллисекунду), а полноценный Chrome 124 со всеми его расширениями, cipher suite'ами и ALPN в правильном порядке. Разница принципиальная.
Параметр random_tls_extension_order, это чтоб при каждом запросе порядок TLS-расширений чутка менялся, иначе CF может зацепиться за то, что сотня запросов с разных IP имеет абсолютно идентичный fingerprint. Мелочь, но именно на таких мелочах горят.
А теперь про прокси, и это самое важное во всей статье. Cloudflare ведёт себя КАРДИНАЛЬНО по-разному в зависимости от типа вашего IP. И это не теория, это я проверял лично, на сотнях запросов. Вот как это работает:
Датацентровый прокси за $0.5/гб, это гарантированный Challenge. CF сразу видит что IP принадлежит хостингу (AWS, DigitalOcean, OVH, не важно), и автоматически кидает "Just a moment..." с интерактивным челленджем. Без JS-движка вы его не пройдёте. Раньше для этого нужен был Capsolver или подобный сервис. Но зачем, если можно просто не получать этот челлендж? Резидентский или мобильный прокси от нормального провайдера, и Cloudflare видит обычного домашнего юзера. Домашний IP из пула ISP, нормальный TLS-fingerprint от tls_client, правильные заголовки, и CF просто ставит куку и пропускает. Без челленджа, без вертушки, без "Just a moment...". Просто пускает. Как обычного человека, который зашёл проверить свой хостинг. По моим тестам, с хорошими резидентскими проксями Cloudflare пропускает 9 из 10 запросов вообще без челленджа. Девять из десяти. Один запрос может словить challenge, ну значит берём другой прокси из пула и пробуем снова. При пуле в несколько тысяч IP это занимает секунды. И никаких $1.2 за каждые 1000 решений, никаких API-ключей, никаких зависимостей от сторонних сервисов которые могут лечь или поднять цены. Я раньше сам использовал Capsolver как запасной вариант, думал "ну мало ли, пригодится". Потом посчитал, сколько раз он реально срабатывал при хороших проксях. Ноль. Ну, почти ноль. И снёс его нафиг. Зачем тащить лишнюю зависимость, лишний import, лишний API-ключ в конфиге, если тот же результат даёт обычная ротация прокси? Правильно, незачем. Код стал проще, конфиг стал проще, точек отказа стало меньше. Чистая победа.
Окей, Cloudflare мы прошли, и прошли без единого стороннего сервиса, только tls_client + резидентские прокси. Теперь самое простое, логин. Заходим на app.getflywheel.com/login и смотрим что там. Обычная форма с двумя полями: username и password. Никакой капчи. Никакой двухфакторки по дефолту. Есть CSRF-токен (authenticity_token), который отдаётся прямо в HTML-коде страницы, и fw_token для внутренних нужд. Регуляркой достаём оба, формируем POST-запрос и шлём.
Обратите внимание на allow_redirects=False. Мы специально не идём по редиректу, а проверяем статус-код. 302 означает что сервер принял креды и редиректит нас в панель. Всё что не 302, невалид. Простая, надёжная проверка без парсинга HTML-ошибок. Хотя парсинг тоже не помешает, вдруг хотим знать ПОЧЕМУ не пустило, может аккаунт заблокирован, может двухфакторка включена, может пароль просрочен. Для этого ловим класс flash-error в ответе и читаем текст. Теперь самое вкусное. Мы залогинились в панель Flywheel. Что дальше? А дальше один GET-запрос на API, и у нас список ВСЕХ сайтов на аккаунте. Помните, что я говорил про фрилансеров? Вот именно тут это выстреливает. Фрилансер Ваня ведёт 30 клиентов, и все 30 сайтов висят на его аккаунте. Один логин, и вы получаете доступ ко всем тридцати. Не к одному, как при брутфорсе wp-login. К тридцати. За один заход.
API отдаёт JSON со списком сайтов, их доменами, статусами, и ссылками на страницы управления. И вот тут ключевой момент, на каждой странице сайта есть кнопка "WP Admin". Это SSO-ссылка, которая автоматически логинит вас в WordPress без пароля. Flywheel генерирует одноразовый nonce + payload, вы отправляете их POST-запросом на эндпоинт WordPress'а, и вас редиректит прямо в wp-admin с полными правами администратора.
А теперь давайте поговорим о самом жирном бонусе, ради которого всё это стоило затевать. Flywheel даёт SSH/SFTP-доступ к каждому сайту. Прямо из панели управления. Без дополнительных паролей, без ключей (ну, почти), без танцев с бубном. Вы уже внутри панели, значит вы уже имеете доступ к серверу. И это не какой-то ограниченный доступ "только к файлам темы". Это полноценный доступ к файловой системе сайта. wp-config.php с кредами от базы? Забирайте. Дамп базы через wp-cli? Пожалуйста. Прописать свой SSH-ключ для доступа, как я показывал в статье про закрепы? Легко.
Если кто-то спросит, а нафига вообще заморачиваться с Flywheel, если можно просто брутить wp-login? Объясняю по пунктам, кратенько, чтоб закрепить. Первое, у wp-login.php на каждом втором нормальном сайте стоит Wordfence, Limit Login Attempts, или кастомный URL для админки (/wp-secretichernogonegra-2026/ и прочее). У Flywheel ничего этого нет, одна форма, один POST. Второе, через wp-login вы получаете доступ к одному сайту. Через Flywheel вы получаете доступ ко ВСЕМ сайтам на аккаунте. Веб-студии, фрилансеры, агентства, они специально складывают все клиентские проекты в одно место, потому что так удобнее управлять. А для нас это значит, что один аккаунт = 10, 20, 50 сайтов разом. Третье, через wp-login вы получаете только WP-админку. Через Flywheel вы получаете WP-админку + SSH + SFTP + бэкапы + DNS-управление + биллинг. Это как разница между тем, чтобы подобрать ключ от одной комнаты, и тем, чтобы получить мастер-ключ от всего здания. Четвёртое, Flywheel-аккаунты часто используют те же креды, что и другие сервисы (утечки, password reuse). А двухфакторку на хостинг-панели включают единицы, потому что "ну это же не банк, зачем". И пятое, самое важное, конкуренция. Про wp-login.php знает каждый школьник с кали линуксом. Про хостинг-панели как вектор входа не думает практически никто. Вся индустрия WP-безопасности заточена на защиту самого WordPress, плагины, файрволы, WAF'ы. А хостинг-панель? Она остаётся незащищённой, потому что "это же отдельный сервис, он к WP не относится". Относится, и ещё как. Просто об этом никто не задумывается. И именно по этому этот вектор работает так хорошо. Вас там просто не ждут.
Давайте подведём итог. Вместо того чтобы стучаться в закрытую дверь wp-login.php и получать по рукам от Wordfence и капч, мы зашли с другой стороны. Через хостинг-провайдера, который сам открыл нам все двери. Cloudflare обошли комбинацией tls_client (правильный TLS-fingerprint) и хороших резидентских прокси. Без Capsolver'а, без платных солверов, без лишних зависимостей. Просто качественный IP из пула ISP, и Cloudflare пропускает вас как обычного юзера. Это ключевой момент, который многие не догоняют, не надо решать челлендж, надо просто его не получать. А не получать его элементарно, достаточно выглядеть как нормальный человек, а не как бот с датацентрового IP. Логин в Flywheel, простая форма без капчи и rate-limit'а. Дальше SSO закинуло нас в WP-Admin без единого прикосновения к wp-login.php. А в качестве бонуса получили SSH-доступ к серверу, готовый закреп на блюдечке. Один аккаунт хостинга = все сайты + все админки + все серверы. И самое смешное, Flywheel это не какой-то ноунейм-хостинг из подвала. Это дочка WP Engine, одного из крупнейших WordPress-хостеров в мире. У них тысячи клиентов, от мелких блогеров до серьёзных e-commerce проектов. И вся эта конструкция держится на одном пароле от панели управления. И таких хостингов, кстати, не один Flywheel. Есть WP Engine, Kinsta, Cloudways, Pagely, все они работают по тому же принципу, одна панель, SSO в WP, SSH из коробки. Flywheel просто оказался первым, который я разобрал, но принцип универсальный. Не усложняйте себе жизнь, не всегда надо ломиться в главный вход. Иногда стоит просто обойти здание и проверить, не открыта ли служебная дверь. Она обычно открыта. Всем пока, не болейте!
Не удалось прогрузить медиа
Попался мне на глаза один хостинг-провайдер, Flywheel. Если кто не в курсе, Flywheel (getflywheel.com), это managed WordPress hosting. То есть не просто сервер, куда ты заливаешь свой WP, а целая платформа, которая берёт на себя всё: установку, обновления, бэкапы, SSL, CDN, и самое вкусное, управление доступом. У них есть панель управления app.getflywheel.com, через которую ты можешь одним кликом залететь в wp-admin любого своего сайта. Без пароля от WP. Без логина от WP. Просто нажал кнопку, и ты внутри.
Не удалось прогрузить медиа
И вот что важно понимать. Flywheel это не просто "ещё один хостинг для одного сайтика". Их основная аудитория, это фрилансеры, веб-студии, и digital-агентства, которые ведут по 10-20-50 клиентских проектов одновременно. Вот представьте, дизайнер Ваня из Остина делает вордпрессы на заказ. У него 30 клиентов, у каждого свой сайт, у каждого свой wp-admin с отдельным логином. Помнить 30 паролей? Нереально. По этому Ваня заводит один аккаунт на Flywheel и складывает туда все 30 сайтов. Одна панель, один логин, все клиенты под одной крышей. Безопасно ли это? Ну, об этом сейчас поговорим. И кстати, прежде чем нырять в технику, хочу подсветить один момент, который мало кто осознаёт. Все, буквально все, кто работает с вордпрессами, долбятся в одну и ту же точку, wp-login.php. Тысячи людей, тысячи скриптов, тысячи брутфорсеров, все стучатся в одну дверь. И именно по этому эта дверь закрыта наглухо, Wordfence, капчи, бан по IP, кастомные урлы для входа, двухфакторка. Разрабы WP-плагинов безопасности уже давным давно на рефлексе затыкают wp-login.php, потому что туда лезут все подряд. А вот про хостинг-панели не думает практически никто. Это как с квартирой, все ставят бронированную входную дверь, а балкон на первом этаже оставляют открытым. Потому что "ну кто полезет через балкон". А мы полезем. И самое смешное, что конкуренция тут минимальная. Пока все толпой ломятся в wp-login и получают по рукам, мы спокойно заходим через боковую дверь, где нас никто не ждёт. Ни антиботы, ни плагины безопасности, ни fail2ban. Просто форма логина и Cloudflare, который, как мы сейчас покажем, не такая уж и крепость.
Не удалось прогрузить медиа
Первое, с чем мы столкнёмся при попытке зайти на app.getflywheel.com, это Cloudflare. Причём не какой-то там Page Rule или простенький JS Challenge, а полноценный Managed Challenge, он же "Just a moment..." с крутящейся вертушкой. Кто сталкивался, тот знает, обычный requests.get() тут идёт лесом. Cloudflare смотрит на TLS-fingerprint вашего клиента, на порядок расширений в ClientHello, на HTTP/2 фреймы, на canvas fingerprint если дело дойдёт до браузерного JS, и если что-то пахнет ботом, выдаёт 403 и крутящуюся вертушку до посинения.
Не удалось прогрузить медиа
И вот тут ключевой момент, и он проще чем вы думаете. Никаких Capsolver'ов, никаких платных сервисов для решения челленджей, никакой лишней головной боли. Всё что вам нужно, это две вещи: tls_client и хорошие резидентские прокси. Всё. Серьёзно, всё. Давайте разберу почему. tls_client, это Python-обёртка над Go-шной библиотекой, которая умеет имитировать TLS-fingerprint реальных браузеров. То есть когда Cloudflare смотрит на ваше TLS-рукопожатие, он видит не "Python/urllib3" (что палится за миллисекунду), а полноценный Chrome 124 со всеми его расширениями, cipher suite'ами и ALPN в правильном порядке. Разница принципиальная.
Code:
import tls_client
session = tls_client.Session(
client_identifier='chrome_124',
random_tls_extension_order=True,
)
session.proxies = {
'http': 'http://user:pass@proxy:port',
'https': 'http://user:pass@proxy:port',
}Параметр random_tls_extension_order, это чтоб при каждом запросе порядок TLS-расширений чутка менялся, иначе CF может зацепиться за то, что сотня запросов с разных IP имеет абсолютно идентичный fingerprint. Мелочь, но именно на таких мелочах горят.
Не удалось прогрузить медиа
А теперь про прокси, и это самое важное во всей статье. Cloudflare ведёт себя КАРДИНАЛЬНО по-разному в зависимости от типа вашего IP. И это не теория, это я проверял лично, на сотнях запросов. Вот как это работает:
Датацентровый прокси за $0.5/гб, это гарантированный Challenge. CF сразу видит что IP принадлежит хостингу (AWS, DigitalOcean, OVH, не важно), и автоматически кидает "Just a moment..." с интерактивным челленджем. Без JS-движка вы его не пройдёте. Раньше для этого нужен был Capsolver или подобный сервис. Но зачем, если можно просто не получать этот челлендж? Резидентский или мобильный прокси от нормального провайдера, и Cloudflare видит обычного домашнего юзера. Домашний IP из пула ISP, нормальный TLS-fingerprint от tls_client, правильные заголовки, и CF просто ставит куку и пропускает. Без челленджа, без вертушки, без "Just a moment...". Просто пускает. Как обычного человека, который зашёл проверить свой хостинг. По моим тестам, с хорошими резидентскими проксями Cloudflare пропускает 9 из 10 запросов вообще без челленджа. Девять из десяти. Один запрос может словить challenge, ну значит берём другой прокси из пула и пробуем снова. При пуле в несколько тысяч IP это занимает секунды. И никаких $1.2 за каждые 1000 решений, никаких API-ключей, никаких зависимостей от сторонних сервисов которые могут лечь или поднять цены. Я раньше сам использовал Capsolver как запасной вариант, думал "ну мало ли, пригодится". Потом посчитал, сколько раз он реально срабатывал при хороших проксях. Ноль. Ну, почти ноль. И снёс его нафиг. Зачем тащить лишнюю зависимость, лишний import, лишний API-ключ в конфиге, если тот же результат даёт обычная ротация прокси? Правильно, незачем. Код стал проще, конфиг стал проще, точек отказа стало меньше. Чистая победа.
Не удалось прогрузить медиа
Окей, Cloudflare мы прошли, и прошли без единого стороннего сервиса, только tls_client + резидентские прокси. Теперь самое простое, логин. Заходим на app.getflywheel.com/login и смотрим что там. Обычная форма с двумя полями: username и password. Никакой капчи. Никакой двухфакторки по дефолту. Есть CSRF-токен (authenticity_token), который отдаётся прямо в HTML-коде страницы, и fw_token для внутренних нужд. Регуляркой достаём оба, формируем POST-запрос и шлём.
Не удалось прогрузить медиа
Code:
import re
resp = session.get('https://app.getflywheel.com/login', headers=HEADERS, timeout_seconds=30)
pattern = r'"(authenticity_token|fw_token)"\s*:\s*"([\w-]+)"'
matches = re.findall(pattern, resp.text)
tokens = dict(matches)
data = {
'authenticity_token': tokens.get('authenticity_token'),
'fw_token': tokens.get('fw_token', ''),
'login_form[username]': '[email protected]',
'login_form[password]': 'bibibibi',
}
resp_login = session.post(
'https://app.getflywheel.com/login',
headers=HEADERS,
data=data,
allow_redirects=False,
timeout_seconds=20,
)
if resp_login.status_code == 302:
print("валид")Обратите внимание на allow_redirects=False. Мы специально не идём по редиректу, а проверяем статус-код. 302 означает что сервер принял креды и редиректит нас в панель. Всё что не 302, невалид. Простая, надёжная проверка без парсинга HTML-ошибок. Хотя парсинг тоже не помешает, вдруг хотим знать ПОЧЕМУ не пустило, может аккаунт заблокирован, может двухфакторка включена, может пароль просрочен. Для этого ловим класс flash-error в ответе и читаем текст. Теперь самое вкусное. Мы залогинились в панель Flywheel. Что дальше? А дальше один GET-запрос на API, и у нас список ВСЕХ сайтов на аккаунте. Помните, что я говорил про фрилансеров? Вот именно тут это выстреливает. Фрилансер Ваня ведёт 30 клиентов, и все 30 сайтов висят на его аккаунте. Один логин, и вы получаете доступ ко всем тридцати. Не к одному, как при брутфорсе wp-login. К тридцати. За один заход.
Code:
resp = session.get(
'https://app.getflywheel.com/site_filter?p=1&per=50',
headers={'accept': 'application/json', 'referer': 'https://app.getflywheel.com/login'},
timeout_seconds=20,
)
sites = resp.json().get('sites', [])
print(f"всего сайтов: {len(sites)}")API отдаёт JSON со списком сайтов, их доменами, статусами, и ссылками на страницы управления. И вот тут ключевой момент, на каждой странице сайта есть кнопка "WP Admin". Это SSO-ссылка, которая автоматически логинит вас в WordPress без пароля. Flywheel генерирует одноразовый nonce + payload, вы отправляете их POST-запросом на эндпоинт WordPress'а, и вас редиректит прямо в wp-admin с полными правами администратора.
Не удалось прогрузить медиа
А теперь давайте поговорим о самом жирном бонусе, ради которого всё это стоило затевать. Flywheel даёт SSH/SFTP-доступ к каждому сайту. Прямо из панели управления. Без дополнительных паролей, без ключей (ну, почти), без танцев с бубном. Вы уже внутри панели, значит вы уже имеете доступ к серверу. И это не какой-то ограниченный доступ "только к файлам темы". Это полноценный доступ к файловой системе сайта. wp-config.php с кредами от базы? Забирайте. Дамп базы через wp-cli? Пожалуйста. Прописать свой SSH-ключ для доступа, как я показывал в статье про закрепы? Легко.
Не удалось прогрузить медиа
Причём даже если потом аккаунт Flywheel почистят и поменяют пароль, ваш SSH-ключ уже прописан на сервере. Вы уже там. Навсегда. И ещё раз подчеркну, это не один сайт. У фрилансера на аккаунте может быть 30 сайтов, и SSH-доступ есть к каждому из них. Тридцать серверов, тридцать закрепов, один пароль на входе. Кстати, сайт, который вы видите на скрине это юсовская корпа на 8кк ревеню, интересный факт, хотя достал я его просто и банальных ЮЛПНе удалось прогрузить медиа
Если кто-то спросит, а нафига вообще заморачиваться с Flywheel, если можно просто брутить wp-login? Объясняю по пунктам, кратенько, чтоб закрепить. Первое, у wp-login.php на каждом втором нормальном сайте стоит Wordfence, Limit Login Attempts, или кастомный URL для админки (/wp-secretichernogonegra-2026/ и прочее). У Flywheel ничего этого нет, одна форма, один POST. Второе, через wp-login вы получаете доступ к одному сайту. Через Flywheel вы получаете доступ ко ВСЕМ сайтам на аккаунте. Веб-студии, фрилансеры, агентства, они специально складывают все клиентские проекты в одно место, потому что так удобнее управлять. А для нас это значит, что один аккаунт = 10, 20, 50 сайтов разом. Третье, через wp-login вы получаете только WP-админку. Через Flywheel вы получаете WP-админку + SSH + SFTP + бэкапы + DNS-управление + биллинг. Это как разница между тем, чтобы подобрать ключ от одной комнаты, и тем, чтобы получить мастер-ключ от всего здания. Четвёртое, Flywheel-аккаунты часто используют те же креды, что и другие сервисы (утечки, password reuse). А двухфакторку на хостинг-панели включают единицы, потому что "ну это же не банк, зачем". И пятое, самое важное, конкуренция. Про wp-login.php знает каждый школьник с кали линуксом. Про хостинг-панели как вектор входа не думает практически никто. Вся индустрия WP-безопасности заточена на защиту самого WordPress, плагины, файрволы, WAF'ы. А хостинг-панель? Она остаётся незащищённой, потому что "это же отдельный сервис, он к WP не относится". Относится, и ещё как. Просто об этом никто не задумывается. И именно по этому этот вектор работает так хорошо. Вас там просто не ждут.
Не удалось прогрузить медиа
Давайте подведём итог. Вместо того чтобы стучаться в закрытую дверь wp-login.php и получать по рукам от Wordfence и капч, мы зашли с другой стороны. Через хостинг-провайдера, который сам открыл нам все двери. Cloudflare обошли комбинацией tls_client (правильный TLS-fingerprint) и хороших резидентских прокси. Без Capsolver'а, без платных солверов, без лишних зависимостей. Просто качественный IP из пула ISP, и Cloudflare пропускает вас как обычного юзера. Это ключевой момент, который многие не догоняют, не надо решать челлендж, надо просто его не получать. А не получать его элементарно, достаточно выглядеть как нормальный человек, а не как бот с датацентрового IP. Логин в Flywheel, простая форма без капчи и rate-limit'а. Дальше SSO закинуло нас в WP-Admin без единого прикосновения к wp-login.php. А в качестве бонуса получили SSH-доступ к серверу, готовый закреп на блюдечке. Один аккаунт хостинга = все сайты + все админки + все серверы. И самое смешное, Flywheel это не какой-то ноунейм-хостинг из подвала. Это дочка WP Engine, одного из крупнейших WordPress-хостеров в мире. У них тысячи клиентов, от мелких блогеров до серьёзных e-commerce проектов. И вся эта конструкция держится на одном пароле от панели управления. И таких хостингов, кстати, не один Flywheel. Есть WP Engine, Kinsta, Cloudways, Pagely, все они работают по тому же принципу, одна панель, SSO в WP, SSH из коробки. Flywheel просто оказался первым, который я разобрал, но принцип универсальный. Не усложняйте себе жизнь, не всегда надо ломиться в главный вход. Иногда стоит просто обойти здание и проверить, не открыта ли служебная дверь. Она обычно открыта. Всем пока, не болейте!
👍16
🤔1
😢3
💯4