Citaat van darkshifty

Het valt mij op dat als ik de API call uitvoer of direct benader, dat ik een SSL foutmelding ontvang

Dat zou ik dan ff melden, een testomgeving zou immers de productie-omgeving zo goed mogelijk moeten weerspiegelen. Wat ben je anders precies aan het testen?

Het uitzetten van CURLOPT_SSL_VERIFYHOST en CURLOPT_SSL_VERIFYPEER wordt met klem afgeraden omdat je met deze instellingen kwetsbaar bent voor aanvallen, wat het hele gebruik van HTTPS min of meer teniet doet. Ik snap dat je nu genoodzaakt bent om dat te gebruiken omdat je anders niet kunt communiceren met de API, maar een veel betere oplossing zou natuurlijk zijn dat het certificaat gewoon werkt. Even melden dus.

Ook helpt het als je aangeeft in welke capaciteit je hier naar op zoek bent, en met welk doel.

Je zegt dat je bezig bent met een project over de KvK.

Ben je een student (programmeur in opleiding?) die bezig is met een huiswerk- of afstudeeropdracht?
Ben je een werkgever die bepaalde KvK connectiviteit wil automatiseren?
Ben je een programmeur die dit in opdracht aan het uitzoeken/uitvoeren bent (en krijg je hiervoor betaald)?

In het eerste en laatste geval zou ik toch wat meer eigen inspanning verwachten. En in het middelste geval ingeval je hier weinig tot geen knowhow over hebt en verder geen enkele moeite wilt doen: besteed het uit.

Ook daar kun je op Googlen.

In het bovenstaande bericht staat een link naar de/een "KVK API". Daarin staan weer links naar verdere documentatie en een developer subdomein. Daar wordt waarschijnlijk een volledige specificatie uit de doeken gedaan zodat je deze zelf kunt bouwen. Of wellicht zijn er al out-of-the-box PHP implementaties beschikbaar.

Maar het feit dat je dit niet kon vinden wil min of meer zeggen dat je hier niet echt naar hebt gezocht, ik bedoel, ik type simpelweg "KVK API" in in Google en we arriveren met het volgen van het eerste resultaat direct bij onze eindbestemming...

Citaat van luna

maar die krijg ik niet gevonden

letterlijk het eerste zoekresultaat op "KVK API"

Je zou een klasse/wrapper kunnen schrijven hiervoor waarbij je de cURL-instructies scheidt van de daadwerkelijke API-commando's, dit scheelt een hele hoop code.

Kan me trouwens niet voorstellen dat iemand niet al zoiets heeft gedaan? En misschien zou je zo'n oplossing wel aan anderen aan kunnen bieden.

Citaat van lekkeryoo

Het script heeft een read pagina die niet werkt

Dit is niet alle code. Ook genereert include(_once) geen foutmeldingen als er bestanden ontbreken.

Krijg je ook foutmeldingen te zien?
Zet anders eens aan het begin van het bestand (direct op de regel na <?php) het volgende:

error_reporting(E_ALL);
ini_set('display_startup_errors', true);
ini_set('display_errors', 'stdout');

Dit zorgt ervoor dat alle foutmeldingen (dus ook notices enzo) op het scherm worden weergegeven. Deze instellingen zijn uiteraard alleen bedoeld voor debugging.

Krijg je vervolgens meldingen op het scherm te zien?

Citaat van lekkeryoo

ik heb al een game online

Wat betekent dit?

Betekent dit dat het inmiddels gelukt is?
Betekent dit dat je afziet van de import en het over een andere boeg gooit met een andere source?
Heb je nog (steeds) hulp nodig met het huidige probleem?
Iets anders?

Zelfs wanneer je de import aan de praat krijgt dan is er een grote kans dat dit pas de eerste horde is.

Als dit inderdaad een (zwaar) verouderd systeem is dan is de code (en misschien nog belangrijker, de hierbij gebruikte ontwerpprincipes) hoogstwaarschijnlijk ook verouderd en mogelijk worden er ook functies gebruikt (zoals de mysql_* functies voor de oorspronkelijke MySQL-driver) die niet meer worden ondersteund in nieuwere PHP-versies.

Het voorstel om daarom maar terug in de tijd te gaan met de PHP-versie, ik weet niet of je dit moet doen.

Maar mogelijk nog het grootste probleem is dat dit soort systemen van zichzelf vaak slecht in elkaar zitten. De hele architectuur is doorgaans een complete gribus. Geen filtering op input, geen escaping van output. Geen database-transacties voor batches van queries wat de foutgevoeligheid en het risico dat deze gemanipuleerd kunnen worden aanzienlijk vergroot. Deze projecten schenken, van wat ik ervan meegekregen heb, vaak weinig tot geen aandacht aan security.

