[PHP] redirect pdf direct access maar local script niet

[Khallouki]

Hoi allemaal,

Ik zit al een tijdje met een probleem en kan het antwoord niet echt vinden op het internet.

Momenteel heb ik een hoop PDF files op een server liggen. Deze PDF's mogen niet direct te zien zijn maar moeten geredirect worden naar een pagina waar nog overige info over de PDF getoond moet worden (titel, in welke pagina het voorkomt etc.)

Dat redirecten gaat goed met htaccess. Daar gebruik ik de volgende rewriterule voor:

code:

RewriteRule (.+\.pdf)$ https://urlvandewebsite.com/pdf-reader/?src=$1 [L]

Echter, de PDF embedder reader (plugin) die ik gebruik op de geredirecte pagina fetched de pdf maar krijgt de geredirecte pagina terug.

Hoe zorg ik ervoor dat local scripts wel PDFs mogen ophalen en direct access PDFs ophalen niet?

De website draait op wordpress.

Alvast bedankt!

Groetjes,
Soufiane

[ Voor 1% gewijzigd door RobIII op 05-01-2016 17:15 . Reden: Code tags toegevoegd. ]

[Creepy]

Nogal logisch, je redirect alles wat eindigt op .pdf naar je tussenpagina. Maar dat had je zelf ook alvast wel hebben bedacht. Je zult een extra pagina/script moeten maken die als doorgeef luik fungeert.

[Khallouki]

Creepy schreef op dinsdag 05 januari 2016 @ 16:57:
Nogal logisch, je redirect alles wat eindigt op .pdf naar je tussenpagina. Maar dat had je zelf ook alvast wel hebben bedacht. Je zult een extra pagina/script moeten maken die als doorgeef luik fungeert.

Ik snap je advies niet helemaal. Doorgeefluik? Waar moet die komen te staan en hoe moet de htaccess weten dat hij dat niet moet redirecten?

[Gomez12]

Wat noem jij hierin "local" scripts? Zijn dat javascriptjes die dus eigenlijk bij de klant draaien (en dus remote zijn) of is dat echt iets wat op de server een pdf omzet naar bijv een bmp die getoond wordt oid?

Want als het echt om local scripts gaat dan zou je die kunnen laten verwijzen naar niet je complete hostnaam maar naar localhost en dan in je htaccess en je hostnaam af laten vangen.
Enkel gaat dit niet werken met client-side dingen want voor die is localhost hun localhost.

Je kan btw naast een extra pagina ook gewoon je htaccess rewrite zo zetten dat die alle pdfs minus alles met in de url pdf-reader/?src= doorlaat ipv echt simpelweg alle pdfs

[Khallouki]

Gomez12 schreef op dinsdag 05 januari 2016 @ 18:22:
Wat noem jij hierin "local" scripts? Zijn dat javascriptjes die dus eigenlijk bij de klant draaien (en dus remote zijn) of is dat echt iets wat op de server een pdf omzet naar bijv een bmp die getoond wordt oid?

Want als het echt om local scripts gaat dan zou je die kunnen laten verwijzen naar niet je complete hostnaam maar naar localhost en dan in je htaccess en je hostnaam af laten vangen.
Enkel gaat dit niet werken met client-side dingen want voor die is localhost hun localhost.

Je kan btw naast een extra pagina ook gewoon je htaccess rewrite zo zetten dat die alle pdfs minus alles met in de url pdf-reader/?src= doorlaat ipv echt simpelweg alle pdfs

Met local scripts bedoel ik echter 1 script. Het is een PHP bestand die de PDF wil ophalen om te embedden in de html pagina. Echter krijgt de PHP bestand niet de pdf als resultaat maar de geredirecte pagina.

Nee, het gaat hier om alle PDF's die moeten redirecten naar de desbetreffende pagina.

[Gomez12]

Khallouki schreef op dinsdag 05 januari 2016 @ 18:26:
[...]
Met local scripts bedoel ik echter 1 script. Het is een PHP bestand die de PDF wil ophalen om te embedden in de html pagina. Echter krijgt de PHP bestand niet de pdf als resultaat maar de geredirecte pagina.

Nee, het gaat hier om alle PDF's die moeten redirecten naar de desbetreffende pagina.

Ok, dus het is geen lokaal script, het is gewoon een client-side embedded document.

