Domein scannen op PDF links

[droner]

Ik zoek een (online?) tool die m'n site compleet kan crawlen en een lijst kan maken van alle URLs waarop een PDF te vinden is, en de bestandsnaam van die PDF.

Achtergrond: ik werk aan een nogal flinke site die stikt van de PDF's waarvan een deel verouderd is; echter aangezien jarenlang meerdere mensen aan de site gewerkt hebben is het nogal een doolhof; pagina voor pagina rondklikken is bijna niet aan te beginnen. De bestandsnaam van de PDF's kan me echter vertellen of het een 'oude' PDF betreft, als ik daarbij de URL van de linkende pagina heb weet ik welke pagina's gefixt moeten worden.

Eventueel kan ik ook zelf een crawlertje hosten (op een simpel LAMP hostingpakketje).

Kan iemand me een zetje in de goede richting geven?

[Switchie]

Wellicht denk ik te simpel, maar is het geen idee om gewoon een zoekopdracht "*.pdf" los te laten op de (s)Ftp?

[droner]

De PDF's zelf staan allemaal in een /docs dir maar daar staan sowieso ongelinkte oude files in en vanaf meerdere pagina's kan naar dezelfde PDF gelinkt worden, ik heb dus echt de URLs nodig.

Bijkomend probleem is dat ik geen rechtstreekse toegang tot FTP of database heb - het gaat om een grote corporate site waar dat soort toegang stringent bewaakt wordt door een IT afdeling met messen tussen de tanden. Via het CMS lukt me zo'n zoekopdracht helaas ook niet...

[Fish]

google ?

https://www.google.nl/sea...tweakers.net+filetype:pdf

[droner]

Thanks Fish! Had dat eerder geprobeerd maar gebruikte blijkbaar toch niet de juiste string (kon alleen pag 1 zien, nevermind)

Fixed

EDIT: Alhoewel.. twee probleempjes met deze approach:

- lange URLs worden afgeknot zodat de (PDF) bestandsnaam soms niet helemaal zichtbaar is
- zo krijg je alleen de links naar de PDF's zelf, niet de URL's van de linkende pagina's

[ Voor 46% gewijzigd door droner op 12-12-2016 18:53 ]

[MissingDog]

Lijkt me een mooie gelegenheid om je te bekwamen in de kunst van recursie en het bijhouden van breadcrumbs. Tijd voor het betere scriptwerk (al dan niet op de shell) met wat handig regex gebruik voor de noodzakelijke pattern matching.

[droner]

Shell toegang, IT ziet me al aankomen met die request

Desalniettemin, thx voor het meedenken!

[Switchie]

die stikt van de PDF's waarvan een deel verouderd is

heb weet ik welke pagina's gefixt moeten worden.

Wat is nu precies de case waar je tegenaanloopt en over welke aantallen hebben we het?
Je geeft zelf aan niet van plan te zijn om alle pagina's door te klikken maar hoe wil je anders deze pagina's "fixen"?
Het crawlen is opzich het probleem niet. Zoals hierboven al aangegeven zou zelfs Google de gewenste info voor je kunnen weergeven.

Quick and dirty fix zou eventueel ook kunnen zijn om in /docs te speuren naar de verouderde pdf's en deze vervangen voor een nieuwe versie met dezelfde bestandsnaam. Hoef je ook niet alle url's aan te passen.
Snap dat dit niet de schoonheidsprijs verdient maar zoals Missingdog al schetst was de huidige invulling ook al niet perfect

Shell toegang, IT ziet me al aankomen met die request

Waarom zou dit zo gek zijn? Als jij dergelijke 'tools' nodig hebt om je werk goed en efficiënt te kunnen doen dan is het toch niet anders?
Als ik het gazon moet maaien wil ik ook een maaimachine. Dat ik het werk uiteindelijk ook met een nagelknippertje gedaan krijg is leuk maar vind ik zonde van de tijd Over het gebrek aan uiteindelijk resultaat nog maar niet te spreken.

[ Voor 21% gewijzigd door Switchie op 12-12-2016 18:58 ]

[CodeCaster]

Aangezien je dus een lijst van pagina's wil maken die een link naar een PDF-bestand bevatten, lijkt me de enige relevante vraag: hoe zijn die pagina's opgeslagen?

Als er ofwel een CMS achter zit, dan wel de site bestaat uit losse html-bestanden, dan lijkt me dat zeer triviaal te doorzoeken.

[droner]

Stuk of 500 PDF's gaat het om. Stel dat ik een excel lijstje zou hebben van alle URL's waar een PDF op aangeboden wordt, plus een kolom met de naam van betreffende PDF dan zou ik op basis van die PDF namen snel alle pagina's kunnen identificeren waarop een link aangepast dient te worden.

Quick & dirty fixes op de server of CMS zelf zijn echt totaal geen optie.

Een relatief simpel custom crawlertje zou het werk misschien kunnen doen maar als ik zelf uit moet zoeken hoe ik die in elkaar PHP ben ik alweer een halve dag verder

CodeCaster schreef op maandag 12 december 2016 @ 18:57:
Aangezien je dus een lijst van pagina's wil maken die een link naar een PDF-bestand bevatten, lijkt me de enige relevante vraag: hoe zijn die pagina's opgeslagen?

Als er ofwel een CMS achter zit, dan wel de site bestaat uit losse html-bestanden, dan lijkt me dat zeer triviaal te doorzoeken.

Kan niet vanuit het CMS helaas, hebben de kenners me laten weten. Ook geen losse HTML's, alles ASP.

[ Voor 32% gewijzigd door droner op 12-12-2016 18:59 ]

[droner]

Switchie schreef op maandag 12 december 2016 @ 18:53:
[...]

Waarom zou dit zo gek zijn? Als jij dergelijke 'tools' nodig hebt om je werk goed en efficiënt te kunnen doen dan is het toch niet anders?
Als ik het gazon moet maaien wil ik ook een maaimachine. Dat ik het werk uiteindelijk ook met een nagelknippertje gedaan krijg is leuk maar vind ik zonde van de tijd Over het gebrek aan uiteindelijk resultaat nog maar niet te spreken.

Ik ben dat met je eens hoor, maar IT niet - die laten me liever een week lang door de site klikken dan dat ze een security risico menen te nemen wat ze potentieel bakken geld aan schadevergoeding kan kosten

Is een no-risk omgeving hier... IT is uitbesteed aan grote jongens, miljoenencontracten.

[ Voor 3% gewijzigd door droner op 12-12-2016 19:03 ]

[Fish]

Dan rip je toch gewoon je hele site
https://www.httrack.com/

[Switchie]

droner schreef op maandag 12 december 2016 @ 19:02:
[...]


Ik ben dat met je eens hoor, maar IT niet - die laten me liever een week lang door de site klikken dan dat ze een security risico menen te nemen wat ze potentieel bakken geld aan schadevergoeding kan kosten

Is een no-risk omgeving hier...

http://wummel.github.io/linkchecker/

Kan deze kant-en-klare oplossing niet precies wat jij wilt?

[CodeCaster]

droner schreef op maandag 12 december 2016 @ 18:57:
Kan niet vanuit het CMS helaas, hebben de kenners me laten weten. Ook geen losse HTML's, alles ASP.

"Kan niet" bestaat niet. Ze hebben wellicht geen zin om je te helpen. Die pagina's staan érgens opgeslagen, en op die plek zijn ze doorzoekbaar. Het is de meest makkelijke, minst foutgevoelige weg.

Crawlers / rippers / Google gaan pagina's missen waarnaar niet gelinkt wordt, of die achter een login staan, of ...

[ Voor 18% gewijzigd door CodeCaster op 12-12-2016 19:07 ]

[droner]

Ik ga die eens checken Switchie, dank!

Httrack als backup optie!

Goed punt wel wat die gemiste links betreft Codecaster, dat zal ik vast maar op de koop toe moeten nemen.. ongelinkt is geen issue, achter login is geloof ik niet zo veel.

[ Voor 83% gewijzigd door droner op 12-12-2016 19:07 ]

[Switchie]

CodeCaster schreef op maandag 12 december 2016 @ 19:03:
[...]
Crawlers / rippers / Google gaan pagina's missen waarnaar niet gelinkt wordt, of die achter een login staan, of ...

Google wel inderdaad maar een Crawlertje kan waarschijnlijk wel ingesteld worden om de robots.txt te negeren.
Jullie hebben inderdaad gelijk.

[ Voor 5% gewijzigd door Switchie op 12-12-2016 19:25 ]

[MissingDog]

droner schreef op maandag 12 december 2016 @ 18:44:
Shell toegang, IT ziet me al aankomen met die request

Desalniettemin, thx voor het meedenken!

Ik doelde uiteraard op client-side shell scripting, bijvoorbeeld bash of powershell, misschien wat python als dat je beter ligt. Totaal geen noodzaak om op de server shell access te hebben.

[CodeCaster]

Switchie schreef op maandag 12 december 2016 @ 19:07:
[...]

Google wel inderdaad maar een Crawlertje kan waarschijnlijk wel ingesteld worden om de robots.txt te negeren.

Dan moet er nog steeds naar iedere te scannen pagina worden gelinkt vanaf een andere pagina. Als pagina's alleen beschikbaar zijn via een POST of via de zoekmachine van de site, bijvoorbeeld, dan worden die dus niet gevonden door crawlers.

Maar als dat volgens TS niet het geval is, kan een crawl-tool inderdaad uitkomst bieden.

[droner]

Hmm nee volgens mij gaat het idd alleen om pagina's die via browsen gevonden kunnen worden.

[RobIII]

droner schreef op maandag 12 december 2016 @ 19:10:
Hmm nee volgens mij gaat het idd alleen om pagina's die via browsen gevonden kunnen worden.

wget --mirror --convert-links --adjust-extension --no-parent http://jesite.nl

Maakt een mirror van je site. Daarmee heb je alle pagina's "offline" staan. Daarna kun je helemaal nuts gaan op de directory met die bestanden zonder de webserver te belasten met onnodige requests etc. Eventueel kun je met --page-requisites ook nog eens de images/pdf's etc. daadwerkelijk downloaden.

Maar, zoals hierboven al door meerdere mensen aangegeven, er zitten nogal wat mitsen en maren aan (logins, formulieren etc.)

Verder is dit meer iets voor CSA dan WEB.

[ Voor 38% gewijzigd door RobIII op 12-12-2016 19:30 ]

[The Eagle]

Mocht je op de server zelf kunen, dan is een simpele locate *.pdf natuurlijk al voldoende (aangenomen linux).

[Keiichi]

The Eagle schreef op maandag 12 december 2016 @ 20:09:
Mocht je op de server zelf kunen, dan is een simpele locate *.pdf natuurlijk al voldoende (aangenomen linux).

Even aangenomen dat je op een willekeurige hoster dus geen ssh access hebt