De observatie (of realisatie) dat software onderhevig is aan slijtage is ook belangrijk. Software heeft gewoon een houdbaarheidsdatum en is op een gegeven moment door externe veranderingen (nieuwere versies van PHP, MySQL, webserversoftware etc.) niet of niet goed meer bruikbaar.

Misschien is het een beter idee om te kijken naar recentere sources, hier aan bij te dragen of het (specifieke) concept van dit systeem in een compleet nieuwe jas te gieten indien je hier zelf genoeg knowhow voor hebt of voor kunt vinden. Het heeft denk ik weinig zin om in deze huidige vorm aan dit dode paard te trekken als het inderdaad een oude source betreft.

Daarbij denk ik dat een eerdere opmerking over het gebruik van het (werk)woord "script(ing)" hier ook (deels) van toepassing is.

Citaat van RJ Webdesign

Modded software vertellen we waar je die kunt halen (legaal uiteraard)

Citaat van RJ Webdesign

dit doen we met betaalde software, zo maken we de accounts modded.

Even kijken of ik dit goed begrijp.

De "modded software" is het resultaat van "betaalde software" die waarschijnlijk ingrijpt op bestanden van een GTA-spel, zodat je een of meer voordelen hebt in dat spel die anderen niet hebben. In de volksmond heet dit volgens mij valsspelen?

Hoe is dit legaal? Dit is toch het equivalent van (het meewerken aan) het kraken van software?

En waarschijnlijk schend je daarmee ook de EULA (End User License Agreement) van GTA / in het algemeen / van de console of het platform waar je op speelt, ook al heb je hier mogelijk nergens expliciet mee ingestemd.

Misschien zijn er aan hun kant* mogelijkheden om een feed te genereren, of wellicht ondersteunt die webshop bepaalde webservices? Ik zou eerst kijken naar de mogelijkheden om het -in overleg- geautomatiseerd te importeren via gangbare tools.

Webscraping is eigenlijk het ding wat overblijft (en je pas zou moeten proberen) wanneer alle andere mogelijkheden zijn uitgeput.

En ja, op het moment dat je een bepaalde taak hebt die je honderden/duizenden keren moet herhalen en die je in code kunt vatten dan zou je dat zeker moeten proberen om te doen want het schrijven van die code kost waarschijnlijk minder tijd dan hier manueel doorheen gaan.

Citaat van Servertjee

Het gaat bij de variabel "Optellen" mis, deze wordt 2x aangegeven maar met verschillende waardes.

Dat staat niet met zekerheid vast (of het gaat in ieder geval niet mis op de manier zoals je denkt, zie hieronder) want beide $health['optellen'] manipulaties (2x2) zitten in verschillende delen van het if statement waar $schade['own'] en $schade['user'] worden vergeleken (regel 33 in het eerder geposte fragment). Als de code was ingesprongen (dit forum maakt dit helaas weer ongedaan) dan had je dit kunnen zien. De bijbehorende queries worden dus nooit foutief door elkaar heen gebruikt omdat deze in verschillende delen van het if-statement zitten. Alles staat dus waarschijnlijk wel op de goede plaats, maar doen niet de goede dingen, of leveren mogelijk nooit een dode speler op, of, zoals we hieronder misschien kunnen opmaken, werkt dit alles niet zo lekker :p.

De enige manier waarop dit verder onderzocht kan worden is door relevante gevallen af te lopen en daarbij de randgevallen te bekijken. Oftewel gewoon ff door de code heenlopen (nadat je dit in een editor een beetje hebt gefatsoeneerd want hier is het onleesbaar).

Maar nogmaals: het is sowieso compleet maf dat (enkel) het aantal killers plus je eigen "power" bepaalt of de "moord" succesvol is (en dat er geen enkel random aspect is of een soort van bonus modifier voor een grotere kans op succes - het is compleet deterministisch), en dat de speler vervolgens HP verliest. Je zou eerder verwachten dat iemand dan een aantal killers verliest, en als ze allemaal zijn omgelegd dat dan de eindbaas (de speler) kwetsbaar is en aangevallen kan worden ofzo.

