Katana İncelemesi: `-jc` ve `-headless` Farklı Uç Noktalar Buluyor, İkisini Birden Yakalayan Tek Bir Komut Yok

Katana, ProjectDiscovery’nin uç nokta keşif tarayıcısıdır — Go ile yazılmış, MIT lisanslı bir ikili dosya; bir hedefi alır ve bir sonraki araç için URL’ler ve uç noktalar döndürür. Tarayıcı kullanmadan HTTP modunda ya da Chromium’u çalıştıran -headless ile tarama yapabilir. Resmî yönlendirme, headless modunu daha geniş kapsama sunan seçenek olarak anlatır; bu örnek, yalnızca sayının değil, uç noktanın türünün de ne kadar önemli olduğunu gösteriyor.

Küçük bir site kurup, kasıtlı olarak farklı üç uç nokta sınıfı oluşturduğum bir test yaptım ve v1.6.1 sürümünde -d 4 ile hangi modun hangisini bulduğunu ölçtüm. Sıradan HTML, dört yapılandırmanın hepsinde 4/4 bağlantıya ve tam üç sıçramalı zincire ulaştı. Ayrışma, JavaScript kaynağı üzerinden görünen uç noktalar ile çalışma anında DOM değişiklikleriyle ortaya çıkan uç noktalarda oldu.

Bu testte headless, tarayıcı kullanmadan çalışan modların kaçırdığı çalışma anı DOM sınıfını buldu; buna karşılık standart modda -jc, headless çalışan iki denemede de kaçan JavaScript dosyası içindeki sabit değerleri buldu. Dört komutluk матrisin hiçbir satırı bu iki sınıfı birlikte kapsamıyordu. Kapsam, devam ettirme ve bilinen dosyalar davranışı ise diğer pratik sınırları gösterdi.

Katana gerçekte nedir?

Katana tarayıcısı — GitHub’daki projectdiscovery/katana — Go ile yazılmış ve MIT lisanslıdır. Ben v1.6.1 sürümünü 27 Temmuz 2026’da test ettim; sürüm önemli çünkü aşağıda anlatılan kapsama ve bilinen dosyalar bulguları derlemeye özgü gözlemlerdir.

Burada kategori etiketi her zamankinden daha önemli. Bir uç nokta keşif tarayıcısı, alan çıkarıcı değildir. Ürün adlarını ve fiyatlarını yapılandırılmış JSON olarak veren bir go web crawler istiyorsanız, Katana tamamen yanlış raftadır — size memnuniyetle /products/1138 var der ama o sayfanın içinde ne olduğuna dair tek kelime etmez. Bu tasarım gereğidir; çıkarım yeteneğine göre değerlendirmek, metal dedektörünü mücevher değer biçme konusunda incelemek gibidir.

Asıl kullanım alanı saldırı güvenliği keşfi ve otomasyon boru hatlarıdır: STDIN’den alır, URL’ler üretir, bir sonraki araca yönlendirirsiniz. Buradan önemli bir uyarı doğuyor: buradaki tüm ölçümler, benim yazdığım 127.0.0.1 üzerindeki bir yerel örnekleme karşı yapıldı. Katana’yı yalnızca size ait ya da yazılı yetkiniz olan sistemlerde kullanın; başka hiçbir yerde değil. Buradaki konu kimsenin savunmasını aşmak değil; bir komutun bir sitenin uç nokta yüzeyinin ne kadarını gerçekten listelediği.

Üç mod ve her birinin görebildikleri

Standart mod, Go tabanlı bir HTTP istemcisidir. Sayfayı çeker, HTML’yi ayrıştırır, href bağlantılarını takip eder ve asla tarayıcı başlatmaz. Hızlıdır, ucuzdur; ama JavaScript çalıştıktan sonra oluşan şeylere kördür.

-jc (-js-crawl), bu tarayıcısız yola bir JavaScript ayrıştırıcısı ekler. Bağlantılı .js dosyalarını indirir ve kaynak içindeki URL biçimli string sabitlerini çıkarır. Çalıştırma yok, sadece okuma var. Ayrıca README’de daha ağır, bellek tüketimi yüksek bir ayrıştırıcı olarak tanımlanan -jsl (jsluice) de var — bunu test etmedim, dolayısıyla kapsama açısından fark yaratıp yaratmadığına dair söyleyecek bir şeyim yok.

