Structuur webapplicatie met meerdere clients op 1 pagina

[Verwijderd]

Hoi! *zwaait*

Ik ben bezig met een projectje met e-tickets (concertkaarten). Ik heb een "webapplicatie" gebouwd met de volgende functionaliteit:
Na creëren van een account en inloggen, kan een csv-bestand kan geüpload worden, dit bestand bevat een lijst van barcodes (en enkele andere gegevens) van alle toegangskaarten voor een bepaald concert. Het bestand wordt geopend/ingeladen in een pagina die de inhoud van het csv-bestand weergeeft. Op deze pagina (laat ik het de scan-pagina noemen) kunnen de kaarten worden gecontroleerd met een barcodescanner. Deze vult een invoerveld en er wordt gecontroleerd of de gescande barcode in de lijst aanwezig is.

Nu wil ik de applicatie uitbreiden met een functionaliteit waarbij er een tweede (en wellicht derde of vierde) client kan inloggen en daarna toegang krijgt tot een subset van de lijst die op dat moment is ingeladen op de 'scan-pagina' (deze subset toont alleen de barcodes die als 'VIP' zijn aangemerkt door middel van één van de kolommen in het csv-bestand).

De vraag is, hoe krijg ik bovenstaande voor elkaar?

Het doel hiervan is om door middel van socket.io (onder andere) real-time te zien of er VIP-barcodes zijn gescand.

[MAX3400]

En hoe sla je e.e.a. op nu dan? Nadat de CSV is geupload, wordt deze dan in de (RAM) working-set van de http-daemon voor de ingelogde user gehouden? Of sla je de CSV op in een ander formaat waarna het dan wordt weergegeven op de scan-pagina?

Want volgens mij, maar even out of the box; user A kan natuurlijk niet direct de gegevens van user B zien. Logischerwijs upload je de CSV als "beheerder", slaat de data op in een centrale database en die database kan/mag door users 1 t/m 4 gelezen worden.

Daarna, als je scant, is een ticket al gevalideerd en zal deze dus ook door user 1, 2, 3 OF 4 mogen worden afgevinkt in de database zodat een tweede scan (aan de deur??) niet mogelijk meer is.

[DJMaze]

Ja, ja, hier weer die php "sukkel" die overal wel iets van weet

Is je projectje een test of praten we over een echt concert met 500 kaarten ofzo?

Er zijn namelijk ticket systemen waar je €0,50 tot €1,- betaalt per ticket om het te gebruiken.

Ik ontwikkel ook een ticket systeem en dat kost € 30.000 aan ontwikkeling.
En dat weegt natuurlijk niet op bij 1 concert

[Verwijderd]

Bedankt voor je antwoord. Toen ik hiermee begon ben ik ook eerst gaan kijken wat er al op de markt was, of wat er al voor gelijkwaardige software 'bestond'. Ik ben toen ook het soort SaaS-diensten tegengekomen waar je waarschijnlijk aan refereert, maar die zijn erg duur. Helemaal als het €0,50 oid per ticket zou kosten. Het gaat namelijk al snel om 600 tot ruim 1000 kaarten. Vaak zitten er ook nog maandelijkse kosten aan vast. Dus ja, toen vond ik t een uitdaging om zelf iets in elkaar te knutselen

Het gaat om in principe om een hobby-project, maar wel iets wat ik in kan zetten in de praktijk. Dat geeft ook wel wat meer motivatie om er aan te werken.

De functionaliteit die ik tot nog toe heb gebouwd is absoluut niet ingewikkeld. Ook de functionaliteit die ik eraan toe wil voegen zou niet per se enorm ingewikkeld moeten zijn. Ik loop er in deze alleen tegenaan dat ik niet net niet genoeg kennis heb om meteen te weten hoe ik dit moet vormgeven. Het zou mooi zijn als iemand me in de goede richting zou kunnen sturen. Er is ongetwijfeld een logische of voor de hand liggende manier om dit op te lossen, alleen zie ik die nu even niet

Edit: wel gaaf om zoiets te ontwikkelen. Met 30k zal het een aardig projectje zijn.

[ Voor 3% gewijzigd door Verwijderd op 11-01-2019 22:58 ]

