Posts by FangorN

Hm, de oplossing van @darkshifty heeft in principe wel wat, ik zou in ieder geval niet allerlei aparte -en expliciete- rewriterules opstellen voor aparte pagina's. Maak dan één rewriterule die op het domein (*.)betaalplugin.nl werkt, en kijk dan of het subdomein overeen komt met een bestaande pagina en serveer anders een 404 pagina ofzo. En stuur dit alles naar één voordeur (single point of entry). Op die manier kanaliseer je alles nog steeds door een index-pagina.

Maar persoonlijk zou ik deze aanpak eigenlijk niet volgen. Kom je hier namelijk niet vreselijk in de knoei met SEO enzo? En wellicht komen pagina-statistieken op die manier ook in allerlei verschillende emmers terecht als je al het bezoek uitsplitst over allerlei subdomeinen, aangenomen dat je er meerdere hebt?

Wat is er mis met de oorspronkelijke vorm?

Tenzij het marketing-metrics subdomein een apart deel van de website betreft met een specifiek doel (bijvoorbeeld een soort van backend/portal voor klanten ofzo) en op die manier echt een soort van bestaansrecht heeft omdat die dingen doet die echt afwijkt van de rest van het betaalplugin.nl domein zou ik de site niet opsplitsen in allerlei subdomeinen.

EDIT: wat @Syntax voorstelt kan ook, maar wederom, ik zou de wildcard vervolgens niet in je querystring stoppen. Het is helemaal niet nodig om de "$_GET namespace" te vervuilen met onzichtbare variabelen. Deze waarde kun je prima uit een $_SERVER-variabele hengelen zonder $_GET te vervuilen.

Hm, interessante materie, maar is dit niet een beetje "who watches the watchmen"?
In de zin van, als je dan toch full tinfoil hat conspiracy theory modus gaat, wanneer is het dan genoeg?

Het is goed om veiligheid in lagen te stoppen, maar om nu alles te encrypten, dit is wellicht misschien wat overkill? Dit belemmert je wellicht ook om van andere optimalisaties in een database gebruik te maken (zie ook hieronder) zoals voor zoekfunctionaliteit? Als je een of andere custom laag hiervoor hebt kun je waarschijnlijk niets direct vinden in deze brei.

Als je bang bent dat dingen uitleesbaar zijn via phpMyAdmin - bied dan simpelweg deze mogelijkheid niet? Maak rechtstreekse (of mogelijk nog beter? indirecte) databasetoegang alleen mogelijk via een beveiligde shell. En zet wellicht een aparte databaseserver op die verder losstaat van de applicatieserver. Je zou ook whitelists kunnen opstellen voor wie de database uberhaupt toegankelijk is; wat trouwens hopelijk toch wel gebeurt, neem aan dat er geen GRANTs uitgegeven worden aan 'god'@'%' of dat je alles ophangt aan je root user :p.

Misschien zou je ook naar "native support" voor encryptie kunnen kijken. Je zou best je eigen encryptielaag kunnen rollen, maar als dit niet je vakgebied is of je jezelf geen vis in het water voelt met deze materie zou ik out-of-the-box / standaard componenten gebruiken. En dat heeft misschien als bijkomend voordeel dat andere functionaliteit nog steeds beschikbaar is.

Oh, sorry, specifiek in blogs, weet niet of dit op andere plaatsen ook optreedt.

Heb hier al een tijd niet meer in geschreven. Code ziet er alleen goed uit nadat je de eerste keer een post submit, daarna is inspring weg bij bekijken post maar als je de codeblokken in het artikel wijzigt verschijnt de inspring weer dus dan lijkt het alsof deze (weer) klopt maar na opslaan is deze weer weg.

Het lijkt er dus ook op alsof er een rauw "origineel" is die verder wel ongewijzigd wordt opgeslagen en een soort van gecachede versie waarin dus alle inspring weg is.

Na 30 pagina's eigen reacties doorploeteren geef ik het maar op, ik dacht dat ik hier ergens een post van had gemaakt.

Concreet gebeuren er twee knetter irritante dingen:
- al mijn inspring wordt weggegooid, dit wordt vervangen door een enkele spatie
- de regels worden gewrapped, wat de code totaal onleesbaar maakt

Het zou wat mij betreft een verbetering zijn om:
- de invoer gewoon niet aan te passen
- lange code regels gewoon in een soort van overflow te zetten, zodat regels niet gebroken worden

Hier al dan niet mee samenhangend vinden er waarschijnlijk aanpassingen op de inhoud plaats (wat nog wat verder voert dan escape-on-input).