-headless, Chromium’u çalıştırır ve sayfa scriptlerini yürütür. Bu testte, parçalardan birleştirilip çalışma anı DOM’una eklenen yolu geri getiren tek Katana modu oydu. Bu sonuç, her ayrıştırıcının ya da gelecekteki her Katana modunun neleri geri getirebileceğini kanıtlamaz.

Sonra kapsam modeli var; üretim ortamında herhangi bir şey yazmadan önce içselleştirmeniz gereken kısım da bu.

Sıralama sadece görsel bir ayrıntı değildir: bir host regex’inin taramayı genişletip genişletmediğini ya da sessizce boşaltıp boşaltmadığını belirler.

Kurulum: tek ikili, bir tek yıldız işareti

Üç kurulum yolu var; bunların yalnızca biri araç zinciri ister:

Benim kurulumum ~/go/bin/katana altına geldi ve her çalıştırmada Current version: v1.6.1 döndürdü. Şimdilik bildik ve keyifli Go hikâyesi: tek dosya, çalışma zamanı yok.

Yıldız işareti headless modda geliyor; burada tarayıcı, ikiliden ayrı bir gereklilik:

Çıplak bir sunucuda bu kolaylık ortadan kalkıyor. Komut satırına -headless girer girmez yalnızca ikiliyi değil, bir tarayıcıyı da bütçeye ekleyin.

CI’da kullanacaksanız bilinmesi gereken küçük ama önemli bir nokta: Katana başlarken GitHub’a bir sürüm kontrol çağrısı yapıyor. -duc bunu kapatıyor. Dizüstünde önemsizdir; ağsız ya da hız sınırına takılan bir çalıştırıcıda ise her koşuda istemediğiniz bir ağ gidip gelmesidir. Zaman ölçümlerimde -duc kullandım; böylece rakamlar “eve haber verme” değil, taramayı ölçüyor.

Nasıl test ettim?

Modları birbirinden ayırmak için bilerek seçilmiş üç uç nokta sınıfı. Her şey bir yerel örnek sunucusunda duruyor ve herhangi bir tarama başlamadan önce gerçek durum yazılıydı; bu yüzden geri çağırma, Katana’nın o anda ne yazdırdığına değil sabit bir küme üzerine ölçülüyor.

• Sınıf A — düz HTML. /page/a, /page/b, /page/c ve üç sıçramalı zincir /depth/1 → /depth/2 → /depth/3. Her tarayıcı bunları bulmalıdır.
• Sınıf B — JavaScript dosyası içindeki sabit metinler. /api/js-endpoint-7 ve /api/js-endpoint-8, yalnızca bağlantılı bir /static/app.js içindeki string sabitleri olarak bulunur. Bir şey JavaScript’i okumaya zahmet ederse, tarayıcı olmadan da okunabilir.
• Sınıf C — yalnızca çalışma anı DOM’u. Parçalardan çalışma anında oluşturulan ('endpoint' + (6 * 7)) ve script ile DOM’a eklenen tek bir yol. /runtime-only/endpoint42 dizgisi, sunucunun gönderdiği hiçbir baytta yan yana görünmez — ne HTML’de ne de JS kaynağında. Yalnızca çalıştırma bunu ortaya çıkarır.

Buna ek olarak robots.txt, sitemap.xml içinde başka hiçbir yerde geçmeyen iki <loc> uç noktası, 500 dönen bir rota, ölü bir bağlantı ve farklı host adındaki ikinci bir sunucuya işaret eden kapsam dışı bir bağlantı vardı.

Kullanılan ölçüm aracı da örnekleme kadar önemlidir: sunucu gerçekte neyin çekildiğini sayar; dolayısıyla kapsam ve devam ettirme iddiaları, Katana’nın kendi stdout’una değil gerçek isabetlere dayanır. Ham çalıştırmalar, hesabımı kontrol etmek isterseniz benchmark deposuna işlenmiş durumda.

Kimsenin sayıya dökmediği kapsama ayrımı

-d 4 ile, moda göre uç nokta sınıfı matrisi:

Son iki sütunu birlikte okuyunca sorun hemen görünür. Sınıf B yalnızca tek bir yapılandırma tarafından bulundu: -jc ile standart mod. Sınıf C ise yalnızca iki yapılandırma tarafından bulundu: iki headless çalıştırma da. Her iki sütunda da isabet olan tek bir satır yok. Tam matris discovery-summary.json içinde; oradaki headless_jc_covers_both alanı false değerini okuyor.