[TwArbo]

Je noemt socket.io, oftewel met NodeJS. Is je applicatie ook in NodeJS geschreven?

[ Voor 56% gewijzigd door TwArbo op 11-01-2019 23:15 ]

[Verwijderd]

@TwArbo
Het uploaden van het CSV-bestand gaat met PHP. De functionaliteit van de 'scan-pagina' komt van JavaSript. Er zitten enkele events aan, bijvoorbeeld dat de achtergrond rood wordt bij een onbekende barcode, en oranje bij een barcode die reeds gescand is. Aantal gescande barcodes wordt weergegeven. Ook wordt in een kolom 'gescand' ingevuld zodra een barcode is gescand. Er wordt op dit moment echter niets opgeslagen. Bij pagina refreshen is de lijst nog aanwezig maar verder is alles 'gereset'.

[TwArbo]

Verwijderd schreef op vrijdag 11 januari 2019 @ 23:32:
@TwArbo
Het uploaden van het CSV-bestand gaat met PHP. De functionaliteit van de 'scan-pagina' komt van JavaSript. Er zitten enkele events aan, bijvoorbeeld dat de achtergrond rood wordt bij een onbekende barcode, en oranje bij een barcode die reeds gescand is. Aantal gescande barcodes wordt weergegeven. Ook wordt in een kolom 'gescand' ingevuld zodra een barcode is gescand. Er wordt op dit moment echter niets opgeslagen. Bij pagina refreshen is de lijst nog aanwezig maar verder is alles 'gereset'.

Aah oké. Waarom laat je men een CSV bestand uploaden?

Als je mij een PM stuurt, wellicht kan ik je dan gericht feedback geven. Ik help je graag.

[Verwijderd]

@MAX3400
Op dit moment worden de 'kolommen' van het CSV-bestand uitgelezen (load data local infile) en 1-op-1 opgeslagen in de database, waarbij bij elk record (row) ook de user-id van de ingelogde gebruiker word opgeslagen. Dit zou in dat geval het id van de 'beheerder' zijn.

Het verlenen van toegang tot bepaalde bestanden aan meerdere gebruikers is denk ik niet per se een groot struikelblok. Het gaat er meer om dat ik probeer uit te vogelen op welke manier ik, nadat het bestand is ingeladen op de 'scan-pagina' andere users toegang kan verlenen tot die specifieke lijst, op een dergelijke manier dat er bijv. met socket.io gecommuniceerd kan worden tussen deze pagina's.

Het zou goed kunnen dat ik veel te ingewikkeld denk en/of dat ik een hele domme vraag stel. Ik ben niet bepaald een dev-guru

[TwArbo]

Ik zou het volgende doen:

1. Zorg voor een centrale database.
2. Je maakt al een deel in PHP. Dus je kunt daarbij een json api maken.
3. Je javascript applicatie kan dan de json uitlezen (makkelijker dan csv).
4. Socket.io is dan niet nodig (je moet dan een socket hebben draaien).
5. Als je toch een socket wilt draaien. Wat ik kan snappen als je daar iets over wilt leren. Dan moet je wel een hosting/server hebben die dat voor je kan bieden. Shared webhosting biedt zulke dingen meestal niet.

Bekijk Laravel eens (php framework). Die heeft alles wat jij wilt al in het framework zitten voor de API.

[Verwijderd]

@TwArbo
Dankjewel voor je bericht, een centrale DB heb ik iig al, die ik kan dus afstrepen denk ik.

Om antwoord te geven op je eerdere vraag, ik ben apart bezig met het bouwen van de applicatie en het leren van NodeJS en socket.io. Ik kwam er inderdaad achter dat ik hosting nodig heb waarbij ik de rechten heb om bijv. NodeJS te kunnen installeren. Ik heb toen een Raspberry Pi gekocht en daar LAMP op gezet en daarna Node geïnstalleerd. Webserver ingesteld met Express. De applicatie is niet in NodeJS geschreven.

[TwArbo]

Oké! Wellicht is het handig om eerst te kijken hoe Socket.io werkt.