Een forum of een ander systeem moet inhoud gewoon accepteren (of niet) zoals deze wordt aangeleverd, en hier -in beide bovenstaande gevallen- niet zelf in proberen te modderen.

Het enige waar de applicatie voor moet zorgen is dat het fatsoenlijk ge-escaped wordt in de gebruikte context, maar zou hier NOOIT zelf inhoudelijk dingen in moeten wijzigen. Als de vorm niet goed is of zou zijn, dan zou de validatielaag hier over moeten klagen, maar dit zou je vervolgens niet door een soort custom vleesmolen moeten laten gaan.

Oh en als we gaan voor visuele zaken met veel code enzo, wellicht een idee om die codeblokken eens te fixen :p.

Citaat van Jeroen.G

Verder zie ik graag de blogs eigenlijk verdwijnen, geen meerwaarde in mijn ogen op dit moment, maak liever een overzichtelijke tuturial page en misschien een keer door de downloads heen spitten, om te kijken wat outdate is en gevaarlijk kwa beveiliging. Zodat we nieuwe leden ook een actueel aanbod kunnen bieden en wat duidelijk oud is!

Maar de tutorials kun je toch prima onderbrengen in blog posts?

Wel zou al deze user generated content wat mij betreft onderworpen mogen worden aan een keursessie voor plaatsing en iemand zal dit ook een beetje moeten bijhouden inderdaad om zo te zorgen dat er geen verouderde of onveilig geworden methodieken worden gebruikt. Software en code hebben meestal een beperkte houdbaarheidsdatum.

Citaat van rickvbeek

Video tutorials

Dat is misschien wel leuk, maar waar worden deze dan geplaatst en hoe houd je dat vervolgens "binnen" de site? Het internet kan best een vluchtig medium zijn. Als iemand besluit om zijn YouTube-kanaal te verwijderen of op te schonen verdwijnt zo'n tutorial wellicht in de prullenbak.

Het ironische (of misschien tragische) van community-sites is dat deze af en toe de plank misslaan in wat ze proberen te bereiken. En soms is het doel niet eens helder geformuleerd (waarover hieronder meer). Ik neem phphulp even als referentie en dan heb ik het met name over het forum, wat eigenlijk het meest actieve deel van de site is. Tutorials en "scripts" zijn volgens mij over het algemeen redelijk oud grut, daarnaast zijn die delen ook niet echt actief. Maar wat er op het forum gebeurt is op zich wel interessant. Dit is overigens mijn persoonlijke mening, anderen mogen hier anders over denken, mij best. Maar dit is wat er over het algemeen gebeurt:
1. topicstarter stelt een vraag
2. er volgt misschien enige discussie, of er wordt
3. direct een antwoord gegeven zonder uitgebreide toelichting over het hoe of wat
(of 4a. het ontwerp ontaardt in een discussie tussen forumleden en de topicstarter reageert niet meer, ik maak mij hier ook wel eens schuldig aan :p)
4b. topicstarter neemt het antwoord zonder boe of bah over of geeft aan dat 'ie zelf al een oplossing heeft of opent een soortgelijke of wellicht identieke nieuwe thread over hetzelfde onderwerp.
5. repeat

Over het algemeen is het dus een beetje een fabriek waarbij de overige forumleden vooral een faciliterende rol vervullen die met name tot doel heeft om een (direct) antwoord op de vraag te geven. Er wordt wat mij betreft (veel) te weinig aandacht besteed aan een analyse van het probleem (wat is er nu werkelijk aan de hand?) en ook de gekozen werkwijze (is dit uberhaupt wel de goede aanpak?). Heel vaak "is het probleem niet het probleem". Een waarschuwing over een ongedefinieerde variabele heeft oneindig veel verschillende verschijningsvormen, maar dat is niet het daadwerkelijke achterliggende probleem. Het probleem is dat de programmeur of hobbyist niet de goede instelling heeft bij het programmeren, of gewoon geen debuggingstools gebruikt om deze informatie snel inzichtelijk te maken. Iemand vertellen dat iemand op locatie X variabele Y even moeten initialiseren lost dan mogelijk op dat moment het directe probleem op, maar deze persoon is verder geen steek wijzer geworden. Er beklijft geen kennis. Je blijft programmeren op een domme manier en dus blijf je domme fouten maken.