Alle logische zaken daar gelaten (genoeg killers, zelfde stad, verschillende familie, doelwit niet veilig, voldoende rang en laatste aanval voldoende lang geleden) blijven daar de volgende factoren over:
- schade afhankelijk van killers + eigen power
- (ingeval own wint) een breekpunt van 3 hitpoints, als de user hieronder zit is ie dood, dit is dus een soort genadeklap-aanval
- als de user boven 3 hitpoints zit verliest ie maximaal 3 hitpoints en houdt ie dus altijd minimaal 1 hitpoint over, maar dan kan ie dus de volgende aanval dood zijn

Nota bene: omdat er geen random aspect aan de aanvalsschade is, en wanneer het bekend is hoeveel killers en power iemand heeft -is dit publieke informatie, weet je dit van elkaar? - dan kun je dus altijd aanvallen uitvoeren die 100% kans van slagen hebben? Wat weet een speler over andere spelers?

- maar dan is er nog een raar breekpunt bij 298 health als je wint
je krijgt er 2 HP bij als je onder de 298 zit en anders gaan er misschien wel hitpoints af
dit heeft waarschijnlijk als resultaat dat je maximaal rond de 300 HP zweeft?
^ de dikgedrukte tekst hierboven verklaart mogelijk de reden dat dit zo is opgezet, dit is dus waarschijnlijk niet fout, maar gewoon zo bedoeld

Voordat je dood bent / op of onder de kritische grens van 3 HP zit en aanvallen verliest gaan er per aanval maximaal 3 HP af, dat kan wel ff duren als je (op den duur) rond de 300 zit :p.

Het lijkt er dus wel op dat je iemand daadwerkelijk dood kunt krijgen, maar dat kost misschien nogal wat tijd, maar het kan.

En dan nog de case dat je een moord probeert te begaan die gedoemd is om te mislukken (dit is 100% deterministisch doordat dit puur afhangt van killers en power en geen enkel random aspect heeft), gebeurt dit uberhaupt ooit? Dit hangt dus af van de informatie die je over een andere speler hebt. Weet je het aantal killers maar niet iemands power of andersom of heb je beide stukken informatie niet dan is het een gok om iemand aan te vallen. Hierbij kun je (als aanvaller) eigenlijk alleen maar dood gaan als je minder dan 4 HP hebt. Misschien is het dan ook niet verstandig om een willekeurig iemand aan te vallen. Je zou zelfs een aantal accounts kunnen rollen die je expres zwak houdt om zo je sterkere karakters terug in het groen te trekken als ze weinig HP meer hebben. Maar niet dat dat wat boeit als je tussen de 4 en 300 (!) HP zit want dan kun je toch niet (direct) dood :p.

Tegelijkertijd kun je je ook bedienen van de strategie om iemand altijd 2 of 3x aan te vallen. Misschien dwing je hem dan de eerste keer op de knieen (<4 HP) en reken je vervolgens permanent met iemand af. Is nog steeds een kleine kans dat ie dit weer overleeft. Je zou dus iemand kunnen spammen of aanvallen coordineren. Is er alleen maar een tijdsrestrictie? Waarom kost het bijvoorbeeld geen cash om een aanval uit te voeren? Dit vergt toch enige organisatie zou je zeggen, munitie voor de killers, logistiek om iedereen op locatie te krijgen et cetera?

Het zit sowieso gewoon raar in elkaar, op meerdere fronten.

Maar het is dus volgens mij wel degelijk mogelijk om iemand (permanent?) te doden. Of jezelf, als je erg dom bezig bent / niet op je HP let.

EDIT: en in die zin is de code dus ook niet per definitie "fout" maar kan misschien getweaked of aangepast worden (random elementen?) om het geheel wat interessanter te maken.

/rant

Wellicht een tip: stop wat annotatie (commentaar) in code, zodat je in ieder geval weet wat er functioneel de bedoeling is. Er is nu geen enkele leidraad die aangeeft hoe het dan wèl zou moeten werken, wat alles nodeloos complexer maakt. Je zou nu namelijk je eigen product moeten reverse engineeren om vast te stellen hoe het nu geldende "gedrag" is, en hoe dit afwijkt van hoe het zou moeten werken.

Documentatie, zelfs een minimale inline variant, bij dit soort systemen lijkt mij nogal belangrijk.

Maar alle software heeft een houdbaarheidsdatum en is onderhevig aan veroudering.

Indien projecten niet worden bijgewerkt en op den duur niet meer werken kun je niet echt de schuld (uitsluitend) in de schoenen schuiven van de gebruikte techniek(en), de oorzaak daarvan ligt dan toch echt ergens anders ;).

