Akamai Bot Manager Çerezleri: _abck, ak_bmsc, bm_sz, bm_sv

Akamai Bot Manager çerezleri, Akamai'nin istemciniz hakkında daha önce verdiği kararları takip etme yöntemidir. İlk gelen bm_sz olur; genellikle ilk HTML yanıtıyla gelir ve yaklaşık dört saat yaşar. ak_bmsc ve bm_sv yaklaşık iki saatlik kısa oturum çerezleridir. Kalıcı olan _abck'tir ve genellikle bir yıllığına ayarlanır: tarayıcınızın istemci tarafı kontrollerinin kabul edilip edilmediğini kaydeder. Değerleri şifrelidir ve belgelenmemiştir. Bunlardan okuyabileceğiniz şey, hangi çerezlere sahip olduğunuz, ne zaman değiştikleri ve tek bir IP'deki tek bir istemcide kalıp kalmadıklarıdır.

Akamai Bot Manager çerezlerine hızlı bakış

Akamai bu çerezler için alan alan bir spesifikasyon yayımlamıyor. Kamuya açık en güvenilir bilgi, çerez beyanlarıdır: Akamai'nin kendi ürün belgeleri ve çerez sayfaları ile Bot Manager kullanan sitelerin çerez politikaları. Aşağıdaki tablo bunları bir araya getiriyor. Kaynakların çeliştiği yerlerde tablo bunu belirtiyor.

Kaynaklar: RIPE NCC çerez listesi beşini de kesinlikle gerekli olarak sınıflandırıyor ve _abck için 1 yıl, bm_sz için 4 saat, ak_bmsc, bm_sv ve bm_mi için 2 saat veriyor. cookie.is, _abck, bm_sz, ak_bmsc ve bm_sv için aynı ömürleri listeliyor. Akamai'nin Identity Cloud çerez tablosu, bm_sv açıklamasını ve ak_bmsc ile bm_sv için HttpOnly/Secure/SameSite bayraklarını veriyor. Akamai'nin kendi çerez tercihleri sayfası _abck, ak_bmsc ve bm_sv çerezlerini kesinlikle gerekli, bm_sz çerezini ise performans kategorisine koyuyor.

İki pratik uyarı. Birincisi, bu özelliklerin her biri kurulum bazında ayarlanır; yukarıdaki ömürler garanti değil, tipik değerlerdir. Çalıştığınız sitedeki gerçek Set-Cookie başlıklarını okuyun. İkincisi, daha yeni kurulumlar DevTools'ta adlarını görebileceğiniz ek çerezler ayarlıyor. Bunlar için güvenilir bir kamuya açık açıklama bulamadık, bu yüzden burada yer vermedik.

_abck: kararı taşıyan çerez

_abck, tarayıcınızın Akamai'nin istemci tarafı kontrollerini geçip geçmediğini yansıtan kalıcı çerezdir. Önce doğrulanmamış durumda verilir, ardından Bot Manager script'i her rapor gönderdiğinde sunucu tarafından yeniden yazılır. Genellikle bir yıllık son kullanma süresi vardır, ama içindeki "doğrulanmış" durum çerezin kendisinden çok daha kısa sürer.

Değeri, tilde ile ayrılmış bölümlerden oluşan uzun, şifreli bir dizedir. Üzerine konuşulan tek kısımlar ~-1~ ve ~0~ gibi kısa işaretlerdir. Aşağıdakileri topluluk gözlemi olarak değerlendirin. Akamai bu işaretleri hiçbir zaman belgelemedi ve ayrıntılı yazılardan biri, Scrapfly'ınki, değerden sabit alanlar çıkarmaya çalışmamayı açıkça öneriyor. Bağımsız kaynakların üzerinde uzlaştığı yorum kabaca şöyle:

• Baştaki konumda ~-1~: istemci henüz istemci tarafı kontrolü karşılamamış. Yeni bir _abck bu durumda gelir ve kabul edilebilir telemetri hiç gelmezse bu durumda kalır.
• Aynı konumda ~0~: kontrol şimdilik karşılanmış. Yaygın açıklama, sayfa script'ine telemetri göndermeyi bırakabileceğini söyleyen istemci tarafı bir "durdurma sinyali" olduğu yönünde.
• Doğrulanmış bir çerez sıfırlanabilir. Korunan endpoint'ler, örneğin bir giriş veya ödeme adımından önce, sizi yeniden doğrulanmamış duruma döndüren yeni bir _abck verebilir.