Wat mij betreft zouden wat artikelen over programmeren zelf en met name debugging een toevoeging zijn. Debugging lijkt mij namelijk de beste manier om te leren te programmeren. Als je kunt debuggen worden alle triviale vraagstukken in één keer... triviaal. Je hebt dan namelijk zelf een toolkit ontwikkeld om dit soort dingen op te lossen. In plaats van ze elke dag een vis te voeren heb je ze leren vissen, of zoiets.

Een kennissysteem waarin dit soort informatie wordt vastgelegd lijkt mij ook zinnig. Weinig tot geen site heeft echt zoiets. ik heb dat ooit eens geprobeerd van de grond te krijgen bij sitemasters, maar niemand had daar echt trek in. Waar ik weinig trek in had was week na week eenzelfde soort topics lezen die in wezen variaties van dezelfde terugkerende problemen waren :p. Wat nu als je wat uitleg geeft over het fundament en dat je er dan in 1x mee klaar bent? Kun je ze eerst naar de knowledge base of een flow chart sturen voordat je uberhaupt een vraag op het forum stelt.

Een community-site zou ook niet teveel willen doen anders ga je hinken op teveel benen en wordt de spoeling op den duur wel erg dun. Het is nogal suf om 200 subfora te hebben waar nauwelijks iets in wordt gepost bijvoorbeeld. Misschien tijd voor een andere indeling? Iets met tags ofzo? En hierbij mag je je best specialiseren. Dit jaagt misschien mensen weg maar trekt ze ook aan plus het zorgt er dan voor dat je je onderscheidt van de rest van de meute. In plaats van dat je het zoveelste in het rijtje bent.

Just my 2c for now.

Hangt er ook een beetje vanaf wat je bedoelt met "scripts".

Afhankelijk van de (programmeer)taal heb je hier mogelijk hulpstukken voor nodig in de vorm van een webserver of een ander programma, maar dit is lang niet altijd het geval.

Dit is allemaal eenzelfde soort problematiek. Dit kan verholpen worden door gebruikmaking van database-transacties.

Artikel is inmiddels enigszins gedateerd, maar die paragraaf (7.10.9 Voorbeeld van gebruik) beschrijft in wezen nog steeds het onderliggende probleem. Een (beperkte) resource wordt tegelijkertijd meerdere keren gewijzigd naar aanleiding van een serie van handelingen, met ongewenste gevolgen. De remedie is om deze "series van handelingen" zodanig in afzondering (van elkaar) te behandelen, zodat deze niet meer verweven zijn, maar de series an sich ook echt in serie worden uitgevoerd.

Dit voert verder dan simpelweg wat codewijzigingen. Je moet je bewust zijn van wat er mis kan gaan, en vervolgens moeten er zowel in code alsook de database voorzieningen worden getroffen om dit tegen te gaan.

Maar voordat je dit doet moet je echt begrijpen wat er misgaat (zie artikel), waarom dit misgaat en hoe je dit moet bestrijden. Dit zodat je in de toekomst dit soort scenario's kunt identificeren, en dan niet opnieuw dezelfde fout maakt.

Citaat van tkzone

Ik geef het mee als tip dat die dat misschien moet controlleren, omdat hij met bug komt dat mensen veel geld hebben in het spel.

Dat is prima, maar zoveel had ik al min of meer gesuggereerd in een vorige reactie :).

Citaat van tkzone

Als die niet registreert dat die al verkocht is en iemand doet met een request maker ( google chrome app) hem 50x ophalen dan heeft die zo geld.

Ja maar het is dus heel erg belangrijk hoe je dit controleert. Als dit soort fratsen mogelijk zijn dan houdt dat dus in dat de registratie (mogelijk wel gebeurt maar) niet goed plaatsvindt.

Citaat van tkzone

Dan is verkoop auto een voorbeeld waarschijnlijk heb je wel meer dingen die dan opvragen zal dat ook is na lopen.

Maar dat zou dus inhouden dat dit soort checks mogelijk fundamenteel verkeerd zijn. En mogelijk is je applicatie uberhaupt niet uitgerust met de middelen om dit te (kunnen) doen.

Om dit soort zaken te voorkomen moet je waarschijnlijk de mogelijkheid hebben records echt voor korte tijd te locken middels database-transacties. Indien je database (er vanuitgaande dat dit MySQL is) geen gebruik maakt van de InnoDB-engine dan wordt e.e.a. al verdomd lastig zo niet onmogelijk. In dat geval zul je eerst terug moeten naar het database-ontwerp, want om dit programmatisch op te lossen lijkt mij onbegonnen werk (en is mogelijk nog veel foutgevoeliger).

Citaat van Frenzo.Brouwer