(edit: ah, ik zie wat je bedoelt, aanverwante libs die gebruik maken van jQuery maar op een gegeven moment niet meer compatibel zijn, maar dat is in zekere zin nog steeds een onderhoudsprobleem, en niet zozeer een inherent jQuery-probleem; het creëert natuurlijk wel een afhankelijkheid en die kan onhandig zijn inderdaad; streven naar minder afhankelijkheid is meestal goed)

Neemt niet weg dat je best je horizon mag verbreden, jQuery is een oplossing, en niet per definitie dé oplossing.

Citaat van tigermaffia

PS als ik me niet vergis is het een script van jou haha

Ik denk dat je je vergist. Heb namelijk nooit aan dit soort webspellen gewerkt.

EDIT: ik weet niet hoeveel "health" een speler normaal heeft, maar $health['user'] heeft een hele kleine waarde, dus de kans dat $health['user'] kleiner is dan een random getal tussen 1 en 3 is nagenoeg 0?

Dit lijkt verder ook totaal ongecorreleerd aan de schade die je toebrengt, wat misschien ook een beetje vreemd is?

Verder niet gerelateerd maar je slaat verderop $own['power'] op als buit? Zou dat niet $winst['cash'] moeten zijn?

Ik heb het gevoel dat er wel meer rammelt in deze lap code...

Wat is $sql voor object, en wat gebeurt er als een query misgaat?

Dit lijkt mij sowieso niet kloppen:
UPDATE attlose = attlose + '1', users SET cash = ...

Even los van het feit dat er niets ge-escaped wordt in queries, en het geheel niet in een transactie staat, misschien is het handig als de klasse waar $sql een object van is een soort van wrapper is waarbij je query-logging aan en uit kan zetten? Dan zou je een tijdje dit soort moord-query-batches kunnen loggen, dan zie je precies welke queries worden uitgevoerd, en met welke waarden.

Op die manier heb je een aantal concrete cases die je kunt analyseren. Op dit moment is het grootste probleem dat je niet precies weet wat er misgaat, omdat je geen enkele concrete informatie hebt van wat er gebeurt, dus dan wordt het nogal lastig om te bepalen wat er nu precies aan de hand is.

Je zult dus moeten beginnen met het verzamelen van informatie.

Citaat van tigermaffia

speller 1 valt speller 2 aan speller 2 heeft nog twee % leven nu valt speller 1 weer aan nu blijft speller 2 op 1 % staan en niet dood dus ik weet niet waar het fout zit.

¯\_(ツ)_/¯

Waarom zou dat fout moeten zijn? tenzij er niemand wordt verslagen op die manier?

Wat is er mis met jQuery though? Deze lib helpt je ook met cross browser compatibiliteit etc.
Vanwaar de aversie voor jQuery?

Zelfs als verschillende subdomeinen compleet verschillende pakketten gebruiken dan zou je index.php nog steeds als een soort van routing-portaal / superbootstrapper kunnen gebruiken met een simpel switch-statement:

<?php
$found = false;


switch ($_SERVER['SERVER_NAME']) {
    case 'www.domain.com': // website
    case 'cdn.domain.com': // CDN
    case 'blog.domain.com': // WordPress
    // et cetera
        $found = true;
    break;
}


if ($found) {
    // laad de config file behorend bij het subdomein
    require_once '/path/to/bootstrap/'.$_SERVER['SERVER_NAME'].'.php';
} else {
    header('HTTP/1.0 500 Internal Server Error');
    die('error: subdomain not found');
}
?>

En in /path/to/bootstrap/ stop je je configuratiebestanden. Bijvoorbeeld de config voor WordPress wordt dan /path/to/bootstrap/blog.domain.com.php etc. In de individuele cases van het switch-statement kun je eventueel nog meer constanten en/of environment variabelen instellen, of de configuratiebestanden specfieke namen en paden geven met behulp van een extra $path variabele ofzo.

EDIT: het enige wat je hiervoor nodig hebt is een enkele rewriterule die alles naar dit index.php bestand doorstuurt.

Dit kan wat mij betreft allemaal zonder serverconfiguratie en met slechts een enkele rewriterule die gewoon alles doorstuurt naar een index.php die het verder uitpluist. Zo verplaats je het probleem naar programmacode / programmeerbare logica. Is dat niet veel eenvoudiger?

Hangt er wel een beetje vanaf wat de rest van het domein allemaal doet, maar los daarvan verdient één centrale verkeersregelaar eigenlijk altijd de voorkeur boven tig verschillende stukken configuratie die bovendien allemaal op een verschillende plaats staan en ook apart ingeregeld dienen te worden. Simpelweg uit oogpunt van overzicht / simpliciteit.