Maak eens 1 simpel html bestand en 1 simpel js bestand waar je de socket.io package inlaadt. In je js bestand is het handig om als eerste console.log uit te voeren om te kijken hoe het werkt.
Bijvoorbeeld deze code maakt een socket op poort 3000.

JavaScript:

var app = require('express')();
var http = require('http').Server(app);
var io = require('socket.io')(http);

io.on('connection', function(socket){
  console.log('a user connected');
});

http.listen(3000, function(){
  console.log('listening on *:3000');
});

HTML:

<!DOCTYPE html>
<html>
    <head>
       <title>Test socket</title>
    </head>
    <body>
        <script src="LINK-NAAR-SOCKET:3000/socket.io/socket.io.js"></script>
        <script>
            var socket = io.connect('LINK-NAAR-SOCKET:3000');
        </script>
    </body>
</html>

Bovenstaande code werkt bij. Ik krijg een console log als ik connectie maak met de socket via de browser.

[ Voor 29% gewijzigd door TwArbo op 12-01-2019 11:02 ]

[Janoz]

Mwah, ik denk eerder dat het handiger is om te kijken hoe de applicatie nu eigenlijk opgezet is en waar (in welke scope en op welk device) nu eigenlijk welke data bijgehouden wordt.

Wat ik nu begrijp is dat er een database is, een php applicatie en een webpagina. Wat ik verder een beetje af kan leiden is dat de gegevens in principe eerst in de database gezet worden en vervolgens met php omgezet worden naar een webpagina. Dit gebeurt allemaal op de server. Vervolgens wordt de hele controle op de client gedaan. Dit speelt zich echter allemaal af op de client (scanner). Geopperde probleem is dat de ene scanner een lijstje heeft en dat de andere scanner hetzelfde lijstje zou moeten hebben. en TS wil nu op 1 of andere manier die gegevens gaan synchroniseren.

Eigenlijk zit het probleem al veel eerder en is het hele socket.io verhaal een vorm van symptoombestrijding.

Werkelijk probleem is dat begonnen is met een verkeerde architectuur. Als je meer dan 1 client wil gebruiken moet je niet gaan valideren op de client, maar valideren op de server.

[TwArbo]

Janoz schreef op maandag 14 januari 2019 @ 13:49:
Mwah, ik denk eerder dat het handiger is om te kijken hoe de applicatie nu eigenlijk opgezet is en waar (in welke scope en op welk device) nu eigenlijk welke data bijgehouden wordt.

Wat ik nu begrijp is dat er een database is, een php applicatie en een webpagina. Wat ik verder een beetje af kan leiden is dat de gegevens in principe eerst in de database gezet worden en vervolgens met php omgezet worden naar een webpagina. Dit gebeurt allemaal op de server. Vervolgens wordt de hele controle op de client gedaan. Dit speelt zich echter allemaal af op de client (scanner). Geopperde probleem is dat de ene scanner een lijstje heeft en dat de andere scanner hetzelfde lijstje zou moeten hebben. en TS wil nu op 1 of andere manier die gegevens gaan synchroniseren.

Eigenlijk zit het probleem al veel eerder en is het hele socket.io verhaal een vorm van symptoombestrijding.

Werkelijk probleem is dat begonnen is met een verkeerde architectuur. Als je meer dan 1 client wil gebruiken moet je niet gaan valideren op de client, maar valideren op de server.

100% mee eens. Dat vond ik ook al, maar als TS dit wilde gebruiken om meer te snappen van Socket.io en real time updates, tja dan kan het een oké hobby projectje zijn.

[BarôZZa]

Je hoeft niet persé te valideren op de webserver.

Je kan ervoor kiezen om clientside te valideren (want sneller en betrouwbaarder, als het een drukke rij is voor een feest dan kan een storing funest zijn) en op de achtergrond de gescande barcodes naar de server te sturen en de gebruikte barcodes op te halen en clientside te updaten. Of als je lazy bent haal je periodiek alle tickets met de status op. Afhankelijk van hoe vaak je dat doet is het enige risico dat twee mensen op hetzelfde moment op twee plekken met een enkel ticket binnen zouden kunnen komen.