En ik zou je laatste zin nog eens goed doorlezen en mijn vorige bold stukje, want dat is een mogelijke oplossing. Jouw laatste zin dat heb je nu bereikt en dat betekent netto dat ook je embedded pdf's doorgestuurd worden (juist het effect wat je ziet en zegt niet te willen hebben)

[Pizzalucht]

Je zou in de htaccess een referer check kunnen doen, iets als:

code:

RewriteCond %{HTTP_REFERER} !^https:\/\/urlvandewebsite\.com\/pdf-reader\/\?src=.+\.pdf$
RewriteRule (.+\.pdf)$ https://urlvandewebsite.com/pdf-reader/?src=$1 [L]

Door de ! zeg je eigenlijk:
voer deze regel (dus de redirect) uit als de regex niet matched.

Dan zou hij dus niet moeten redirecten als je al op die pagina zit.
Let er wel op dat de referer een HTTP header is en dus te faken door clients.

[ Voor 16% gewijzigd door Pizzalucht op 05-01-2016 19:37 ]

[Creepy]

Khallouki schreef op dinsdag 05 januari 2016 @ 18:08:
[...]


Ik snap je advies niet helemaal. Doorgeefluik? Waar moet die komen te staan en hoe moet de htaccess weten dat hij dat niet moet redirecten?

Ik bedoel een PHP script die de PDF vanaf het filesysteem inleest en weer aan de browser doorgeeft. Je rewrite rule gaat dan niet af (want het eindigt niet op .pdf) en zo kan het wel worden gedownload.

[BlueZero]

Combinatie van header en readfile

PHP:

<?php
//Content type = pdf
header('Content-Type: application/pdf');

// We noemen hem preview.pdf en laten hem inline zien dus niet als attachment
header('Content-Disposition: inline; filename="preview.pdf"');

// En hier haal je het originele bestand op
readfile('original.pdf');
?>

Dan moet je alleen nog even uitvogelen hoe je hem op een andere pagina in een box etc wil laten zien.

[Verwijderd]

Het probleem is dat je plugin de pdf-bestanden ook weer opent via een URL en op die URL is dus ook je rewrite-rule van toepassing. Tenminste, dat is wat ik uit je OP begrijp. Je pdf-plugin zou die bestanden als lokale bestanden moeten openen.
Een mogelijke oplossing is een rewrite-condition op te nemen die weer een uitzondering vormt op jouw rewrite-rule, dus dat altijd naar jouw plugin wordt doorgeschakeld, behalve als de aanvraag afkomstig is van het IP-adres van jouw server. Iets in de trend van:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^xxx\.xxx\.xxx\.xxx
RewriteRule (.+\.pdf)$ https://urlvandewebsite.com/pdf-reader/?src=$1 [L]
</IfModule>

Op de plaats van de xxx-en vul je dan het IP-adres van je server in (A-name van je domeinnaam).
Mocht dat niet werken, dan kan het nog zijn dat je provider ergens een proxy heeft geïnstalleerd (doen ze vrijwel nooit meer) en je de IP-reeks van de proxy als uitzondering moet nemen.

Dit is vergelijkbaar met de oplossing van @Pizzalucht, al zal die oplossing meestal niet werken omdat jouw plug-in hoogstwaarschijnlijk de referer leeg zal laten (referer wordt doorgegeven door de client in de http-header van de aanvraag).

[Pizzalucht]

Verwijderd schreef op woensdag 06 januari 2016 @ 12:21:
Het probleem is dat je plugin de pdf-bestanden ook weer opent via een URL en op die URL is dus ook je rewrite-rule van toepassing. Tenminste, dat is wat ik uit je OP begrijp. Je pdf-plugin zou die bestanden als lokale bestanden moeten openen.
Een mogelijke oplossing is een rewrite-condition op te nemen die weer een uitzondering vormt op jouw rewrite-rule, dus dat altijd naar jouw plugin wordt doorgeschakeld, behalve als de aanvraag afkomstig is van het IP-adres van jouw server. Iets in de trend van:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^xxx\.xxx\.xxx\.xxx
RewriteRule (.+\.pdf)$ https://urlvandewebsite.com/pdf-reader/?src=$1 [L]
</IfModule>

Op de plaats van de xxx-en vul je dan het IP-adres van je server in (A-name van je domeinnaam).
Mocht dat niet werken, dan kan het nog zijn dat je provider ergens een proxy heeft geïnstalleerd (doen ze vrijwel nooit meer) en je de IP-reeks van de proxy als uitzondering moet nemen.