Crawlex'in yazısı da aynı yorumu yapıyor ve bunun "tamamen çerezin değişimini izleyen insanlardan" geldiğini vurguluyor. Buradaki önemli sonuç, ~0~'ın ne anlama gelmediği. Bu bir geçiş kartı değildir. Akamai her isteği IP itibarı, protokol fingerprint'leri ve istek kalıpları açısından yine puanlar; farklı bir istemciden veya ağdan sunulan ~0~ çerezi başarısız olabilir. Akamai'nin kendi Bot Manager hızlı başlangıç kılavuzu, Cookie Integrity Failed adlı bir tespiti listeliyor; bu tespit "hiçbir bot operatörünün bir Bot Manager çerezini kurcalamadığından veya kopyalamaya çalışmadığından emin olur". Yani kopyalanmış bir _abck, sistemin tam olarak yakalamak için kurulduğu şeydir.

Sayfa script'i bu işareti okuduğu için _abck genellikle HttpOnly değildir; çoğu zaman document.cookie içinde görebilirsiniz. Akamai'nin bu konuda bir açıklamasını bulamadık; test ettiğiniz sitede doğrulayın.

bm_sz: oturum tohumu

bm_sz genellikle korunan bir host'tan gelen ilk HTML yanıtında, henüz hiçbir Bot Manager JavaScript'i çalışmadan ayarlanır ve yaklaşık dört saat sürer. Crawlex'in bm_sz analizi gibi teknik yazılar bunu, istemci tarafı script'in üzerinde çalıştığı oturum başına girdi olarak tanımlıyor. Başka bir oturumdan veya origin'den gelen bir bm_sz'nin sonraki her şeyi bozmasının nedeni budur. Bir istemci hiç bm_sz almıyorsa, korunan sayfa muhtemelen Bot Manager'dan hiç geçmemiştir; hata ayıklarken bunu bilmek işe yarar.

ak_bmsc: kısa ömürlü oturum çerezi

ak_bmsc yaklaşık iki saatlik bir oturum çerezidir. Beyanlar onu insanları botlardan ayıran bir çerez olarak tanımlıyor; Akamai'nin Identity Cloud belgeleri ise ayrıca "performansı optimize etmek için kullanıldığını" söylüyor. HttpOnly bayrağı konusunda yazılar çelişiyor. Akamai'nin kendi Identity Cloud tablosu HttpOnly: false derken birkaç scraping blogu HttpOnly olduğunu söylüyor; bu da ayarın kurulumlar arasında farklılaştığını düşündürüyor. Oturum ortasında kaybolursa genellikle nedeni iki saatin dolmuş olması ya da istemcinizin çerezleri düşürmesidir.

bm_sv ve bm_mi

bm_sv, Akamai'nin doğrudan tanımladığı tek çerezdir ("Akamai Bot Manager tarafından, insanların ürettiği web isteklerini botların veya diğer otomatik süreçlerin ürettiği web isteklerinden ayırt etmeye yardımcı olmak için kullanılır"). Yaklaşık iki saat sürer. Akamai'nin hızlı başlangıç kılavuzu ayrıca "bir istemciden gelen HTML sayfası ve AJAX isteklerinin sayısını sayan" bir Session Validation tespitini listeliyor. Adlandırma bm_sv ile bir bağlantı olduğunu düşündürüyor, ama bunu doğrulayan kamuya açık bir bilgi yok; buna güvenmeyin. bm_mi bazı kurulumların beyanlarında iki saatlik ömürle ve başka bir ayrıntı olmadan geçiyor.

Sensor akışı kavramsal olarak nasıl işler

Bot Manager katmanlı çalışır. Edge her isteği kendi başına değerlendirir; tarayıcıdaki bir JavaScript katmanı da _abck içine kaydedilen istemci tarafı kanıt ekler. Akamai'nin hızlı başlangıç kılavuzu başlıca tespitleri şöyle sıralıyor:

• Bilinen botları taklit edenler: sahte Googlebot ve benzerleri.
• User agent tabanlı tespit ve istek anomalisi tespiti: bir istek içindeki tutarsızlıklar.
• Web scraper itibarı: "yakın zamanda scraping faaliyetinde bulunmuş IP adreslerine kötü bir itibar puanı".
• Çerez bütünlüğü, oturum doğrulama ve tarayıcı doğrulama: "isteklerin gerçek bir web tarayıcısından geldiğini doğrular".
• Davranış anomalisi tespiti: yalnızca Premier'de, giriş ve ödeme gibi işlem endpoint'lerinde.

Akamai'nin güncel tespit yöntemleri sayfası aynı ayrımı anlatıyor: şeffaf tespit "sırası bozuk başlıkları ve tarayıcı sürümü uyuşmazlıklarını" yakalarken, aktif tespit "isteğin bir web tarayıcısından geldiğini doğrulamak için bir etkileşim kullanır".

Çerez yaşam döngüsü bu tasarımdan çıkar:

