[JS/HTML]Poll/enquete verwerking zonder server

[henkleerssen]

Ik probeer met een programma (niet in .net taal geschreven btw maar dat maakt verder hier niet uit) JS/HTML form uit te laten spugen in de vorm van een enquete of poll.
Ik dacht tot nu toe dat dit JS/HTML form het beste desgewenst per mail wordt verstuurd of gewoon op een webserver gezet (Enquete/poll format is dat deze tot 100 stellingen kan hebben waar met +/- 25 gevoelens op gescoord kan worden op een 6 punts schaal.. dus vragenlijst invuller kan maximaal 25 * 100=2500 waarden invullen).

Omdat het vertrouwelijke info is en het alle schijn niet kan hebben dat het niet veilig is .. geen server side verwerking voor mij (of toch met SSL?? .. of ben ik te paranoia?).
Ik heb op hotscripts.com gekeken bij form processors (http://www.hotscripts.com/Remotely_Hosted/Form_Processors/) maar dan gaat het een en ander via een server (en ook nog eens van een ander.. die oplossing zijn er genoeg btw).
De oplossing die ik nog toe heb gezocht en nog zoek is dus NIET Server Side Form Processing (zoals vrij gangbaar PHP met mysql etc... lijkt me eigenlijk al te ingewikkeld voor dit probleem) of any kind.

Nou heb ik de search al gebruikt (Waar vind ik online poll? bijvoorbeeld), maar nog steeds niet het antwoord op mijn vraag gekregen.
Dit is verder geen script request ...maar gewoon het aftasten van mogelijkheden voor dit specifieke poll/enquete probleem (met betrekking tot veiligheid, makkelijke implementatie en zo goedkoop mogelijk; ennuh.. een url verwijzing http://poll.dezeserver.nl/ lijkt me dus ook niet de oplossing ennnn een huge formulier met maximaal 2500 vragen lijkt me dat ook al niet).
Ik dacht ook nog een klein client progje te maken voor de vragenlijst invuller ... maar het zou toch het beste zijn via een website.

Wie oo wie heeft wat hints (en wie heeft hier ervaringen mee)?

btw kennis van HTML/CSS is prima ... javascript redelijk.

[André]

In het geval van een website: zonder serverside kant kun je het schudden want je kunt je gegevens van de client nergens heensturen. De enige andere oplossing is een zelfgemaakte tool die over een beveiligde verbinding alles ge-encrypt verstuurd.

Ik zou aanraden om gewoon serverside code te gebuiken eventueel icm https

[ Voor 15% gewijzigd door André op 05-10-2005 08:33 ]

[henkleerssen]

André schreef op woensdag 05 oktober 2005 @ 08:33:
In het geval van een website: zonder serverside kant kun je het schudden want je kunt je gegevens van de client nergens heensturen. De enige andere oplossing is een zelfgemaakte tool die over een beveiligde verbinding alles ge-encrypt verstuurd.

Ik zou aanraden om gewoon serverside code te gebuiken eventueel icm https

nergens heensturen? in geval van form submit mailto: ref maken zou toch moeten kunnen?
Die beveiligde site.. had ik ook al aangedacht.. maar aan de andere kant heb ik met die enquete invullers met technische nitwits te maken.. IE "Blocked content" en firewall settings veranderingen (voor het accepteren van verbinding met internet met mijn eventuele progje) gaat hen al veel te ver...

[wizzkizz]

henkleerssen schreef op woensdag 05 oktober 2005 @ 09:20:
[...]

nergens heensturen? in geval van form submit mailto: ref maken zou toch moeten kunnen?
Die beveiligde site.. had ik ook al aangedacht.. maar aan de andere kant heb ik met die enquete invullers met technische nitwits te maken.. IE "Blocked content" en firewall settings veranderingen (voor het accepteren van verbinding met internet met mijn eventuele progje) gaat hen al veel te ver...

SSL wordt imho vrijwel nergens geblokt (of mss in bedrijfsomgevingen, ben ik het wel eens tegengekomen). Inetbankieren maak ook gebruik van SSL, dat is toch ook voor de 'normale' computergebruiker geen probleem (althans, ik heb er in de familie/buurt nog nooit problemen mee gehad). Default wordt SSL gewoon ondersteund.

En een email is volgens mij nog _vele malen_ onveiliger dan een form over SSL. email komt langs tig servers en kan dus op evenveel plaatsen opgeslagen en bekeken worden. Ik zou ook een form, al dan niet via SSL, aanraden hoor

[henkleerssen]

wizzkizz schreef op woensdag 05 oktober 2005 @ 10:33:
[...]

SSL wordt imho vrijwel nergens geblokt (of mss in bedrijfsomgevingen, ben ik het wel eens tegengekomen). Inetbankieren maak ook gebruik van SSL, dat is toch ook voor de 'normale' computergebruiker geen probleem (althans, ik heb er in de familie/buurt nog nooit problemen mee gehad). Default wordt SSL gewoon ondersteund.

En een email is volgens mij nog _vele malen_ onveiliger dan een form over SSL. email komt langs tig servers en kan dus op evenveel plaatsen opgeslagen en bekeken worden. Ik zou ook een form, al dan niet via SSL, aanraden hoor

het is idd een manier.. maar das nog steeds server side.. Ik zat te denken om HTML anders te encrypten.. maar das ook weer niet veilig genoeg.
Het formulier zou alleen bepaalde data hoeven te versturen (de antwoorden eenmaal ingevuld) .. daar valt weinig soep van te maken.
Trouwens ook een reden om het NIET server side te doen is.. dat het wel eens teveel traffic zou genereren die me weer teveel zou kunnen gaan kosten... dubbeltje op de eerste rang he..

[André]

Via de mail met een mailto zou ik sowieso afraden:
http://www.isolani.co.uk/articles/mailto.html

Mailto moet je nooit gebruiken.

[henkleerssen]

André schreef op woensdag 05 oktober 2005 @ 10:49:
Via de mail met een mailto zou ik sowieso afraden:
http://www.isolani.co.uk/articles/mailto.html

Mailto moet je nooit gebruiken.

Hele goeie om te weten (Am i inexperienced? .. ).. gewoon toch maar een php scriptje om mail te versturen (meer hoeft niet lijkt me Server side)?

[wizzkizz]

henkleerssen schreef op woensdag 05 oktober 2005 @ 11:02:
[...]

Hele goeie om te weten (Am i inexperienced? .. ).. gewoon toch maar een php scriptje om mail te versturen (meer hoeft niet lijkt me Server side)?

Als je toch php gaat gebruiken, waarom maak je dan niet in 1 keer ook een script om de data te vewerken? Nu moet je zelf handmatig alle enquetes gaan analyseren of invoeren in een analyseprogramma.

PHP kan in dat geval veel werk uit handen nemen door het simpelweg op te slaan in een database en afhankelijk van de manier van analyse resultaten te genereren (dus ofwel data om te importeren in je analyseprogramma ofwel zelf een aantal (simpele) statistische analyses maken in PHP).

Hierboven gaf je aan de veiligheid van je enquete erg belangrijk te vinden. Als je overweegt om het via e-mail te sturen, moet je dit eens lezen. Met behulp van de source in je enqueteform is dat toch een niet al te grote opgave voor een beetje hacker (bij een redelijke beveiliging van je database is dat laatste zeker moeilijker te kraken).

[ Voor 22% gewijzigd door wizzkizz op 05-10-2005 18:34 . Reden: addendum over veiligheid email ]

[henkleerssen]

tja zoals het er nu naar uit ziet wordt het ongeveer zo'n oplossing (niet de mooiste flow.. links boven beginnen): Klikerdeklik

Het wordt wel alweer een ingewikkeld verhaal zo. Server side scripting en veel trafficwil ik eigenlijk niet (ik wil de controle houden over bepaalde resultaten met mijn programmatje (F)). Wordt ook uitgebreide analsye toegepast met graphics en zo.. vandaar geen PHP ook.
De vraagtekens in het schema hierboven ben ik dus nog niet over uit (das nou net rond het webgedeelte).
Ik wil nergens eigenlijk een database bijhouden ..Dat moet de gebruiker (Y) maar doen met zijn programmatje (Z).
Eigengemaakte encryptie wordt al toegepast. Ook rond eventueel email verkeer.

[ Voor 11% gewijzigd door henkleerssen op 05-10-2005 20:57 ]

[wizzkizz]

henkleerssen schreef op woensdag 05 oktober 2005 @ 20:54:
tja zoals het er nu naar uit ziet wordt het ongeveer zo'n oplossing (niet de mooiste flow.. links boven beginnen): Klikerdeklik
[afbeelding]
Het wordt wel alweer een ingewikkeld verhaal zo. Server side scripting en veel trafficwil ik eigenlijk niet (ik wil de controle houden over bepaalde resultaten met mijn programmatje (F)). Wordt ook uitgebreide analsye toegepast met graphics en zo.. vandaar geen PHP ook.
De vraagtekens in het schema hierboven ben ik dus nog niet over uit (das nou net rond het webgedeelte).
Ik wil nergens eigenlijk een database bijhouden ..Dat moet de gebruiker (Y) maar doen met zijn programmatje (Z).
Eigengemaakte encryptie wordt al toegepast. Ook rond eventueel email verkeer.

Ik denk dat ik het niet helemaal snap hoe je het wil doen en eig ook weer wel

Een van de grote voordelen van een webbased app is dat de gebruiker er geen software voor hoeft te installeren. Als ik het zo zie wil jij de gebruiker wél een aparte app voorschotelen die geinstalleerd moet worden en daarna de resultaten upload naar een server. Kun je het écht niet in de browser realiseren?

Daarnaast snap ik je punt over zo weinig mogelijk server-side verwerking niet echt. Daar heb je opzich geen last van en zolang je geen extreme dingen gaat doen boeit dat voor jou absoluut niet.
Eveneens voor traffic en database? Zolang je enquete niet te veel grote afbeeldingen bevat (dus grotendeels plain text), is het dataverkeer echt minimaal hoor. Kun je met 1 gb toch behoorlijk wat enquetes serveren en verwerken.

Tevens bespaar je met een server-side generatie van de data om te importeren in je analyseprog een heleboel tijd. Het valt echt niet mee om een 100 vragen per enquete een paar honderd keer handmatig in te voeren. Dat kun je dan echt veeeeeel makkelijker oplossen door de data in een db op te slaan en met php een bestandje te genereren om te importeren.

Of heb je een hostingaccount die dat (server-side scripting en databases) niet ondersteunt

[henkleerssen]

wizzkizz schreef op donderdag 06 oktober 2005 @ 00:36:
[...]

Ik denk dat ik het niet helemaal snap hoe je het wil doen en eig ook weer wel

Een van de grote voordelen van een webbased app is dat de gebruiker er geen software voor hoeft te installeren. Als ik het zo zie wil jij de gebruiker wél een aparte app voorschotelen die geinstalleerd moet worden en daarna de resultaten upload naar een server. Kun je het écht niet in de browser realiseren?

aparte app zowel aan mijn kant als die bij gebruiker Y is al bijna een voorwaarde. Daar kom ik niet om heen. Dat hebben die gebruikers graag .. tja. En eigenlijk ik ook wel.

Daarnaast snap ik je punt over zo weinig mogelijk server-side verwerking niet echt. Daar heb je opzich geen last van en zolang je geen extreme dingen gaat doen boeit dat voor jou absoluut niet.
Eveneens voor traffic en database? Zolang je enquete niet te veel grote afbeeldingen bevat (dus grotendeels plain text), is het dataverkeer echt minimaal hoor. Kun je met 1 gb toch behoorlijk wat enquetes serveren en verwerken.

Je hebt gelijk... maar ik heb dus wel verschillende graphics.. die ik al met enige moeite heb moeten proggen.. Omdat nu weer om te schrijven naar PHP/GDI zie ik niet zo zitten.

Tevens bespaar je met een server-side generatie van de data om te importeren in je analyseprog een heleboel tijd. Het valt echt niet mee om een 100 vragen per enquete een paar honderd keer handmatig in te voeren. Dat kun je dan echt veeeeeel makkelijker oplossen door de data in een db op te slaan en met php een bestandje te genereren om te importeren.

Ik zie nu niet in waar ik meer tijd mee kan winnen. Eeuh wie heeft het over handmatig invoeren of verwerken? Enige persoon die veel voor zijn kiezen krijgt is de invuller (die er zelf voor gekozen heeft btw). dussum.

Of heb je een hostingaccount die dat (server-side scripting en databases) niet ondersteunt

[/quote]
zeker wel... maar ondertussen om het en ander weer anders te bedenken... tja.
btw ik ben een reseller van wat hosting .. dus als ik aan de ene kant wat traffic af snoep .. dan hebben andere (potentiele) klanten minder traffic.. vandaar.
Het is alleen de vraag hoe ik het een en ander ga doen naar zo'n webserver toe. Dat moet zo makkelijk mogelijk blijven maar toch veilig. De vraagtekens zijn dus nog een beetje onbeantwoord ondertussen.

[wizzkizz]

oh, omdat je het had over e-mailen van de resultaten d8 ik dat je die dan handmatig toe ging voegen in je prog. Blijkbaar verkeerd begrepen.

En dat verbinden zou ik nog steeds over een SSL-beveiligde verbinding met je webserver doen. ik ben nog geen firewall tegengekomen die standaard https blokkeerde

Je zou in je app ook IE (of de default browser) kunnen (ge/mis)bruiken om de resultaten te versturen, dan heb imho de minste kans op problemen, behalve bij een firewall die dat detecteert en een snel op 'nee' klikkende gebruiker die verder niet weet wattie doet.

Het probleem met client-side apps is dat je altijd bepaalde assumpties moet doen over het systeem van de gebruiker (OS: window? linux? mac OS? nog anders?; firewall? Hoe streng geconfigureerde firewall? geen firewall? enzo) en het niveau waarop de gebruiker met de computer kan omgaan.

[henkleerssen]

wizzkizz schreef op donderdag 06 oktober 2005 @ 10:47:
oh, omdat je het had over e-mailen van de resultaten d8 ik dat je die dan handmatig toe ging voegen in je prog. Blijkbaar verkeerd begrepen.

Gebruiker Y zal misschien een keer een e-mail adres invullen maar that's it.

En dat verbinden zou ik nog steeds over een SSL-beveiligde verbinding met je webserver doen. ik ben nog geen firewall tegengekomen die standaard https blokkeerde

Is ook zo.. Moet ff kijken hoe ik SSL dat zou moeten doen.. maar das meer zoekwerk.. niet voor hier.

Je zou in je app ook IE (of de default browser) kunnen (ge/mis)bruiken om de resultaten te versturen, dan heb imho de minste kans op problemen, behalve bij een firewall die dat detecteert en een snel op 'nee' klikkende gebruiker die verder niet weet wattie doet.

Zat ik ook ff aan te denken: een php form om een ftp upload te doen of zo. weet ik nog niet.

Het probleem met client-side apps is dat je altijd bepaalde assumpties moet doen over het systeem van de gebruiker (OS: window? linux? mac OS? nog anders?; firewall? Hoe streng geconfigureerde firewall? geen firewall? enzo) en het niveau waarop de gebruiker met de computer kan omgaan.

Ik ga er vanuit dat 97% van de gebruikers gewoon windows gebruikers zijn. 2% misschien mac. Voor hen heb ik misschien op termijn ook wel een oplossing. Het zijn allemaal ruwe schattingen ..maar bij de gebruikers is dat eenmaal zo.

Ennuh.. bedankt allemaal alvast he .. voor jullie inbreng. Ik waardeer het!

[T-MOB]

Ik snap werkelijk waar niet waarom je zo moeilijk aan het doen bent. Wat je ook maakt, je zal op een gegeven moment de gegevens moeten versturen naar jezelf. Het unencrypted versturen van een zelfgebouwde client naar een zelfgebouwde server is daarbij even kwetsbaar als het posten van een HTML-form naar een php script. Wil je het veilig doen dan heb je encryptie nodig. Punt.

HTML/PHP met SSL is daar uitermate geschikt voor, het werkt out-of-the-box bij iedereen en is ook nog in een spreekwoordelijke zucht aan het werk te krijgen. Kortom, waarom maak je het jezelf zo ingewikkeld?

[henkleerssen]

zei ik ergens dat ik geen encryptie gi gebruiken? Ik moet ff rondkijken hoe ik met php het een en ander moet oplossen...ik kom er wel uit. Die apps ben gebruikers kom ik bijna niet onderuit.Misschien lijkt het allemaal simpel voor je...ik zit alleen vast aan randvoorwwaarden , tenzij jij ook out of the box een fullfledged met uitgebreide analyse mogelijkheden php module kan vinden...

[T-MOB]

henkleerssen schreef op donderdag 06 oktober 2005 @ 13:28:
zei ik ergens dat ik geen encryptie gi gebruiken?

Nee, dat zei je niet en dat beweerde ik ook niet. Wat ik je probeer duidelijk te maken is dat SSL een zeer geschikte encryptiemethode is voor je probleem. Het is een beproefde methode die door al je gebruikers ondersteund zal worden. Daarnaast bestaan er al out-of-the box implementaties van voor verschillende webservers.

Ik moet ff rondkijken hoe ik met php het een en ander moet oplossen...ik kom er wel uit. Die apps ben gebruikers kom ik bijna niet onderuit.Misschien lijkt het allemaal simpel voor je...ik zit alleen vast aan randvoorwwaarden , tenzij jij ook out of the box een fullfledged met uitgebreide analyse mogelijkheden php module kan vinden...

Voor de analyse zou ik niet zelf een oplossing verzinnen. Daarvoor heb je gespecialiseerde software zoals SPSS. Het enige dat je dan met PHP hoeft te doen is de data opslaan die er binnenkomt op een manier die te importeren is in je analyseprogramma. Het meest eenvoudige is dan in een comma-seperated textfile. Die kun je on-the-fly aanpassen als er een enquête binnenkomt of met tussenkomst van een databeest.
Dit is zo eenvoudig als het klinkt en ik vraag me dan ook af wat voor randvoorwaarden er zijn die een ingewikkelde oplossing noodzakelijk maken. Bandbreedte kan geen issue zijn aangezien de enige data die op deze manier verstuurd wordt bestaat uit 1. de enquête richting respondent en 2. de ingevoerde gegevens richting de server. Dat is data die sowieso verstuurd moet worden wil je een enquête afnemen.

[henkleerssen]

T-MOB schreef op donderdag 06 oktober 2005 @ 15:18:
[...]

Nee, dat zei je niet en dat beweerde ik ook niet. Wat ik je probeer duidelijk te maken is dat SSL een zeer geschikte encryptiemethode is voor je probleem. Het is een beproefde methode die door al je gebruikers ondersteund zal worden. Daarnaast bestaan er al out-of-the box implementaties van voor verschillende webservers.

Dacht ik ook.. heb je toevallig wat url's?

Voor de analyse zou ik niet zelf een oplossing verzinnen. Daarvoor heb je gespecialiseerde software zoals SPSS. Het enige dat je dan met PHP hoeft te doen is de data opslaan die er binnenkomt op een manier die te importeren is in je analyseprogramma. Het meest eenvoudige is dan in een comma-seperated textfile. Die kun je on-the-fly aanpassen als er een enquête binnenkomt of met tussenkomst van een databeest.

Nou .. mijn software is al voorzien van statistisch analyse methoden (daar hoef ik en anderen alvast niet meer naar om te kijken.. SPSS is dan niet meer nodig .. ken dat programma ook). Heb ik allemaal zelf lopen proggen.. gedeeltelijk was dat het wiel opnieuw uitvinden .. maar ach..

Dit is zo eenvoudig als het klinkt en ik vraag me dan ook af wat voor randvoorwaarden er zijn die een ingewikkelde oplossing noodzakelijk maken. Bandbreedte kan geen issue zijn aangezien de enige data die op deze manier verstuurd wordt bestaat uit 1. de enquête richting respondent en 2. de ingevoerde gegevens richting de server. Dat is data die sowieso verstuurd moet worden wil je een enquête afnemen.

Die randvoorwaarde van een stand alone app bij mij en gebruikers is op dit moment een vrij zware voorwaarde. Maar op termijn misschien dat ik en de gebruikers er anders over gaan denken.
Maar ik zal het zeer zeker meenemen bij de overweging van toekomstige veranderingen.
thnx..