Overigens vormt dat wel een beveiligingsrisico als je de barcodes naar de client stuurt. Je kan deze beter hashen.

Socket.io lijkt me voor deze toepassing niet echt nuttig. Een good ol' ajax call werkt net zo makkelijk.

[ Voor 7% gewijzigd door BarôZZa op 14-01-2019 17:58 ]

[Janoz]

BarôZZa schreef op maandag 14 januari 2019 @ 17:56:
Je hoeft niet persé te valideren op de webserver.

Je kan ervoor kiezen om clientside te valideren (want sneller en betrouwbaarder, als het een drukke rij is voor een feest dan kan een storing funest zijn)

Sneller? Marginaal.. Betrouwbaarder? Zeker niet, eerder het tegenovergestelde.

Ik ben benieuwd hoe druk de rij zou moeten worden voordat het uberhaupt een probleem gaat worden. Hoeveel kaartjes kan een beveiliger scannen? Zonder fouilleren komt je niet boven de 1 per seconde uit. Zet vervolgens eens 10 beveiligers naast elkaar (we hebben het over een organisatie die niet het budget heeft om 50ct per kaartje extra uit te geven, dus dat lijkt me al heel veel) dan kom je uit op 10 requests per seconde.

De enorme [sarcasme] load die dat op een RaspberryPi genereert kan ie nog wel afhandelen terwijl hij een FullHD video aan het afspelen is...

Overigens vormt dat wel een beveiligingsrisico als je de barcodes naar de client stuurt. Je kan deze beter hashen.

Ook dit lijkt me het oplossen van het verkeerde probleem. Steek je energie in het gesloten houden van het systeem dan is het netwerk vervolgens gewoon te vertrouwen. Hashen is in dit geval ingewikkelder dan je denkt. Denk het maar eens uit. Crux zit het hem voornamelijk in omdat je niet alleen de barcode moet scannen, maar na scannen ook ongeldig moet maken. Elke oplossing die je gaat verzinnen zal falen op 1 van de volgende 3 redenen:
1 Werkt niet
2 Je hebt een nodeloos ingewikkelde implementatie gemaakt van serverside controleren
3 De hashes zijn gepromoveerd tot dezelfde waarde als het originele nummer waardoor ze op het gebied van beveiligingsrisico evenwaardig zijn.

[BarôZZa]

Janoz schreef op dinsdag 15 januari 2019 @ 13:09:
[...]


Sneller? Marginaal.. Betrouwbaarder? Zeker niet, eerder het tegenovergestelde.

Ik ben benieuwd hoe druk de rij zou moeten worden voordat het uberhaupt een probleem gaat worden. Hoeveel kaartjes kan een beveiliger scannen? Zonder fouilleren komt je niet boven de 1 per seconde uit. Zet vervolgens eens 10 beveiligers naast elkaar (we hebben het over een organisatie die niet het budget heeft om 50ct per kaartje extra uit te geven, dus dat lijkt me al heel veel) dan kom je uit op 10 requests per seconde.

Het is sneller/betrouwbaarder omdat je niet afhankelijk bent van een stabiele internetverbinding. En ja, dat is nog zeker een probleem tegenwoordig. Denk aan raves/festivals op afgelegen gebieden of in een betonnen bunker waarbij het bereik slecht is of een mobiele netwerkstoring.

Offline first web apps zijn tegenwoordig heel gebruikelijk.

De enorme [sarcasme] load die dat op een RaspberryPi genereert kan ie nog wel afhandelen terwijl hij een FullHD video aan het afspelen is...

Als het daarop kan, dan kan de load ook op de client . Het punt is dat je niet wil dat je tickets niet kan controleren op een event doordat er een netwerkstoring is of je geen bereik hebt, niet dat de load voor de server te hoog is

Ook dit lijkt me het oplossen van het verkeerde probleem. Steek je energie in het gesloten houden van het systeem dan is het netwerk vervolgens gewoon te vertrouwen. Hashen is in dit geval ingewikkelder dan je denkt. Denk het maar eens uit. Crux zit het hem voornamelijk in omdat je niet alleen de barcode moet scannen, maar na scannen ook ongeldig moet maken. Elke oplossing die je gaat verzinnen zal falen op 1 van de volgende 3 redenen:
1 Werkt niet
2 Je hebt een nodeloos ingewikkelde implementatie gemaakt van serverside controleren
3 De hashes zijn gepromoveerd tot dezelfde waarde als het originele nummer waardoor ze op het gebied van beveiligingsrisico evenwaardig zijn.