Heb ook eigenlijk geen idee hoe ik mijn php errors kan weg schrijven naar mijn database?

Waarom zou je dat willen doen? Volgens mij wordt dit nergens voorgesteld? Dit kun je gewoon doen naar een bestand. Trouwens het aanzetten van querylogging kan wel een performancedeuk opleveren, dus daar zul je misschien ook een beetje op moeten letten.

Citaat van Frenzo.Brouwer

Graag kom ik met een van jullie in gesprek (Liefst via whatsapp of skype) om over de beveiliging te praten. Ik merk wel dat dit stukje minder goed door mij is uitgevoerd omdat ik mezelf hier nooit op heb gefocust...

Dit zou het cement van je applicatie moeten vormen. Tegelijkertijd, indien je niet bekend met bepaalde (andere) principes zoals database-transacties dan kan je code misschien wel "veilig" zijn, maar zijn er nog steeds "onveilige" / onwenselijke situaties mogelijk. Het is zaak dat je van al deze markten thuis bent. Daarbij helpt het als de site "portabel" is zodat je makkelijk een ontwikkel-/test- en productie-omgeving kunt opzetten. En makkelijk code+(test)dabases kunt deployen op deze omgevingen.

Citaat van M.Beers

Dit moet volgens mij de kracht zijn van ICTScripters.

Niet zozeer van deze site alleen, maar meer van alle fora / efficiente communicatie in het algemeen. Op deze manier kun je je boodschap in één keer uitzenden in plaats van 1-op-1 elke keer hetzelfde verhaal te vertellen.

Citaat van M.Beers

Te vaak goedbedoelde adviezen gedaan, waar vervolgens weinig waardering is voor het betreffende persoon (zeg niet dat jij dat doet) en de betreffende persoon heeft er vervolgens ook niks van geleerd.

Sja, dat is het lot van eenieder die reageert op een forum, verwacht niets terug. Dus kun je er misschien inderdaad maar beter iets aan verdienen I suppose :p.

Citaat van Frenzo.Brouwer

Ik krijg nergens een foutmelding en ik zie nergens een fout..

Welke fouten registreer je op dit moment? Worden deze alle braaf weggeschreven naar je errorlog, of veeg je alle foutmeldingen onder het tapijt? Hoe luiden jouw error_reporting(), display_errors, log_errors en error_log directives?

Citaat van Frenzo.Brouwer

Het spel is geprogrammeerd in PHP PDO.

Sja, maar hanteer je de principes van PDO (en daarmee prepared statements) wel juist? Plak je zelf snippets in je query in plaats van hiervoor de placeholders te gebruiken? Dan ga je mogelijk al nat. Het maakt niet uit welke methode je gebruikt; als je de principes hiervan op de verkeerde manier toepast dan levert dat zelden/nooit veilige applicaties op.

Citaat van Frenzo.Brouwer

Wat ik me nu dus afvraag, is het mogelijk om SQL-injecties uit te voeren waardoor je dus onbeperkt geld krijgt?

Ja, zie hierboven, maar mogelijk is er iets anders aan de hand. Maken de queries die je gebruikt voor het uitwisselen van (speel)geld wel gebruik van database-transacties waarbij je eventueel records locked? Anders is het wellicht mogelijk om de server te bombarderen met verzoeken tot het overmaken van geld, waardoor de momenten van controle of iemand wel genoeg geld heeft om iets over te maken en het overmaken zelf door elkaar gaan lopen (met alle ongewenste gevolgen van dien). Je zou voor de gein eens kunnen kijken of er spelers met negatieve geldbedragen zijn? Dit hangt natuurlijk sterk af van hoe alles is ontworpen. Maar als er dus mensen zijn met onbeperkt geld dan zit er ergens iets goed scheef in het ontwerp, de veiligheid van de site, of beide.

Indien je geen gebruik maakt van database-transacties (hiervoor heb je de InnoDB database-engine nodig) zodat je kunt afdwingen dat dit soort geldtransacties echt als één ondeelbare actie uitgevoerd kunnen worden dan is het in zekere zin al einde oefening :p.

Citaat van Frenzo.Brouwer

Hoe kan ik dit testen?

Zie hierboven, of bekijk de suggesties van @darkshifty. Wat je op dit moment wilt doen is het verzamelen van "bewijs" zodat je de situatie kunt reproduceren of op zijn minst kunt verklaren.

Je zou ook eens door je code heen kunnen rennen en zoeken op de databasetabel(len) die betrekking hebben op speelgeld en dan de bijbehorende queries eens verder onder de loep nemen.