Pratik sonuç şu: “Daha iyi kapsama için headless kullan” ifadesi bu test için eksikti. Headless, standart sonuca ek olarak sınıf B’yi getirmedi; bunun yerine sınıf C’yi kurtardı ama sınıf B’yi kaçırdı. Bu örnekte ekilmiş tüm sınıfları kapsamak için iki tarama ve bir birleştirme gerekiyordu:

katana -u https://target.example -jc -d 4 -silent -o pass-jc.txt
katana -u https://target.example -headless -d 4 -silent -o pass-headless.txt
sort -u pass-jc.txt pass-headless.txt > endpoints.txt

-headless -jc satırı, upstream’den en çok cevap görmek istediğim satır. JavaScript ayrıştırıcısını headless çalıştırmaya eklemek hiçbir şeyi geri getirmedi — sınıf B’de hâlâ 0/2, her çalıştırmada, taze yeniden üretimde de dahil. Burada mekanizmayı çözümlediğimi iddia etmiyorum; neden tarayıcı yolunun JS dosyası sabitlerini katkı olarak eklemeyi bıraktığını anlamak için Katana’nın içini enstrümante etmedim. Bunu, yeniden üretilebilir bir gözlem ve iyi bir GitHub sorunu olarak görün; teşhis olarak değil. (Bununla birlikte, v1.6.1’de macOS ARM üzerinde -hl -jc birleşimi dönüş kodu 0 ile sorunsuz tamamlandı; tarihsel olarak bu her zaman böyle değildi.)

Resmî belgeler, headless’in daha iyi kapsama sağladığını söylüyor; burada da çalışma anında oluşturulan sınıfta bunu yaptı. Fakat kontrol edilen rehber, kaynak-sabit / çalışma anı DOM ayrımını açıkça anlatmıyordu; bu yüzden matrisi, kendi uç nokta sınıflarınıza karşı iki yolu da test etmek için bir neden olarak görün, evrensel bir taksonomi olarak değil.

Headless’ın zaman maliyeti

Boşta sayılabilecek bir makinede, her mod için ardışık üç çalıştırma:

Bu, aralıkları birbirine hiç yaklaşmayan bir 5.1x oran demek — en yavaş standart çalışmam (13.17s), en hızlı headless çalışmamı (66.78s) 53 saniyeden fazla farkla geçti (cost-summary.json). Bu ölçüm gürültüsü değil.

13 saniyelik değere ilişkin küçük bir not: örneklemem kasıtlı olarak bir 500 rotası ve bir ölü bağlantı içeriyor; standart mod varsayılan -timeout 10 tekrar kuyruğunun sonuna her ikisinde de takılıyor. Hızlı modu güzelleştirecek şekilde zaman aşımını ayarlamadım; bu da ayarlanmış bir standart çalışmanın farkı daraltmaktan çok muhtemelen genişleteceği anlamına gelir.

Bu oran yerel kapasite sinyalidir, üretim tahmini değil. Gerçek hedefler gecikme, hata, script işi ve zamanlama bakımından değişir; bu örnek ise varsayılan bir zaman aşımı kuyruğu içeriyor. Ölçülen 5.1x farkı, headless’ın ayrı bir bütçe ve hedef alt kümesi hak edip etmediğine karar vermek için kullanın; sonra bu planı temsili ve yetkili ana makinelerde benchmark edin.

Kapsam korunuyor, ama bir bayrak sessizce etkisiz kaldı

Kapsam testi iki sunucu kullandı: birincil sunucu 127.0.0.1 üzerinde, ikincisi ise farklı bir portta localhost olarak erişilebilen ve yalnızca orada var olan bir yolu sunuyor. Dolayısıyla o yoldaki bir isabet, kapsam dışı host’un gerçekten çekildiğinin kanıtıdır; sadece yazdırıldığının değil.

Kapsam disiplini iyi haber: varsayılan durumda Katana yerinde kaldı ve kapsamı genişletmek için açık bir eylem gerekiyordu. Başkalarının altyapısına yönlendirilen bir araç için doğru varsayılan budur.

