Doet dat er toe om welke reden ik het gebruik?quote:Op vrijdag 19 maart 2010 14:27 schreef Scorpie het volgende:
Waarom zou je je broncode willen beschermen, als je gewoon het auteursrecht ervoor hebt?
Is het geen mogelijkheid om het framework op je eigen server te hosten ofzo?quote:Op vrijdag 19 maart 2010 14:49 schreef ursel het volgende:
[..]
Zoals ik al zei bij het voorbeeld. De mogelijkheid is er dat ik een site verkoop inclusief een framework. Maar ik wil voorkomen dat iemand dat framework voor al zijn sites gaat gebruiken.
Applicatie in .NET/C# schrijven?quote:Op vrijdag 19 maart 2010 14:49 schreef ursel het volgende:
[..]
Doet dat er toe om welke reden ik het gebruik?
Zoals ik al zei bij het voorbeeld. De mogelijkheid is er dat ik een site verkoop inclusief een framework. Maar ik wil voorkomen dat iemand dat framework voor al zijn sites gaat gebruiken.
Eeuh, is een optie, maar wil verder niet verantwoordelijk zijn voor de site, en op deze manier hou ik wel de verantwoordelijkheid als mijn server er uit valt.quote:Op vrijdag 19 maart 2010 14:50 schreef Tijn het volgende:
[..]
Is het geen mogelijkheid om het framework op je eigen server te hosten ofzo?
Euh... gewoon geen documentatie meeleveren voor je framework?quote:Op vrijdag 19 maart 2010 14:58 schreef ursel het volgende:
[..]
Ik wil gewoon een site kunnen exporteren naar iemand anders toe, maar puur alleen deze site in de huidige staat. Maar wel voorkomen dat hij hiermee een stapel sites kan bouwen op mijn broncode.
Dan is het het effectiefst als je idd zelf het framework host. Alle andere oplossingen zijn minder goed.quote:Op vrijdag 19 maart 2010 14:58 schreef ursel het volgende:
[..]
Eeuh, is een optie, maar wil verder niet verantwoordelijk zijn voor de site, en op deze manier hou ik wel de verantwoordelijkheid als mijn server er uit valt.
Ik wil gewoon een site kunnen exporteren naar iemand anders toe, maar puur alleen deze site in de huidige staat. Maar wel voorkomen dat hij hiermee een stapel sites kan bouwen op mijn broncode.
Effectiefst wel ja qua bescherming, maar laten we even gemakshalve uitsluiten dat ik deze optie niet wil gebruiken.quote:Op vrijdag 19 maart 2010 15:01 schreef Scorpie het volgende:
[..]
Dan is het het effectiefst als je idd zelf het framework host. Alle andere oplossingen zijn minder goed.
Deze is goedkoper.quote:Op vrijdag 19 maart 2010 15:06 schreef ursel het volgende:
[..]
Laten we even terug gaan naar de kern van de vraag. Zijn er goedkopere software pakketten dan Zend Guard of IonCube?
Niet zozeer stuk, de initiële vraag was ook vooral of iemand anders iets gebruikt en in zijn kofferbak had liggen en ik zodoende niet het wiel hoef te vinden.quote:Op vrijdag 19 maart 2010 15:11 schreef Tijn het volgende:
[..]
Deze is goedkoper.
Je hebt ook bcompiler, dat is gratis.
Is je Google stuk?
quote:
Of je geeft die $100 aan mij en gaat naar bcompiler kijkenquote:Op vrijdag 19 maart 2010 15:31 schreef ursel het volgende:
Sourceguardian klinkt idd wel goed. Ga ik ff naar kijken.
Ik zie een verschil tussen ob_flush en ob_end_flushquote:Op vrijdag 19 maart 2010 14:33 schreef Light het volgende:
[..]
Volgens mij is dat precies was Intrepidity ook schreef, behalve dan dat hij geen short open tags gebruikte. <?php werkt op iedere php-host, maar of <? ook werkt is niet te garanderen. Dat is namelijk afhankelijk van een configuratie-instelling. Het is beter daar niet op te vertrouwen.
Owja. Niet dat dat een spannend verschil is, beide functies bestaan en beide gooien de inhoud van de buffer naar de browser. Enige verschil is dat ob_end_flush() ook de buffering uitzet, terwijl na ob_flush() de buffer nog wel bestaat maar leeg is.quote:Op zaterdag 20 maart 2010 11:02 schreef Xcalibur het volgende:
[..]
Ik zie een verschil tussen ob_flush en ob_end_flush
Edit: ik mis effe de laatste pagina
Denk het niet :p, maar de IT afdeling kan er wel om lachenquote:Op zaterdag 20 maart 2010 14:17 schreef Intrepidity het volgende:
Zeg, zou SQL injectie bij flitspalen ook werken?
[ afbeelding ]
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | if ( $_SERVER['HTTP_X_FORWARDED_FOR'] || $_SERVER['HTTP_X_FORWARDED'] || $_SERVER['HTTP_FORWARDED_FOR'] || $_SERVER['HTTP_CLIENT_IP'] || $_SERVER['HTTP_VIA'] ) { print "No proxies pls!"; exit(); } else{ print "OK"; } ?> |
Niet zo heel veel ervaringen met grote databases maar je wil geen database lock hebben dus suggereer ik alvast InnoDB aan ipv MyISam. Omdat MyISam de hele tabel lockt als er een wijziging gaande is en InnoDB alleen de regel. dat is alvast mijn adviesquote:Op dinsdag 23 maart 2010 10:48 schreef Chandler het volgende:
Aanpassingen zullen niet zoveel gebeuren, uitlezen destemeer.
Een schatting is dat er minimaal 100-150 instellingen per gebruiker in te voeren zijn, en natuurlijk uit te lezen. Er zou met gemak 10.000 gebruikers gebruik moeten kunnen maken van deze tabel.. indien dat mogelijk zou kunnen zijn.
dus 150*10.000 = 1500000 records.
1 2 3 4 5 6 7 | <body> <form name="input" action="voegtoe.php" method="get"> Nummer:<input type="integer" name="nummer" /><br /> <input type="submit" value="Invoeren"> </body> </html> |
1 2 3 4 5 6 7 8 9 | if ($_GET["nummer"]=null || $_GET["nummer"]<'1') { die('Onjuiste waarde ingevuld'); } echo $_GET["nummer"] . " is ingevoerd."; ?> |
1 |
moet ik er dan later een integer van maken om de checks te doen?quote:Op dinsdag 23 maart 2010 12:07 schreef Scorpie het volgende:
<input type="integer" name="nummer" />
moet zijn:
<input type="text" name="nummer" />
Duidelijk. Dan is het ineens weer zo simpel ...quote:Op dinsdag 23 maart 2010 12:11 schreef SinofEnvy het volgende:
En checks doe je altijd met "==", niet met "=". Dat is waardes toewijzen aan een variabele.
Nu kijkt hij dus of hij $_GET['nummer'] op NULL kan zetten OF dat hij kleiner is dan 1. Aangezien hij hem (volgens mij?) op NULL kan zetten, zal hij niet die'en, maar $_GET['nummer'] is nu NULL en toont ie niets.
Edit: Ter verduidelijking, de if statement moet dus zijn:
[ code verwijderd ]
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | $a = rand(1,9); $b = rand(1,9); $c= $a+$b; echo "<input type='hidden' name='calculation' value='".$c."' />"; echo $a." + ".$b."= <input type='text' name='userinput' value='' size='2' />"; //waar het ook heen gaat de als waarde bouwen if($_POST['calculation'] == $_POST['userinput']) { //........CORRECTE waarde }else{ echo "ERROR, you must be bot!" } ?> |
Je hebt zeker eerder geprogrammeerd? Je hoeft in PHP geen verschil aan te duiden tussen data typen. Een variabele is een variabele. PHP bepaalt zelf wel wat het is.quote:Op dinsdag 23 maart 2010 12:25 schreef Joooo-pi het volgende:
Ik heb SinofEnvy zijn opmerking toegepast en het werkt al
Integer mag dus wel als input type? (opmerking Scorpie)
Waarschijnlijk kom ik nog (vaak) terug hiero ... In ieder geval bedankt.
Ja. vars die van een form afkomen zijn per definitie String`squote:Op dinsdag 23 maart 2010 12:18 schreef Joooo-pi het volgende:
[..]
moet ik er dan later een integer van maken om de checks te doen?
Wat is dat? Gaat dit erom om je te beschermen tegen bots? Ik ben nog maar wat aan het proberen, maar als ik het een beetje onder de knie krijg, dan wil ik iets maken voor intern gebruik, dus daar maak ik me nu niet zo druk om.quote:Op dinsdag 23 maart 2010 12:34 schreef SinofEnvy het volgende:
[..]
Ik zou trouwens user input nooit vertrouwen, het is dus altijd aangeraden om ff een htmlspecialchars() en/of addslashes() toe te voegen aan de userinput tegen SQL injectie / remote file inclusion / etc.
Mja, in PHP gaat dat automagisch. In Java bijvoorbeeld moet je hem wel weer casten naar een integer Haal die dingen wel eens door elkaarquote:Op dinsdag 23 maart 2010 13:11 schreef SinofEnvy het volgende:
Uh, wat? Nee, hij hoeft er geen integer van te maken.
Op het moment dat hij een aritmetische operatie uitvoert op z'n $_POST['bla'] vartje, werkt dat gewoon. Hij hoeft er in principe niets mee te doen behalve wat hij erop wilt uitvoeren.
Een ctype_digit() aanroep kan nog wel eens handig wezen om te valideren of de invoer inderdaad numeriek is, maar voor de rest maakt het inderdaad niets uit.quote:Op dinsdag 23 maart 2010 13:11 schreef SinofEnvy het volgende:
Uh, wat? Nee, hij hoeft er geen integer van te maken.
Op het moment dat hij een aritmetische operatie uitvoert op z'n $_POST['bla'] vartje, werkt dat gewoon. Hij hoeft er in principe niets mee te doen behalve wat hij erop wilt uitvoeren.
quote:Op dinsdag 23 maart 2010 13:11 schreef SinofEnvy het volgende:
Uh, wat? Nee, hij hoeft er geen integer van te maken.
Als je user input niet vertrouwt, moet je er ook niet zomaar mee gaan werken. Dan is het wel handig om op de een of andere manier te controleren of het voldoet aan je verwachtingen. Dat kan met een cast.quote:Op dinsdag 23 maart 2010 12:34 schreef SinofEnvy het volgende:
Ik zou trouwens user input nooit vertrouwen
Van een string naar integer casten geeft vaak onbetrouwbare resultaten. Stel dat je wilt contoleren of de invoer van je veld gelijk is aan het getal 0.quote:Op dinsdag 23 maart 2010 14:17 schreef Light het volgende:
[..]
[..]
Als je user input niet vertrouwt, moet je er ook niet zomaar mee gaan werken. Dan is het wel handig om op de een of andere manier te controleren of het voldoet aan je verwachtingen. Dat kan met een cast.
Wat Intrepidity zegt. In PHP is het kloten met datatypen sowieso niet echt nuttig of interessant dunkt me, tenslotte is deel van de simplicity en misschien wel kracht van de taal dat dit niet hoeft. Voor security zou ik persoonlijk niet terugvallen op casten naar een integer, maar goed.quote:Op dinsdag 23 maart 2010 14:17 schreef Light het volgende:
[..]
[..]
Als je user input niet vertrouwt, moet je er ook niet zomaar mee gaan werken. Dan is het wel handig om op de een of andere manier te controleren of het voldoet aan je verwachtingen. Dat kan met een cast.
Niet tegen bots, met name tegen beveiligingslekken. Die functies veranderen HTML characters zoals < in hun respectievelijke codes (< wordt dus <) en addslashes voegt trailing slashes toe aan quote tekens. Dat maakt dus van "dit", \"dit\". Om niet al teveel in detail te treden (dat komt later nog wel, kan je wel precies gaan uitleggen hoe het zit maar gezien het niveau van de vragen die je stelt denk ik dat dat op dit moment misschien iets buiten de scope is van het antwoord ), dat is voor beveiliging.quote:Wat is dat? Gaat dit erom om je te beschermen tegen bots? Ik ben nog maar wat aan het proberen, maar als ik het een beetje onder de knie krijg, dan wil ik iets maken voor intern gebruik, dus daar maak ik me nu niet zo druk om.
Nee, denk het niet, tenzij je de file kunt achterhalen waar de SL-site zelf naar post.quote:Op dinsdag 23 maart 2010 22:53 schreef commentator het volgende:
Nu heb ik een site die informatie kan posten naar een andere website en zo automatisch kan inloggen.
De andere website is bezig met te vernieuwen en de nieuwe site wordt een silverlight site en daar kan ik dus niet naar posten.
Is er een manier om toch login gegevens op de een of andere manier naar die silverlight te kunnen krijgen?
Ik kan alleen aan de eigen site (PHP) wat doen. Die andere site met Silvelight kan ik niets aan veranderen.
In Javascript:quote:Op dinsdag 23 maart 2010 23:06 schreef boem-dikkie het volgende:
Géén idee of dit het topic is om het te vragen maar ik ben een website aan het maken die op de iPhone automatisch net als FOK! ( m.fok.nl ) de resolutie van de mobiele telefoon aanneemt. Iemand enig idee?
1 2 | screen.height; // voorbeeld: 768 |
Als je met pure PHP wilt gaan werken kun je denk ik het beste een lijst van mobiele user-agents bijhouden en deze uitlezen uit $_SERVER["HTTP_USER_AGENT"]quote:Op dinsdag 23 maart 2010 23:06 schreef boem-dikkie het volgende:
Géén idee of dit het topic is om het te vragen maar ik ben een website aan het maken die op de iPhone automatisch net als FOK! ( m.fok.nl ) de resolutie van de mobiele telefoon aanneemt. Iemand enig idee?
Je PHP-controleblok helemaal bovenaan zetten, of output-buffering aanzetten. Zie een van de voorgaande pagina's, daar had iemand hetzelfde probleemquote:Op woensdag 24 maart 2010 12:54 schreef boem-dikkie het volgende:
Ik heb het al op een andere manier opgelost. Klein stukje Javascript die alleen op de mobiele versie alles binnen de 'container' div laat zien. En die container div heb ik gewoon in de resolutie van de iPhone.
Nu een andere vraag. Ik heb een website-je met daarin een inlog schermpje. Dat inlogschermpje moet zodra het is goedgekeurd via een header naar 'welkom.php'. Alleen omdat ik dus HTML heb gebruikt in die pagina doet de header functie het niet...
Iemand enig idee?
Thanks. Bij het inlogscherm is het gelukt door PHP gewoon helemaal boven aan te zetten. Bij de sessie controle en 'print u bent ingelogd' niet, omdat als ik daar de PHP boven aan zet mijn printje ook op de verkeerde plek staat.quote:Op woensdag 24 maart 2010 12:56 schreef Intrepidity het volgende:
[..]
Je PHP-controleblok helemaal bovenaan zetten, of output-buffering aanzetten. Zie een van de voorgaande pagina's, daar had iemand hetzelfde probleem
1 2 3 4 5 | [.stukje code.] echo "<form action="verwijderen.php" method="post">"; [.stukje code.] ?> |
1 2 3 4 5 6 7 | [.stukje code.] ?> <form action="verwijderen.php" method="post"> <? [.stukje code.] ?> |
Je mag het buiten php houden waarom niet!quote:Op donderdag 25 maart 2010 15:48 schreef Joooo-pi het volgende:
Gaat redelijk met mijn zelfstudie php tot nu toe
Hier weer ff een vraag:
De volgende code geeft een fout:
[ code verwijderd ]
volgens mij door de aanhalingstekens binnen de aanhalingstekens...
Ik heb dit als volgt opgelost:
[ code verwijderd ]
Is het normaal om steeds een stukje code af te breken om html te schrijven en vervolgens weer te beginnen met code? Het loopt allemaal zo door elkaar heen op laatst. Sowieso, moet het onderscheid tussen de enkele en dubbele aanhalingstekens mij nog wat meer duidelijk worden.
Iemand tips?
1 |
1 |
1 |
1 |
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |