Kleine Vragen Topic #4

Sevvlor schreef:

@Lennard @Aarclay https://images.weserv.nl probleem opgelost ik doe dat ook

Kan ook, maar soms wil je iets echt in eigen hand hebben, i.p.v. third-parties. Stel je voor dat zij een DDOS krijgen, dan werken je images niet meer.

Aarclay schreef:

Eerdere citaten tonen

Sevvlor schreef:

@Lennard @Aarclay https://images.weserv.nl probleem opgelost ik doe dat ook

Kan ook, maar soms wil je iets echt in eigen hand hebben, i.p.v. third-parties. Stel je voor dat zij een DDOS krijgen, dan werken je images niet meer.

Ik heb dat nooit gehad. Daarnaast zijn de images cached bij CloudFlare dus blijven de plaatjes wel zichtbaar.

Dan alsnog voelt een eigen gehoste proxy vaak wat veiliger. .
Als het moet dan kies ik voor Camo, als ik met rewriterules teveel gedoe heb. En bovendien, heb je weer een uitdaging

Sevvlor schreef:

Eerdere citaten tonen

Aarclay schreef:

Eerdere citaten tonen

Sevvlor schreef:

@Lennard @Aarclay https://images.weserv.nl probleem opgelost ik doe dat ook

Kan ook, maar soms wil je iets echt in eigen hand hebben, i.p.v. third-parties. Stel je voor dat zij een DDOS krijgen, dan werken je images niet meer.

Ik heb dat nooit gehad. Daarnaast zijn de images cached bij CloudFlare dus blijven de plaatjes wel zichtbaar.

Je stuurt daarmee wel alle images die je bezoekers plaatsen door naar een jou onbekende partij. Nu is dat normaliter niet zo erg, maar als ik een screenshot met gevoelige informatie naar iemand PM dan wil ik niet dat die screenshot zonder mijn medeweten zomaar bij iemand terecht komt. Nu is dat in zekere mate al zo doordat de camo-requests ook via CloudFlare gaan, maar dat vind ik wel weer genoeg derde partijen. Een camo heb je zo opgezet, dus dat geniet dan mijns inziens de voorkeur boven een onbekende derde partij waar je 0 invloed hebt op je content.
Bovendien kan weserv.nl dan zien dat jij one2xs gebruikt, in welke mate je dat doet en welke paginas je allemaal bekijkt. Met een camo is dat niet het geval.

@Lennard , maar gebruik jij een kant en klare URL-parser voor Camo? Of heb je die zelf gebouwd ?

Aarclay schreef:

@Lennard , maar gebruik jij een kant en klare URL-parser voor Camo? Of heb je die zelf gebouwd ?
Ik had de UBB parser al die dus alle images binnenkrijgt die in een post voorkomen, die checkt of een image vanaf https komt en zo niet maakt ie er een camo-linkje van:

[COLOR= #0000BB]<?php[/COLOR]
[URL="http://www.php.net/if"]if[/URL][COLOR= #007700]([/COLOR][URL="http://www.php.net/substr"]substr[/URL][COLOR= #007700]([/COLOR][COLOR= #0000BB]$imgUrl[/COLOR][COLOR= #007700],[/COLOR] [COLOR= #0000BB]0[/COLOR][COLOR= #007700],[/COLOR] [COLOR= #0000BB]8[/COLOR][COLOR= #007700]) !=[/COLOR] [COLOR= #DD0000]https://[/COLOR][COLOR= #007700])[/COLOR]
    [COLOR= #0000BB]$imgUrl[/COLOR] [COLOR= #007700]= new[/COLOR] Camo[COLOR= #007700]([/COLOR][COLOR= #0000BB]$imgUrl[/COLOR][COLOR= #007700]);[/COLOR]

Die Camo class komt van https://github.com/atmos/camo/wiki/Generating-Signed-Image-URLs

Lennard schreef:

Eerdere citaten tonen

Sevvlor schreef:

Eerdere citaten tonen

Aarclay schreef:

Eerdere citaten tonen

Sevvlor schreef:

@Lennard @Aarclay https://images.weserv.nl probleem opgelost ik doe dat ook

Kan ook, maar soms wil je iets echt in eigen hand hebben, i.p.v. third-parties. Stel je voor dat zij een DDOS krijgen, dan werken je images niet meer.

Ik heb dat nooit gehad. Daarnaast zijn de images cached bij CloudFlare dus blijven de plaatjes wel zichtbaar.

Je stuurt daarmee wel alle images die je bezoekers plaatsen door naar een jou onbekende partij. Nu is dat normaliter niet zo erg, maar als ik een screenshot met gevoelige informatie naar iemand PM dan wil ik niet dat die screenshot zonder mijn medeweten zomaar bij iemand terecht komt. Nu is dat in zekere mate al zo doordat de camo-requests ook via CloudFlare gaan, maar dat vind ik wel weer genoeg derde partijen. Een camo heb je zo opgezet, dus dat geniet dan mijns inziens de voorkeur boven een onbekende derde partij waar je 0 invloed hebt op je content.
Bovendien kan weserv.nl dan zien dat jij one2xs gebruikt, in welke mate je dat doet en welke paginas je allemaal bekijkt. Met een camo is dat niet het geval.

Ja. het hangt af van de (systeem) eisen die je hebt. Mijnsinziens was dit voor mij wel een viable optie

Lennard schreef:

Eerdere citaten tonen

Aarclay schreef:

@Lennard , maar gebruik jij een kant en klare URL-parser voor Camo? Of heb je die zelf gebouwd ?

Ik had de UBB parser al die dus alle images binnenkrijgt die in een post voorkomen, die checkt of een image vanaf https komt en zo niet maakt ie er een camo-linkje van:

[COLOR= #0000BB]<?php[/COLOR]
[URL="http://www.php.net/if"]if[/URL][COLOR= #007700]([/COLOR][URL="http://www.php.net/substr"]substr[/URL][COLOR= #007700]([/COLOR][COLOR= #0000BB]$imgUrl[/COLOR][COLOR= #007700],[/COLOR] [COLOR= #0000BB]0[/COLOR][COLOR= #007700],[/COLOR] [COLOR= #0000BB]8[/COLOR][COLOR= #007700]) !=[/COLOR] [COLOR= #DD0000]https://[/COLOR][COLOR= #007700])[/COLOR]
    [COLOR= #0000BB]$imgUrl[/COLOR] [COLOR= #007700]= new[/COLOR] Camo[COLOR= #007700]([/COLOR][COLOR= #0000BB]$imgUrl[/COLOR][COLOR= #007700]);[/COLOR]

Die Camo class komt van https://github.com/atmos/camo/wiki/Generating-Signed-Image-URLs

Inderdaad behoorlijk poep-simpel dat hashen

Aarclay schreef:

Eerdere citaten tonen

Lennard schreef:

Eerdere citaten tonen

Aarclay schreef:

@Lennard , maar gebruik jij een kant en klare URL-parser voor Camo? Of heb je die zelf gebouwd ?

Ik had de UBB parser al die dus alle images binnenkrijgt die in een post voorkomen, die checkt of een image vanaf https komt en zo niet maakt ie er een camo-linkje van:

[COLOR= #0000BB]<?php[/COLOR]
[URL="http://www.php.net/if"]if[/URL][COLOR= #007700]([/COLOR][URL="http://www.php.net/substr"]substr[/URL][COLOR= #007700]([/COLOR][COLOR= #0000BB]$imgUrl[/COLOR][COLOR= #007700],[/COLOR] [COLOR= #0000BB]0[/COLOR][COLOR= #007700],[/COLOR] [COLOR= #0000BB]8[/COLOR][COLOR= #007700]) !=[/COLOR] [COLOR= #DD0000]https://[/COLOR][COLOR= #007700])[/COLOR]
    [COLOR= #0000BB]$imgUrl[/COLOR] [COLOR= #007700]= new[/COLOR] Camo[COLOR= #007700]([/COLOR][COLOR= #0000BB]$imgUrl[/COLOR][COLOR= #007700]);[/COLOR]

Die Camo class komt van https://github.com/atmos/camo/wiki/Generating-Signed-Image-URLs

Inderdaad behoorlijk poep-simpel dat hashen

Inderdaad. Like i said; het is eenvoudiger dan je denkt, het opzetten van zon camo.

Alleen even in Nginx even prutten met de hosts en SSL. Maar met Letsencrypt is dat ook zo gedaan. Dan alles doorsturen naar camo op poortje zoveel.

toevoeging op vrijdag 11 november 2016, 1957:
Dan is eigenlijk alleen nog de vraag, en die weet @Lennard vast wel, hoe je Camo het beste kan installeren?

In screen:

> coffee -c server.coffee
> /usr/bin/env PORT=9090 CAMO_KEY="T0P_S3CR3T" node server.js

En uiteraard nog even node.js eerst erop zetten? Right toch?
Update: Ik heb de bende draaiend. Zelfs met nieuwste node.js. Terwijl ze de oude aanraden .

Ik ben een complete noob tot de PHP frameworks dus ik ben me gaan verdiepen in CodeIgniter (volgens Google het makkelijkst om mee te beginnen).
Ik ben dus even lekker de documentatie aan het lezen.
Hierin staat:

Quote:
For the best security, both the system and any application folders should be placed above web root so that they are not directly accessible via a browser. By default, .htaccess files are included in each folder to help prevent direct access, but it is best to remove them from public access entirely in case the web server configuration changes or doesn"™t abide by the .htaccess.

Maar hoe moet je dat dan doen? Ik heb geen flauw idee hoe je applications folder nog boven je web root moet plaatsen

Stef schreef:

Ik ben een complete noob tot de PHP frameworks dus ik ben me gaan verdiepen in CodeIgniter (volgens Google het makkelijkst om mee te beginnen).
Ik ben dus even lekker de documentatie aan het lezen.
Hierin staat:

Quote:
For the best security, both the system and any application folders should be placed above web root so that they are not directly accessible via a browser. By default, .htaccess files are included in each folder to help prevent direct access, but it is best to remove them from public access entirely in case the web server configuration changes or doesn"™t abide by the .htaccess.

Maar hoe moet je dat dan doen? Ik heb geen flauw idee hoe je applications folder nog boven je web root moet plaatsen
Nou, stel je de volgende structuur voor:
domainsexample.com
domainsexample.compublic_html

De bovenste is root, de onderste is waar mensen bij kunnen als ze naar example.com zouden gaan. Wat je dus wil doen is alle applicatie files (het framework, je MVC classes e.d.) in de root plaatsen, en zorgen dat je een index.php file o.i.d. hebt in je public_html die het framework in je root kan inladen.

Ik hoop dat het bij je hosting kan, bij de meeste kan je hoger op komen in boven de public_html (vooral als ze DirectAdmin, en dus ook bij One2XS draaien). En als het niet kan, dan kan je het gewoon in de webroot zetten met een leuke .htaccess erin, waarin je de inhoud van de hele directory beschermt. PHP kan er via het file-system toch wel bij komen.

Nog even terugkomend op het verhaal van @Lennard en @aarklay over de cameo... Fair point dat een derde nu kan zien wie welke website gebruikt. Ik ga daar ook maar eens veranderingen in aanbrengen

Sevvlor schreef:

Nog even terugkomend op het verhaal van @Lennard en @aarklay over de cameo... Fair point dat een derde nu kan zien wie welke website gebruikt. Ik ga daar ook maar eens veranderingen in aanbrengen Tof, het staat ook gewoon leuker.

Aarclay schreef:

Update: Ik heb de bende draaiend. Zelfs met nieuwste node.js. Terwijl ze de oude aanraden .

Viel mee hé?