İlginç satır -cs localhost satırıdır. Taramanın ikinci host’a genişlemesini sağlamadı — ve ayrıca hiç URL üretmedi. Çünkü -cs, alan kapsamı içinde filtre uygular; alan kapsamı hâlâ birincil host olduğundan regex hiçbir şeyi eşlemedi ve tarama hata yerine boş küme döndürdü. Eğer bir tarama-kapsam regex’i yazıp dahil etmek istediğiniz host’un adını oraya koyduktan sonra boş bir çıktı dosyasına bakakaldıysanız, mekanizma budur (scope-summary.json). Bir host eklemek için -fs kullanın. Sahip olduğunuz host’ların içinde daraltmak için -cs/-cos kullanın.

Resume, bayrağın ima ettiğinden daha kaba davranıyor

README, bayrağı -resume string resume scan using resume.cfg olarak tanımlıyor; bu da çalışma dizinine bırakılmış bir dosya gibi okunuyor. Öyle değil. Benim makinemde checkpoint ~/.config/katana/resume-<xid>.cfg içine yazıldı — bunu belgeden okumadım, ölçtüm; çünkü dokümanlar bir yol belirtmiyor.

İçindeki en önemli sürpriz ise başka. Dosya, InFlightUrls adlı bir eşleme içeriyordu ve içinde tam olarak bir şey vardı: seed URL. Ziyaret edilmiş küme değil, ön sınır da değil. Üç saniye sonra bir taramayı SIGINT ile kesip devam ettirdiğimde olan buydu:

Resume, aynı nihai uç nokta kümesine ulaştı; yani bir şey bozuk değil. Ama checkpoint ayrıntısı her URL için değil, her giriş seed’i için; bellekteki dedupe filtresi kalıcılaştırılmıyor, bu yüzden tek seed’li bir taramayı resume etmek o seed’i baştan tarıyor (resume-summary.json). Eğer Katana’ya 500 host’luk bir liste verirseniz, resume tamamen biten host’larda zaman kazandırmalıdır; bu çoklu-seed davranışı durumun nasıl saklandığından çıkar, fakat ben yalnızca tek-seed durumunu ölçtüm. Çok büyük tek bir siteye gömülüyorsanız, resume size zaman değil doğruluk kazandırır.

Bilinen dosyalar: istendi, sonra düşürüldü

-kf all -d 3 gerçekten iki dosyayı da istedi — robots.txt ve sitemap.xml sunucunun hit günlüğünde göründü — sonra da sitemap’in <loc> öğelerinde listelenen uç noktaların 2’sinden 0’ını geri getirdi. Geri çağırma 0.0.

Bunu bir sınırlama olarak adlandırmadan önce, hatanın bende olup olmadığını anlamaya çalıştım. Her varyasyon aynı şeyi geri verdi:

Belirtilen gereksinim — -kf kullan, en az üç derinliğe git — her seferinde karşılandı. Bu, eksik bayrak hikâyesi değil.

İşin yararlı kararı önce gelir: bu IP-literal örneklemede, bilinen dosyalar istiyor olmanın onların <loc> URL’lerinin taramaya katıldığı anlamına geldiğini varsaymayın. Geri çağırmayı doğrulayın ya da bu URL’leri çıkarıp kendiniz seed olarak verin.

v1.6.1 kod yolu gözleme uyumlu; ancak çalıştırma sırasında onu enstrümante etmedim. v1.6.1 sürümündeki sitemapxml.go dosyasında, NewNavigationRequestURLFromResponse bir yanıttan <loc> gezinme istekleri üretirken RootHostname alanını doldurulmuş olarak taşımıyor. İstek ardından ValidateScope’a ulaşıyor; v1.6.1 sürümündeki scope.go dosyasında, IP-literal dalı URL host’unu boş root ile karşılaştırıp bunu reddedebiliyor. Ayrı bir kapsam testinde kullanılan özel -fs '(127.0.0.1|localhost)' komutu farklı bir kapsam dalı aldı; dolayısıyla bu, kaynaktan tahmin edilen bir kurtarmadır, ölçülmüş bir -kf çözümü değil. Doğrulama denemesi, bu makinedeki bilinen dosyalar istemcisinde zaman zaman görülen bağlanma sorunları nedeniyle engellendi; bu yüzden raporlanan sonuç 0/2 olarak kalıyor.

Üretimde, biri bunu doğrulayana kadar, benim yapacağım şey şudur: sitemap’i kendim çeker, <loc> URL’lerini çıkarır ve Katana’ya seed listesi olarak veririm. İki satır shell; kapsam doğrulaması yok.

