Posts by AarClay

    Ik ben er ook niet echt kapot van. Het is een beetje dubbelop nu, je hebt recente activiteiten en daaronder nog eens de laatste topics. Van mij hoeft dat niet, alleen nieuws wat door het team van ICTS wordt geplaatst zou hier moeten staan. Maar dat is mijn mening, misschien zijn er anderen die het wel fijn vinden.


    Hoezo is dat opmerkelijk?We zitten hier op ICT scripters, dan denk ik bij mezelf dat merendeel hier developer is of iets in die branche.

    Hij heeft een crew-tagje met Developer...
    Kijk maar eens goed, of zijn die tagjes door iedereen te bedenken soms? :?

    Een slechte zet, dat we onnodige topics integraal door onze str*t krijgen gedrukt! Als iemand op de 'frontpage' komt wil hij nieuws lezen, en geen meuk zoals domeinnamen of wat dan ook.


    Opmerkelijke is zelfs dat een site-developer hierboven aangeeft dat het ook ruk is? Eh......

    Ik zou het wel handig vinden, zodat je bijvoorbeeld in de trein of het vliegtuig je favoriete film kan kijken, zonder haperingen van brakke WiFi verbindingen. of ik er wil voor betalen ligt aan de prijs. Maar wat mij betreft mogen ze het bij het duurste abbonement inclusief doen.

    Ik weet niet tot hoever je kennis rijkt, maar ik heb een vermoeden dat je beginner bent. In dat geval lijkt het mij zinvoller om naar simpele scripts te kijken, zoals ik opgenoemd heb.


    Het genoemde script is niet echt zo simpel, en je moet weten hoe classes werken, en hoe je er mee om moet gaan.

    Los van de juridische kwesties....


    Maar of het decoden goed werkt, is de vraag. Vaak werken die decoders via op reverse-enigineer basis, wat soms vreemde code oplevert.


    Maar decoden is niet de bedoeling. Ik neem aan dat zulke dingen ook vaak in de voorwaarden genoemd zijn.

    Maar alle HTML en (clientside) JavaScript code die de browser ontvangt is toch niet geëncodeerd? Als dat niet het geval is zou dat inhouden dat een browser speciale voorzieningen zou moeten hebben om met dat soort bestanden om te gaan?

    Tenzij het JavaScript gedeelte door PHP wordt outgeput. Dan is het lastig aanpassen.
    Maar je kan altijd slim zijn, en de DOM manipuleren ;)


    Maar het blijft verder gewoon een lame beveiliging.

    Dat is dan wel behoorlijk matig gedaan, lees 'prutswerk'. Elke developer weet dat er achter de rechtermuisknop andere handige dingen zitten, en dat je met dergelijke beveiligingen menig browser invalide maakt.

    Zit het niet gewoon in een javascript bestand?


    En ja, rechtermuisblokkades zijn echt de crime van het internet. Als iemand op zijn credits wilt hameren, zet het dan onderin de site neer, en encoded het dan gewoon.

    Het is wel een ander probleem, maar een extra veiligheidslaag kan zeker geen kwaad. Wat dacht je van een zero-day exploit in een CMS waar je niet zelf aan de code wilt sleutelen?


    Het klinkt overdreven, maar cronjobs behoor je alleen maar als CLI uit te kunnen voeren, in mijn ogen, of via een whitle-listed IP voor ontwikkeldoeleinden.

    Thomas, zulke controles kunnen zelfs juist handig zijn. Want wat als iemand door een 'remote file inclusion' de cronjob kan aanspreken die buiten de webroot staat? Met en check of deze via de CLI wordt uitgevoerd ben je er zeker van dat niemand hem via de browser uitvoert.

    Een CLI-check kan zeker geen kwaad voor de zekerheid ;)


    PHP
    <?php
    if(php_sapi_name() === 'cli') {
    // CLI
    } else {
    // mag niet met een browser benaderen, foei!
    }
    ?>

    Volgens mij kan je ook prima controleren of het script via de CLI wordt aangeroepen. Dan zit je ook erg safe.


    Maar het script buiten de webroot plaatsten, is het beste. Alleen zijn er soms nog webhosting-bedrijven die dat niet toestaan.