1. Korunan bir host'tan gelen ilk yanıt bm_sz ve doğrulanmamış bir _abck ayarlar; sayfa da Akamai'nin script'ini yükler.
2. Script, tarayıcıda istemci sinyallerini (ortam, zamanlama ve bazı sayfalarda etkileşim) toplar ve aynı sitedeki birinci taraf bir endpoint'e gönderir.
3. Akamai bu gönderimi istek düzeyindeki sinyallerle birlikte puanlar ve _abck'i güncelleyen bir Set-Cookie döndürür.
4. Sonraki istekler çerezleri taşır. Edge, bunların bozulmamış olduğunu, bu oturuma ait olduğunu ve gördüğü diğer her şeyle uyuştuğunu kontrol eder.

Kapsam dışı: bu yazı sensor payload'ını, nasıl üretileceğini veya çerez değerlerinin nasıl oluşturulacağını anlatmıyor. Akamai telemetrisini sahtelemek, Cookie Integrity ve ilgili tespitlerin tam olarak yakalamak için var olduğu şeydir ve bu konuda yardım etmiyoruz. TLS ve HTTP/2 fingerprint'leri dahil daha geniş sinyal tablosu için Akamai Bot Manager incelememize göz atın.

Yalnızca HTTP kullanan istemciler neden geçersiz bir _abck ile kalır

requests, httpx veya Go'nun net/http'si gibi bir HTTP kütüphanesi JavaScript çalıştırmaz; dolayısıyla Bot Manager script'i hiç çalışmaz ve _abck'i hiçbir şey güncellemez. İstemci, ilk yanıtta aldığı doğrulanmamış çerezi göndermeye devam eder. Akamai'nin tarayıcı doğrulaması istediği sayfalarda beklenen sonuç budur.

TLS'i düzeltmek bunu değiştirmez. Bir taklit kütüphanesi handshake'i ve HTTP/2 frame'lerini Chrome gibi gösterebilir, ama script'in üreteceği istemci tarafı kanıtı üretemez. Pratikte genellikle şu olur: yalnızca şeffaf katmanı kullanan sayfalar çalışmaya devam eder, aktif doğrulama gerektiren sayfalar (girişler, sepetler, bazı sitelerde arama API'leri) ise 403 veya challenge sayfaları döndürmeye başlar.

Araçlarınızı seçmeden önce gerçekten hangi sayfalara ihtiyacınız olduğunu sorun. Kamuya açık verilerin büyük kısmı aktif katman olmadan erişilebilir durumda ve bir sitenin resmi API'si veya veri akışı çoğu zaman tarayıcı otomasyonundan daha iyi bir çözümdür.

Temiz ve tutarlı bir bağlantıdaki gerçek bir tarayıcı neyi farklı yapar

Gerçek bir tarayıcı script'i çalıştırır, çerezlerini saklar, tek ve tutarlı bir TLS ve HTTP/2 fingerprint'i gönderir ve oturum boyunca tek bir ağda kalır. _abck'i doğrulanmış duruma taşıyan ve orada tutan bu birleşimdir. Her parçası önemlidir:

• Çerez kavanozunu oturum boyunca koruyun. İstekler arasında çerezleri düşürürseniz her istek ilk ziyaret gibi görünür: yeni bm_sz, doğrulanmamış _abck ve script'in yeniden çalışması gerekir. Playwright'ta bir browser context bir çerez kavanozudur. Her sayfa için yeni bir context açmayın.
• Oturum başına tek bir çıkış IP'si kullanın. Bir IP'deki oturuma verilen çerezlerin başka bir IP'den tekrar gönderilmesi, Cookie Integrity'nin yakalamak için tasarlandığı kopyalamaya benzer. Oturum ortasında IP döndürürseniz çerezler verildikleri ağla uyuşmaz hale gelir. Durum taşıyan her şey için (bir kategoriyi gezmek, sepet, oturum açılmış bir akış) sticky oturum kullanın ve yalnızca oturumlar arasında rotasyon yapın. Bunları nasıl boyutlandıracağınızı sticky ve rotasyonlu oturumlar rehberimiz anlatıyor.
• Temiz bir IP'den başlayın. Web Scraper Reputation IP bazında puanlanır. Scraping geçmişi olan bir datacenter aralığı, daha hiçbir çerez ayarlanmadan şüpheyle başlar. Residential ve mobil IP'lerin itibar başlangıç seviyeleri farklıdır; bu puanların nasıl oluşturulduğunu IP itibarı incelememiz açıklıyor.
• İnsan için makul bir hızda istek gönderin. Session Validation istemci başına HTML ve AJAX isteklerini kelimenin tam anlamıyla sayar. Geçerli bir _abck, dakikada yüzlerce sayfa isteği yapan bir oturumu kurtarmaz.

Bu kurallara uyan minimal bir Playwright kurulumu şöyle görünür. Tek kalıcı context, tek sticky residential çıkış ve kaydedilmiş durum; böylece bir sonraki çalıştırma baştan başlamak yerine aynı oturumdan devam eder:

from pathlib import Path
from playwright.sync_api import sync_playwright

STATE = Path("state.json")
PROXY = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "USERNAME-sid-abc123-ttl-10m",   # sticky: bu oturum için aynı çıkış IP'si
    "password": "PASSWORD",
}