Beklendiği gibi çalışan ve bir cümleyi hak eden bir şey de vardı: 500 rotası ve ölü bağlantı çekildi, loglandı ve geçildi. Tarayıcı kullanmayan her çalıştırma dönüş kodu 0 ile tamamlandı. İlk kötü yanıtta düşen bir tarayıcı işe yaramaz; Katana da öyle yapmıyor.

Yayına almadan önce hedefe özgü bir kapsama kontrolü

Örnek matris, kendi yetkili hedeflerinizi test etmek için bir şablon olarak en kullanışlı haliyle duruyor. Katana’yı çalıştırmadan önce uç nokta sınıflarını tanımlayın: düz bağlantılar, bağlı script’lerdeki sabit değerler, yalnızca çalıştırmadan sonra oluşan rotalar ve bilinen dosya girdileri iyi başlangıç kümeleridir. Her sınıf için küçük bir gerçek durum örneği tutun. Bu ön liste olmadan, daha büyük bir stdout dosyası bir sınıf kaybolmuş olsa bile daha iyi kapsama gibi görünebilir.

Önce tarayıcısız ve headless yollarını ayrı ölçümler olarak çalıştırın. Tam komutları, Katana sürümünü, tarayıcı derlemesini, dönüş kodlarını ve çıktıları kaydedin. Satır sayısı yerine uç nokta kümelerini normalize edip karşılaştırın. Eğer standart -jc, örnekleminizde benzersiz hiçbir şey katmıyorsa, yalnızca headless politikası yeterli olabilir; burada olduğu gibi kümeler ayrışıyorsa, iki geçişi ayrı tutup topladıktan sonra birleştirin. Bir komutta iki bayrağı birleştirmenin, hedefe özgü fark kanıtlamadıkça birleşimle aynı olduğunu varsaymayın.

Kapsamı Katana çıktısı dışındaki kanıtlarla doğrulayın. Hariç kalması gereken bir host üzerine bir canary URL koyun ve o sunucunun istek günlüğünü inceleyin. Tarama genişleyecekse, amaçlanan ikinci host’u da test edin. Buradaki -cs localhost çalıştırması, içerik kapsamı filtresi alan kapsamı genişletmediği için boş çıktı üretti; özel -fs '(127.0.0.1|localhost)' çağrısı ise ikinci sunucuya gerçekten ulaştı. Tam regex ifadesini kaydetmek önemlidir; çünkü tek karakterlik değişiklikler yalnızca sunumu değil, regex’in kendisini de değiştirebilir.

Resume ve bilinen dosyaları keşif geri çağırmasından ayrı test edin. Resume için, temsilî bir seed’i birkaç sayfa sonra kesip üretilen checkpoint yolunu kaydedin ve tamamlanmış kaç URL’nin yeniden çekildiğini sayın. -kf için, hem robots/sitemap’in istendiğini hem de eklenmiş <loc> URL’lerinin gerçekten kuyruğa alındığını doğrulayın. Bunlar farklı iddialardır. Bu örnekte dosyalar çekildi ama iki sitemap uç noktası ortada yoktu; dolayısıyla sınırı görmek için hem istek günlükleri hem de uç nokta çıktısı gerekliydi.

Son olarak, başka türlü boş olan bir makinede ardışık çalıştırmalarla yerel bir maliyet tabanı oluşturun, sonra temsili host’larda tekrarlayın. Sadece bir çarpan değil, minimum, maksimum ve medyanı koruyun. Buradaki 5.1x değeri, örneklemin hata ve zaman aşımı davranışını içeriyor; size headless’ın ayrı bir bütçe hak ettiğini söyler, üretim envanterinin ne kadar süreceğini değil.

Artılar ve eksiler

Artılar:

• Her modda sıradan HTML’de kusursuz geri çağırma — 4/4 bağlantı ve tam 3/3 derinlik zinciri, yapılandırma gerektirmiyor.
• -jc gerçekten tarayıcı olmadan çalışıyor: bağlı bir JS dosyasındaki string sabitlerinden 2/2 uç nokta geri alındı, tarayıcı maliyeti olmadan.
• -headless, çalışma anında birleştirilen bir uç noktayı bulabilen tek seçenek — tasarım gereği kaynak ayrıştırmaya görünmez olan bir sınıf.
• Kapsam varsayılanları temkinli. Kapsam dışı host, varsayılan ayarda, -fs fqdn ile ya da -cs ile hiç çekilmedi.
• Tek Go ikilisi, MIT lisansı, önceden derlenmiş yapılar ve Docker imajı, boru hattı biçimli I/O.
• Hatalara karşı dayanıklı: 500’ler ve ölü bağlantılar taramayı durdurmuyor.