Dit is vergelijkbaar met de oplossing van @Pizzalucht, al zal die oplossing meestal niet werken omdat jouw plug-in hoogstwaarschijnlijk de referer leeg zal laten (referer wordt doorgegeven door de client in de http-header van de aanvraag).

Dat werkt alleen als de PDF reader een applicatie is die op de server draait.
Ik begrijp van de TS dat het een client side script is maar daar is hij niet helemaal duidelijk over.

[Verwijderd]

Pizzalucht schreef op woensdag 06 januari 2016 @ 13:22:
[...]
Dat werkt alleen als de PDF reader een applicatie is die op de server draait.
Ik begrijp van de TS dat het een client side script is maar daar is hij niet helemaal duidelijk over.

Wow, zo had ik het nog niet bekeken, maar dat zou inderdaad kunnen :-)
Ik denk zelf dat het server-sided is, want TS heeft het over 'local scripts', maar als het client-side is, dan heb je natuurlijk gelijk.
TS is inderdaad onduidelijk hierover, we weten de gehele URL niet van de redirect, ook het pakket wordt niet genoemd, noch of het een server- of een client-side plugin is.

Kort gezegd:
Is het server-sided: gebruik de %{REMOTE_ADDR} methode
Is het client-sided: gebruik de %{HTTP_REFERER} methode

Met natuurlijk de restrictie die jij ook al gaf: client-sided is zeer manipuleerbaar (maar wat dan nog, de client krijgt de PDF toch te zien, dus er valt weinig zinvols aan te hacken).

[emnich]

Referer is zoals gezegd zeer onbetrouwbaar, daar zou ik van weg blijven.

Als het gaat om iets server sided dan hoeft dat toch helemaal niet via de webserver te lopen maar kan je het gewoon op halen via het filesystem.

Ik snap persoonlijk niet waarom de PDF exact dezelfde naam (en pad) moet hebben als de url. Is het niet veel makkelijker om deze (iets) anders te maken? Dat lost direct alle problemen op.

[Verwijderd]

emnich schreef op woensdag 06 januari 2016 @ 14:02:
Referer is zoals gezegd zeer onbetrouwbaar, daar zou ik van weg blijven.
Als het gaat om iets server sided dan hoeft dat toch helemaal niet via de webserver te lopen maar kan je het gewoon op halen via het filesystem.
Ik snap persoonlijk niet waarom de PDF exact dezelfde naam (en pad) moet hebben als de url. Is het niet veel makkelijker om deze (iets) anders te maken? Dat lost direct alle problemen op.

Zoals ik de OP lees: TS heeft een server draaien en gebruikt Wordpress en 1-of-ander programma dat een PDF inleest en met extra informatie uit die PDF weergeeft naar de gebruiker. TS heeft wel wat verstand van zaken, maar is geen doorgewinterde programmeur die zelf scripts ontwikkelt. TS is wel handig genoeg te achterhalen waar het probleem ligt en probeert dat simpel op te lossen via rewrite-rules.
De antwoorden van mij en van @Pizzalucht zijn toegesneden op TS.
Het is maar de vraag of het script dat TS gebruikt voor het weergeven van de PDF met extra informatie wel lokaal bestanden kan openen en het is maar de vraag of TS de toegang heeft en de kennis dat te wijzigen.
De berg waar de één tegen oploopt is de steen waar een ander overheen stapt.

[emnich]

Verwijderd schreef op woensdag 06 januari 2016 @ 14:19:
[...]

Zoals ik de OP lees: TS heeft een server draaien en gebruikt Wordpress en 1-of-ander programma dat een PDF inleest en met extra informatie uit die PDF weergeeft naar de gebruiker. TS heeft wel wat verstand van zaken, maar is geen doorgewinterde programmeur die zelf scripts ontwikkelt. TS is wel handig genoeg te achterhalen waar het probleem ligt en probeert dat simpel op te lossen via rewrite-rules.
De antwoorden van mij en van @Pizzalucht zijn toegesneden op TS.
Het is maar de vraag of het script dat TS gebruikt voor het weergeven van de PDF met extra informatie wel lokaal bestanden kan openen en het is maar de vraag of TS de toegang heeft en de kennis dat te wijzigen.
De berg waar de één tegen oploopt is de steen waar een ander overheen stapt.

Maar jullie beider oplossing werk maar ten dele.

Concreet zou mijn oplossing zijn om de PDF op de server iets extra's mee te geven. Dus test123.pdf wordt opgeslagen als test123_saved.pdf.