Wat misschien ook interessant was geweest was de toestand op het moment van de uit de hand gelopen geldbedragen te backuppen en deze eens op een testomgeving nader te bekijken, aangenomen dat deze website "verplaatsbaar" is. Je had dan waarschijnlijk een ideale testcase gehad, maar misschien is die dus nu alweer permanent verwijderd :/. Ook de database van een "gehackte" site kan zeer veel nuttige informatie bevatten.

Volgens mij ben je al een heel eind. Waar loop je nu op vast? Of wat zou er anders moeten werken dan nu gebeurt?

Citaat van Aaron

Waarbij de achtergrond donkerder word.

Ah, dus je wilt een zogenaamd "smoke screen". Dit is redelijk eenvoudig te realiseren, bijvoorbeeld door een absoluut gepositioneerde div die je over je pagina heenlegt. Het enige wat je nodig hebt is wat CSS:

#popup-overlay  { position: fixed; width: 100%; height: 100%; left: 0; top: 0; right: 0; bottom: 0; z-index: 999; background-color: #333333; display: none; opacity: 0.0; }

En een routine die deze overlay automatisch toevoegt op het moment dat je de (inline) popup opent:

$().ready(function() {
    $('body').append('<div id="popup-overlay" onclick="..."></div>');
    $('... selector ...').click(function() {
        $('#popup-overlay').fadeTo('slow', '0.7');
    });
});

(Waar je dus vervolgens je popup-inhoud overheen zet met een hogere z-index.)

Hierbij kun je een onclick-event in de overlay definieren als er iets speciaals moet gebeuren, bijvoorbeeld dat deze weer gesloten moet worden als je buiten de popup klikt ofzo.

Wordt het e-mailbericht wel verstuurd?

Volg het kruimelpad in de code zou ik zeggen. Begin hierbij bij het einde: hoe verstuurt Banditi mail bij registratie, en is dit alles wel goed geconfigureerd.

Ben je dit bijvoorbeeld op een lokale computer of laptop aan het ontwikkelen, en in welk pakket (WAMP, XAMP, LAMP, MAMP, iets anders)? Dan werkt e-mail mogelijk niet out-of-the-box.

Ben je echt op zoek naar een popup, dus een echt nieuw browservenster, of ben je op zoek naar een inline popup ofwel een modal?

Zijn die laatste drie states geen simulatie-opties dan?

Wat gebruik je in PHP / CI4 om Mollie te integreren? Is hier documentatie van?

Wat zegt de documentatie van Mollie hier zelf over?

Je zou PHPMailer kunnen gebruiken om enerzijds rechtstreeks met de SMTP-server te communiceren en anderzijds dit pakket kunnen gebruiken om fatsoenlijke MIME e-mailberichten op te stellen.

Heb je geinspecteerd wat mail() voor waarde retourneert?

Indien deze false retourneert ligt het (direct) aan jouw code of instellingen op de eigen webserver.
Indien deze true retourneert heeft PHP in principe zijn taak vervuld.

Voor de beeldvorming: mail() (en daarmee PHP) verstuurt zelf geen mail. PHP draagt het mailverzoek over aan een ander proces wat de afhandeling van het versturen verder verzorgt.

Waaruit concludeer je dat specifiek het verzenden niet lukt?

Heb je geprobeerd gewoon een statisch mailtje te versturen?
Heb je je errorlogs geinspecteerd / errors aangezet om te zien of er iets anders misgaat?
Hoe luidt de waarde van $email?

Er kan zoveel misgaan vanaf het verzenden tot en met de ontvangst, heb je bijvoorbeeld je spambox al gecontroleerd? En als je op een goedkope host zit hoef je waarschijnlijk ook niet te verwachten dat mail binnen een paar seconden wordt verstuurd.

Indien mail niet aankomt zul je dit stap voor stap moeten debuggen om te zien waar dit precies misgaat.

Kijk naar de code die het registreren/inloggen afhandelt, vang data eventueel tijdelijk op in een dumpbestand. Hoogstwaarschijnlijk gaat daar iets mis. Vergelijk het met de variant die wel werkt, de verschillen tussen die twee zouden moeten verklaren waarom het niet werkt.

Of er zit misschien brakke code in die controleert op isset($_POST['een_of_andere_afwijkende_button_naam_die_ontbreekt_in_je_modal']) ofzo...

Citaat van Jeroen.G

deze komt constant met foutmeldingen uit login.php/tpl

Hoe luiden deze? Dat lijkt mij de belangrijste informatiebron voor het vinden van een oorzaak.