Eksiler:

• Tek bir çalıştırma, JS dosyası ve çalışma anı DOM uç noktalarının ikisini birden kapsamadı. Tam kapsama için iki koşu ve bir birleştirme gerekiyor.
• -headless altında -jc hiçbir katkı sağlamadı — her headless koşuda sınıf B için 0/2.
• Headless, çalışma süresinde 5.1x maliyet getiriyor (66.82s vs 13.08s p50, kesişmeyen aralıklar).
• -resume, bir seed içindeki tamamlanmış sayfaları yeniden tarıyor. Uç nokta kümesini geri getiriyor, geçen süreyi değil.
• Bilinen dosyalar robots.txt ve sitemap.xml istedi ama IP hedefe karşı sitemap <loc> uç noktalarının 2/0’ını geri getirdi.
• Headless görünmez biçimde kutu üzerinde Chromium gerektiriyor; “tek ikili” hikâyesi tarayıcıda bitiyor.
• Yalnızca keşif. Yapılandırılmış çıkarım yok, içerik dönüşümü yok, alan şeması yok.

Test edilmemiş ve bu yüzden bu sayıların kapsamadığı şeyler: -jsluice, -d 1/-d 2 için özel bir derinlik kesme testi, çoklu-seed resume, otomatik form doldurma ve gerçek, JavaScript ağırlıklı ya da korumalı herhangi bir üretim sitesi. Tüm sayılar tek bir makinede (macOS arm64) yerel bir örneklemeye karşı alınmıştır.

Kimler için uygun, kimler kaçınmalı?

İşiniz, dokunma yetkiniz olan altyapının uç nokta envanterini çıkarmaksa, Katana doğru boru hattı yapısına sahiptir: STDIN/STDOUT akışı, dağıtılabilir ikili ve hem tarayıcısız hem tarayıcılı modlar. Bu örnekte ekilmiş sınıflar için iki geçişli birleştirme gerekliydi; hedeflerinizin de her iki geçişe ihtiyaç duyup duymadığını, temsilî sayfalardan çıkarmak gerekir.

Adres değil, veri istiyorsanız kullanmayın. Katana size ürün tablosu vermez; ürünlerin bulunabileceği URL’leri verir ve çıkarımı başka bir şey yapar. Ayrıca tek bir komutun eksiksiz olmasını istiyorsanız da kaçının — iki geçişli birleştirme boru hattında sorun değil, komut satırında can sıkıcıdır. Üstelik envanteriniz sitemap <loc> uç noktalarına dayanıyor ve IP hedefliyorsanız, çıktıya güvenmeden önce gerçekten ne aldığınızı doğrulayın; çünkü benim örneklememde bu yol hiçbir şey döndürmedi.

Alternatifler ve çıkarım sınırı

Katana ücretsizdir, MIT lisanslıdır ve kendi altyapınızda çalışır. Keşfi, mod seçimini, tarayıcı dağıtımını ve sonuç birleştirmeyi sınırın kendi tarafında tutar.

Açık kaynak içinde yararlı karşılaştırma, dil değil iş bazındadır. Colly başka bir Go seçeneğidir; ancak kendi geri çağrılarınızla derlediğiniz bir kütüphanedir ve JavaScript’i hiç çalıştırmaz. Crawl4AI gerçek bir tarayıcı çalıştırır ve LLM boru hatları için Markdown üretir; bu ise bambaşka bir çıktıdır. Bunların birkaçını aynı anda tartıyorsanız, açık kaynak scraper derlememiz kategorileri yan yana koyuyor.

Açıklama: Thunderbit yayıncının ürünüdür ve bu Katana örneğinde test edilmemiştir. Yönetilen çıkarım kategorisinde aşağı akışta yer alır; sayfaları metne veya yapılandırılmış kayda dönüştürür, yetkili bir hedefin uç nokta yüzeyini listelemez. Bir iş akışı iki kategoriyi birlikte kullanabilir; ancak bu inceleme yalnızca Katana’nın keşif davranışı için kanıt sunar.

Web Verisi Çıkarımı için Thunderbit’i Deneyin

Sonuç