In je htaccess maak je dan een rule als

code:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule (.+)\.pdf$ https://urlvandewebsite.com/pdf-reader/?src=$1_saved.pdf [L]

[Verwijderd]

emnich schreef op woensdag 06 januari 2016 @ 14:44:
[...]
Maar jullie beider oplossing werk maar ten dele.

Dat is maar de vraag. Volgens mij wil TS dat er met standaard software (Wordpress wordt gedraaid) de opmaak wordt gedaan, maar dat elke aanvraag naar een PDF wordt ge-reroute via een programma dat die PDF weergeeft met extra informatie.

Concreet zou mijn oplossing zijn om de PDF op de server iets extra's mee te geven. Dus test123.pdf wordt opgeslagen als test123_saved.pdf.

Dat zou betekenen dat je ook elke PDF een aparte bestandsnaam moet geven en je die met standaard software niet meer kunt linken, omdat je niet direct wilt linken.
Jouw idee werkt wel als jij de enige bent die de inhoud bewerkt, maar bij bedrijven heb je vaak meer mensen die de opmaak doen en bestanden toevoegen en die geen idee hebben van allerlei technische zaken.
Volgens mij wil TS gewoon alles dat PDF is rerouten via dat scriptje, zonder een 2 weken durende cursus te geven aan personeel dat die PDF-jes toevoegt aan het systeem en via het onderhoudssysteem van Wordpress linkt.

Veel beter zou zijn alle PDF's buiten de openbare mappen te zetten, zodat ze sowieso niet meer direct benaderbaar zijn en dan een gateway te maken via een software-pakket dat die bestanden lokaal opent. Maar dat valt volgens mij volledig buiten de scope van wat TS wil bereiken.

Zie hier het aloude probleem: techneuten kunnen echt fantastische en zwaarbeveiligde systemen maken, maar is het dan nog wel werkbaar voor de rest van het personeel?

[emnich]

Verwijderd schreef op woensdag 06 januari 2016 @ 15:12:
[...]

Dat is maar de vraag. Volgens mij wil TS dat er met standaard software (Wordpress wordt gedraaid) de opmaak wordt gedaan, maar dat elke aanvraag naar een PDF wordt ge-reroute via een programma dat die PDF weergeeft met extra informatie.


[...]

Dat zou betekenen dat je ook elke PDF een aparte bestandsnaam moet geven en je die met standaard software niet meer kunt linken, omdat je niet direct wilt linken.
Jouw idee werkt wel als jij de enige bent die de inhoud bewerkt, maar bij bedrijven heb je vaak meer mensen die de opmaak doen en bestanden toevoegen en die geen idee hebben van allerlei technische zaken.
Volgens mij wil TS gewoon alles dat PDF is rerouten via dat scriptje, zonder een 2 weken durende cursus te geven aan personeel dat die PDF-jes toevoegt aan het systeem en via het onderhoudssysteem van Wordpress linkt.

Ook dat valt allemaal wel mee en kan je met 1-2 regels PHP wel oplossen. Hij toont nu al informatie van de PDF op die pagina dus kan makkelijk de filename manipuleren. Afhankelijk van de plugin kan het ook nog met 1-2 regels javascript.


Mijn probleem met de andere oplossing is dat het niet voor 100% werkt en je (imho) niet iets moet gaan toepassen wat niet 100% werkt.

[Verwijderd]

emnich schreef op woensdag 06 januari 2016 @ 16:15:
Mijn probleem met de andere oplossing is dat het niet voor 100% werkt en je (imho) niet iets moet gaan toepassen wat niet 100% werkt.

Server-sided werkt wel voor 100% en vergt geen enkele aanpassing aan de software. Client-sided werkt grotendeels en vergt ook geen enkele aanpassing aan de software. Je moet het doel (liever een PDF weergeven via de plugin zodat er extra informatie verschijnt) nastreven.
Als het doel is: de PDF's mogen onder geen beding direct worden geopend, dan moet je de PDF's buiten je openbare hosting zetten en laten serveren door een script dat ze lokaal leest. Daarvoor is jouw oplossing ook niet toereikend. Ik denk niet dat dat het doel is, aangezien de PDF's toch wel worden getoond (en dus geen geheime informatie bevatten die er door de plugin wordt uitgefilterd).
Jouw oplossing brengt meer problemen met zich mee dan dat het iets oplost.
Ik ga uit van wat TS in de OP stelt en als TS toch iets anders wil bereiken, of ik het verkeerd heb begrepen, dan horen we dat wel.