Ongeldig maken kan op de achtergrond als je verbinding hebt. Als je geen verbinding hebt controleer je op de client of de barcode geldig is en niet op die client is gebruikt. Zo ben je nooit afhankelijk van de internetverbinding. Het grootste risico is dan dat je bij (tijdelijk) geen verbinding je een ticket op twee plekken kan scannen, maar dat lijkt me prima in te calculeren en lastig om in de praktijk te misbruiken (je moet op twee plekken tegelijk binnenkomen en weten dat ze geen verbinding hebben).
Dat is beter dan het risico dat je geen enkele ticket kan scannen.

Hashes zijn niet gepromoveerd tot dezelfde waarde omdat je niet de barcodes (snel) kan genereren. Je kan dus geen tickets printen als je het lijstje met hashes hebt, alleen controleren of een barcode geldig is.

Het is overigens niet nodeloos ingewikkeld, het is een bulletproof systeem ontwerpen dat in praktijksituaties blijft werken. Een ticketsysteem ontwerpen dat afhankelijk is van een werkende internetverbinding is een kwestie van tijd voordat een evenement in de soep loopt.

Nu ik het overigens Google zie ik dat andere ticketverkopers ook gewoon offline kunnen scannen
(https://www.eventbrite.co...tbrite-organizer?lg=en_US : NOTE: If you lose your connection to the internet during check-in, you will receive a warning from the app, but you can continue to check in attendees offline. All your check-ins will automatically sync when your internet connection is restored.)

[Janoz]

Internet? TS heeft het over een (onsite?) RaspberryPi. Ik ga er voor mijn situatie dan ook vanuit dat we het hier gewoon over een intranet hebben. Implementeer een REST service op je Pi. Bij het scannen een enkele call die een 200, 403 of 404 terug geeft en klaar.

[BarôZZa]

Janoz schreef op dinsdag 15 januari 2019 @ 16:06:
Internet? TS heeft het over een (onsite?) RaspberryPi. Ik ga er voor mijn situatie dan ook vanuit dat we het hier gewoon over een intranet hebben. Implementeer een REST service op je Pi. Bij het scannen een enkele call die een 200, 403 of 404 terug geeft en klaar.

Het lijkt me dat hij de raspberry pi als webserver wil gebruiken(hij heeft het ook over hosting) om centraal de tickets te beheren van verschillende events op verschillende locaties (+ eventueel dat mensen daar hun ticket kunnen kopen). Het lijkt me niet handig om per locatie een raspberry pi te moeten installeren en een lokaal netwerk op te zetten.

Het lijkt me dat je gewoon een willekeurige smartphone/laptop + barcode scanner moet kunnen gebruiken met de web app. Anders ben je een oplossing aan het bedenken die complexer is dan wat er op de markt is.

Lees niks over intranet.

[Janoz]

BarôZZa schreef op dinsdag 15 januari 2019 @ 16:35:
[...]

Het lijkt me dat hij de raspberry pi als webserver wil gebruiken(hij heeft het ook over hosting) om centraal de tickets te beheren van verschillende events op verschillende locaties (+ eventueel dat mensen daar hun ticket kunnen kopen).

TS heeft het over het opschalen van 1 handscanner naar meerdere. Dat is nog een heel stuk verwijderd van meerdere events die op verschillende lokaties gelijktijdig gehouden worden.

[BarôZZa]

Janoz schreef op woensdag 16 januari 2019 @ 09:09:
[...]


TS heeft het over het opschalen van 1 handscanner naar meerdere. Dat is nog een heel stuk verwijderd van meerdere events die op verschillende lokaties gelijktijdig gehouden worden.

Volgens mij is dat het probleem niet, het probleem is meerdere scanners op 1 event

[Janoz]

Waarom kom je dan met een ingewikkelde oplossing aan om dat probleem op te lossen?