Katana’yı, teslim edilecek şey yetkili olduğunuz hedefler için bir uç nokta listesi olduğunda ve mod kapsamını bu hedeflere göre doğrulayabildiğinizde kullanın. Bu örnekte standart -jc, ekilmiş JavaScript dosyası sabitlerini geri getirirken, headless çalışma anı DOM uç noktasını buldu; test edilen tarayıcısız modlar bu çalışma anı yolunu geri getirmedi. Varsayılan kapsam, ikinci host’un çekilmesini de engelledi ve tarayıcısız koşular 500 ile ölü bağlantıdan sonra da devam etti.

Uyarılar operasyoneldir: karışık uç nokta sınıfları için iki aşamalı birleştirme gerekebilir, headless yerel sürede yaklaşık beş kat daha uzun sürdü, tek-seed resume tamamlanan yolları yeniden çekti ve bilinen dosyalar IP hedefe karşı 2/0 geri çağırma verdi. Bunlar v1.6.1 örnekleme sonuçlarıdır; her site için garanti değildir. Ama bir üretim değerlendirmesinin tekrar etmesi gereken kontrolleri tanımlamak için fazlasıyla yeterlidir.

Web Verisi Çıkarımı için Thunderbit’i Deneyin Get Started Free

SSS

Katana resume dosyasını nereye kaydediyor ve resume etmek daha önce taradığım sayfaları atlıyor mu? Checkpoint, bayrak yardım metninin ima ettiği gibi çalışma dizinindeki bir resume.cfg dosyasına değil, ~/.config/katana/resume-<xid>.cfg dosyasına yazıldı. Hayır, tamamlanan sayfaları atlamıyor: dosya yalnızca devam eden seed URL’lerini saklıyor; bu yüzden resume edilen tek-seed tarama, daha önce tamamlanmış 10 yol dahil olmak üzere bazdaki 11 yolun hepsini yeniden çekti. Nihai uç nokta kümesi aynı kalıyor, ama kazanılan zaman geri gelmiyor.

Neden -kf all sitemap.xml’imi istedi ama içindeki URL’leri taramadı? Bir IP hedefe karşı sonuç, bayrak hatasından çok kapsam doğrulama sınırıyla tutarlı görünüyor. v1.6.1 kodunda Katana’nın sitemap ayrıştırıcısı her <loc> isteğini root hostname’i ileri taşımadan oluşturuyor ve IP-literal host’lar için DNS kapsam kontrolü bu URL’yi reddedebiliyor; çalıştırma sırasında bu mekanizmayı doğrulamak için enstrümantasyon yapmadım. Denediğim her bayrak, derinlik ve seed varyasyonunda geri çağırma 0’da kaldı. Özel bir -fs host regex’i farklı bir doğrulama dalı kullanır ve kaynak bunun bir çözüm olacağını öngörür — ancak bunu kendi makinemde -kf ile doğrulayamadım, bu yüzden test edilmemiş kabul edin. <loc> URL’lerini kendiniz çıkarıp Katana’ya seed olarak vermek, bugün güveneceğim yöntemdir.

Bir Katana kapsama testini raporlarken neyi saklamalıyım? Tam Katana sürümünü ve komutunu, bayt bayt -fs ifadesi dahil kaydedin; çalıştırmadan önce uç nokta sınıflarını tanımlayın; stdout’a ek olarak sunucu tarafı istek günlüklerini tutun; ölçülen davranış ile kaynak temelli hipotezleri ayırın. Headless koşularda tarayıcı derlemesini de kaydedin — bu test kaydetmedi, bu da yeniden üretimi sınırlar.

-jc, -headless ya da ikisini birden mi kullanmalıyım? İhtiyacınız olan uç nokta sınıflarına göre seçim yapın. Bu örnekte standart -jc, bir JavaScript dosyasında saklanan sabitleri buldu; headless ise çalışma anı DOM’una eklenen uç noktayı buldu. İki moddan hiçbiri tek başına her iki sınıfı kapsamadı; bu yüzden karışık hedeflerde savunulabilir seçenek, iki geçişli çalıştırma ve ardından tekilleştirme oldu.

Bir başarısız URL taramayı durdurur mu? Bu kontrollü çalıştırmada durdurmadı. Katana, hem 500 yanıtından hem de ölü bağlantıdan sonra devam etti ve yine de erişilebilen diğer yolları döndürdü. Bu, üretim hata takibinin yerine geçmez: başarısız istek günlüklerini tutun ve kabul edilebilir bir hata oranı tanımlayın; böylece kısmen başarılı bir tarama eksiksiz kapsama sanılmasın.