P.S. ik kan me de reactie van @Pizzalucht levendig voorstellen en misschien blijkt zijn interpretatie ook nog eens correct. Daarvoor heeft TS te weinig gegevens gegeven. Ik kan een heel relaas afsteken over het verschil tussen een plug-in en een include. Ik denk zelf dat we in dit geval met geen van beiden te maken hebben, ik denk dat TS een parser bedoelt.

[ Voor 13% gewijzigd door Verwijderd op 06-01-2016 18:39 ]

[pedorus]

Ik zie dat het woord cookie niet voorkomt in dit topic. Maar ik zou dit zelf net zo implementeren als een soort cookie-wall. Als je bij het pdf-bestand niet het juiste cookie ziet (of een indexatie-robot identificeert) dan redirect je naar de informatiepagina. Indien wel, dan geef je het bestand terug. Het cookie hoeft maar korte tijd geldig te zijn.

Voorbeeldje met rewrite-rules:

quote: https://github.com/RvMouche/CookieWall

RewriteCond %{HTTP_COOKIE} !kiwicookie=kiwicookieVal [NC]
RewriteCond %{HTTP_USER_AGENT} !AltaVista
RewriteCond %{HTTP_USER_AGENT} !Googlebot
RewriteCond %{HTTP_USER_AGENT} !msnbot
RewriteCond %{HTTP_USER_AGENT} !Slurp

Wat ik ook wel zie, is dat pdfs een eerste bonuspagina krijgen, met daarop de informatie. Dan zit de informatie dus in het bestand zelf.

[Verwijderd]

pedorus schreef op donderdag 07 januari 2016 @ 09:30:
Ik zie dat het woord cookie niet voorkomt in dit topic.

Met een cookie gaat het mis als je direct (bijv. via een link in google) het pdf-bestand opvraagt.
Dan is dat cookie er immers nog niet.

[DJMaze]

Het probleem is je php file reader, die moet niet een http request doen.

[pedorus]

Verwijderd schreef op donderdag 07 januari 2016 @ 12:24:
[...]

Met een cookie gaat het mis als je direct (bijv. via een link in google) het pdf-bestand opvraagt.
Dan is dat cookie er immers nog niet.

Die situatie gaat juist goed, want dan redirect je naar de informatiepagina. En bij het laden van die informatiepagina zet je het cookie voordat je de preview inlaad, met een levensduur van 5 minuten ofzo. Het downloaden van de JDK bevat bijvoorbeeld zo'n check. Het gaat pas mis als bijvoorbeeld cookies geblokt worden, of je verwacht op de overzichtspagina te komen als het cookie is gezet. Cookies worden enkel minder vaak geblokkeerd dan Referers, sommige proxies/programma's blokkeren de laatste.

Edit: Bedenk me nog dat je liever niet op de locale klok wil vertrouwen. Liefst doe je dus een cookie als last-timestamp-infopage-for-download-xxxxx=timestamp server met een vervaldatum ver in de toekomst, of zet je het cookie in javascript. In het laatste geval kun je het af met rewriterules en een stukje javascript.

[ Voor 17% gewijzigd door pedorus op 08-01-2016 13:13 ]

[Khallouki]

Pizzalucht schreef op dinsdag 05 januari 2016 @ 19:10:
Je zou in de htaccess een referer check kunnen doen, iets als:

code:

RewriteCond %{HTTP_REFERER} !^https:\/\/urlvandewebsite\.com\/pdf-reader\/\?src=.+\.pdf$
RewriteRule (.+\.pdf)$ https://urlvandewebsite.com/pdf-reader/?src=$1 [L]

Door de ! zeg je eigenlijk:
voer deze regel (dus de redirect) uit als de regex niet matched.

Dan zou hij dus niet moeten redirecten als je al op die pagina zit.
Let er wel op dat de referer een HTTP header is en dus te faken door clients.

Heel erg bedankt. Ik heb dit geprobeerd maar hij deed het niet. Probleem was dat ik de referrer niet goed had gezet.

Het is inderdaad een client side script (javascript) dat een GET request doet naar de server om de PDF op te halen. De referrer stond echter op het javascript bestand (volledige url van de .js file) en niet op de huidige pagina.

Nadat ik dat heb gewijzigd doet alles het weer.