with sync_playwright() as p:
    browser = p.chromium.launch(proxy=PROXY)
    context = browser.new_context(
        storage_state=str(STATE) if STATE.exists() else None
    )
    page = context.new_page()
    page.goto("https://www.example.com/", wait_until="load")
    # ... insan temposunda, az sayıda gezinme ...
    names = sorted(c["name"] for c in context.cookies())
    print(names)                                # hangi Akamai çerezlerine sahip olduğunuzu görün
    context.storage_state(path=str(STATE))      # kavanozu bir sonraki çalıştırma için saklayın
    browser.close()

Kaydedilen durumu oturum kimliğine bağlayın. state.json'u farklı bir çıkış IP'si üzerinden sürdürürseniz kaçınmaya çalıştığınız IP değişikliği sorununu yeniden yaratırsınız.

Sorun giderme: belirti, olası neden, neye bakmalı

Her seferinde tek bir değişkeni kontrol edin. "Akamai beni engelliyor" şikâyetlerinin çoğu ilk üç satırdan birine çıkıyor. Bu tabloda pek işe yaramayan ama dürüst bir cevap da yer almalı: bazen site o yolda otomatik trafiğe hizmet vermemeye karar vermiştir ve doğru tepki durmak ya da erişim istemektir.

Site sahipleri için: bu çerezleri kendi loglarınızda okumak

Bot Manager çalıştırıyorsanız değerleri değil, çerez adlarını ve _abck durum işaretini loglayın; kararlar için Akamai'nin kendi bot sonuçlarını kullanın. Değerler şifrelidir ve format haber verilmeden değişebilir. Normal bir erişim logundan çıkarabileceğiniz kalıplar:

• Hiç bm_sz veya _abck olmadan derin URL'lere gelen istekler. Bunlar çerezsiz istemcilerdir: ya ilk ziyaretler ya da çerezleri atan araçlar. Ürün veya arama URL'lerinde, karşılığında açılış sayfası ziyareti olmayan yüksek bir oran, script ile erişime işaret eder.
• Birçok IP veya ASN'den görülen aynı _abck değeri. Bu, çerez paylaşımı veya tekrar gönderimidir. Akamai'nin Cookie Integrity tespiti bunun için kurulmuştur. Loglarınız sorunun ne kadar büyük olduğunu ve hangi yolların etkilendiğini görmenizi sağlar.
• Birçok istek boyunca doğrulanmamış kalan oturumlar. Bu genellikle sayfalarınızın JavaScript'ini hiç çalıştırmayan istemciler demektir. Kuralları sıkılaştırmadan önce bunu kontrol edin, çünkü gizlilik eklentileri ve bozuk script teslimatı da buna yol açar.
• Origin tarafındaki bot sonuçları. Akamai kararını origin'inize istek başlıkları olarak iletebilir. Auth0'ın entegrasyon kılavuzu akamai-bot ve akamai-user-risk başlıklarını belgeliyor ve Akamai'nin "Forward Bot Results to Origin" yapılandırmasına işaret ediyor. Bunun gibi desteklenen bir alan, çerez iç yapısını ayrıştırmaktan iyidir.

Gizlilik konusunda: bu çerezler bir cihaza bağlı tanımlayıcılardır. RIPE NCC'ninki gibi beyanlar bunları kesinlikle gerekli olarak sınıflandırır; AB'de bu genellikle onay gerektirmedikleri anlamına gelir. Ham değerleri IP'lerle birlikte tutan loglar yine de kişisel veridir; işareti ve ad kümesini aldıktan sonra değerleri hash'leyin veya silin.

Bu çerezlerin size söylemedikleri

Bir çerez, istemci tarafı doğrulamanın henüz gerçekleşmediğini gösterebilir. Bir isteğe izin verileceğini gösteremez. İstek düzeyindeki tespitler (IP itibarı, protokol fingerprint'leri, başlık anomalileri, hız) _abck'ten bağımsız çalışır ve site sahipleri dışarıdan göremeyeceğiniz yol bazlı politikalar belirler. Hata ayıklarken çerezleri sinyallerden biri olarak, yanıt kodlarını, challenge sayfalarını ve zamanlamayı da diğerleri olarak kullanın.