[Web] Goede website bouwen

(Dit zou kunnnen in [Centraal] HTML/CSS/Javascript, maar dit is erg specifiek)

Naar aanleiding van problemen metGoogle's Web Accelerator ben ik gaan nadenken over mijn huidige website design (kwa techniek).

Het probleem is dat websites gebruik maken van links om een bepaalde actie uit te voeren op een database, zoals het verwijderen van record. Een link is per definitie voor de browser (en server) een GET-method en zou derhalve niks mogen wijzigen in de database.
Uit RFC 2116 (met dank aan t.net):

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".

Om wijzigingen aan te brengen in de database moet je namelijk een POST method (oftewel een form) gebruiken.

Bovenstaande is niet zo moeilijk op te lossen. Echter, op heel veel forums (en websites waar je moet inloggen) wordt gebruik gemaakt van een sessie-id. Dit sessie-id wordt vaak meegenomen in de URL. Ook dit is niet goed, aangezien men zo gemakkelijk aan andermans sessie kan komen.

Verder is er ook nog het probleem van cookies. Ik heb voor mezelf besloten om geen cookies meer te gaan gebruiken op mijn eigen website(s). Zonder cookies wordt het moeilijker om bij te houden wie is ingelogd. Normaal gesproken lees in op de server de cookie uit van de client en weet je wie het is. Tevens zal in een dergelijk cookie een aantal andere gegevens staan, zoals tijdstip laats bekeken bericht. Op basis van dit bericht wordt een topic (bij een forum) al 'Gelezen' gemarkeerd.

Dit kan zonder cookies dus niet meer. Het probleem van gelezen/ongelezen topics heb ik al min of meer opgelost. De precieze uitwerking heb ik nog niet helemaal helder, maar het komt er op neer dat er in de URL van het topic een datum-tijd komt wat de laatste postdatum aangeeft (dus "http://forum.scholieren.com/Software& amp;Multimedia/1173225/20050508113806"). Op deze manier laat ik het aan de browser over om een URL als 'gelezen' te markeren, aangezien het a element een :visited pseudo-element heeft. Dit is namelijk veel netter tegenover de bezoeken. Op dit forum ben ik bijvoorbeeld nog nooit op ARTistiek geweest, maar alle topics staan daar wel op 'Gelezen'. Dit klopt naar mijn idee niet.

Even samengevat:

• Geen cookies
• Geen sessie-id in de URLs meegeven
• Een GET-method mag niks veranderen in de database

Problemen:

• Hoe kan ik leden laten posten zonder iedere keer 'in te loggen'
• Hoe koppel ik een gebruiker aan een server sessie
• Wil ik bovenstaande wel

Een kleine toelichting op het laatste punt:
Aangezien tcp/ip een connectie loos (de connectie wordt verbroken nadat de gegevens zijn verstuurd) communicatie middel is, kun je op de webserver standaard niet weten wie welke pagina heeft opgevraagd. Per definitie is er dus geen (eenvoudige) koppeling tussen client en server. Maar is die koppeling wel wenselijk? In princiepe wel. Gebruikers moeten immers de mogelijkheid hebben om te kunnen posten. Maar de realiteit is dat het onmogelijk is om te doen zonder gebruik te maken van cookies - en laat dat nou net één van de voorwaarden zijn van mijn toekomstige sites.

Wie heeft een idee over de problemen en de oplossingen? Wie ziet nog meer problemen en wil deze met mij delen?

Ik heb niet alles gelezen...

Maar is dat eigenlijk niet gewoon een Proxy.
En dat een GET niks mag veranderen is onzin, hoe wil je dingen als hits ed dan bijhouden? Je kan moeilijk voor alles een post doen..

[iamcj]

Ik weet er weinig van af maar:

http://www.phpfreaks.com/tutorials/41/3.php ?

Met deze methode (session_start(); ) geef je het sessionID toch niet mee aan de url?

iamcj schreef op 08-05-2005 @ 12:02 :
Ik weet er weinig van af maar:

http://www.phpfreaks.com/tutorials/41/3.php ?

Met deze methode (session_start(); ) geef je het sessionID toch niet mee aan de url?

Volgens PHP.net:

A visitor accessing your web site is assigned an unique id, the so-called session id. This is either stored in a cookie on the user side or is propagated in the URL.

Helaas dus.

********** schreef op 08-05-2005 @ 11:59 :
Ik heb niet alles gelezen...

Maar is dat eigenlijk niet gewoon een Proxy.

Je doelt hier op Google's Web Accelerator? Dat is een 'plug-in' voor je browser (IE, Firefox) die kijkt weaar je muiscursor is en wanneer je muis over een link beweegt vast een request stuur naar Google's Cache om de pagina vast te prefetchen. Google's stuurt de request naar de webserver om te verwerken. Wanneer je daadwerkelijk op de link klikt haal je het direct uit Google's Cache.

********** schreef op 08-05-2005 @ 11:59 :

En dat een GET niks mag veranderen is onzin, hoe wil je dingen als hits ed dan bijhouden? Je kan moeilijk voor alles een post doen..

Hits bijhouden. Dat is een goede. Bij een refresh heb je dus weer een nieuwe hit.

Misschien dat de webserver dat bij kan houden (dus niet je site)?

[Enlightenment]

GET wordt volop gebruikt voor acties. Zo heb ik ook links om bijvoorbeeld een forum omhoog of omlaag te schoppen bij het beheerspaneel. Zo heb je ook links die bij een webshop op "bestel" klikken etc. Hoe moet dat nu dan? Allemaal via een form? Dat is wel een stap terug in de tijd, vind ik.

Misschien is het huidige HTTP protocol wel achterhaald, en lopen we daar nu tegen de lamp.

Maar die Web accelerator vind ik ook wel gevaarlijk. Op het huidige internet is dat ding gewoon niet zonder risico te gebruiken, helaas.

Enlightenment schreef op 08-05-2005 @ 12:26 :
GET wordt volop gebruikt voor acties. Zo heb ik ook links om bijvoorbeeld een forum omhoog of omlaag te schoppen bij het beheerspaneel. Zo heb je ook links die bij een webshop op "bestel" klikken etc. Hoe moet dat nu dan? Allemaal via een form? Dat is wel een stap terug in de tijd, vind ik.

Dan is dat (dus) verkeerd. GET is nooit bedoeld voor acties. Forms met method="post" zijn daarvoor bedoeld.
Ik neem aan dat bij je beheerspaneel je een lijst (tabel) hebt met: forum, omhoog, omlaag (weet ik veel ). Je kan dan ipv de link er een input type="checkbox" van maken. Kun je er meerdere tegelijk doen. En als je er een type="text" van maakt, kun je zelfs nog een volgorde aangeven dmv 1, 2, 3, etc. Vervolgens kun je met de submit button het geheel doorvoeren

Enlightenment schreef op 08-05-2005 @ 12:26 :

Misschien is het huidige HTTP protocol wel achterhaald, en lopen we daar nu tegen de lamp.

Dat ben ik helemaal met je eens. Helaas moeten 'we' het daar nu nog wel mee doen.

Enlightenment schreef op 08-05-2005 @ 12:26 :

Maar die Web accelerator vind ik ook wel gevaarlijk. Op het huidige internet is dat ding gewoon niet zonder risico te gebruiken, helaas.

En dat komt door verkeerd gebruik van (o.a.) de GET method

[Manuzhai]

Eigenlijk is het hele issue dat circuleert gebaseerd op een stukje design; form-buttons zijn nou eenmaal maar niet zo mooi, maar wel iets dat gebruikt zou moeten worden voor requests die een wijziging in de database aanbrengen. Je kan de buttons tegenwoordig er makkelijk uit laten zien als een link, maar tegelijkertijd wil je je afvragen of dat wel de bedoeling is: is het dan nog wel duidelijk dat je iets verandert op de server voor de mensen.

Wat ik eigenlijk wil zeggen: er zijn twee issues hier - of software kan onderscheiden of het om een database-veranderende actie gaat, en of de gebruiker dat kan onderscheiden. Het verschil is dat er voor de gebruiker meestal ook wel een tekstuele of visuele clue is, terwijl je er voor de software juist vanuit moet gaan dat er altijd met een POST (of PUT, DELETE) gewerkt wordt.

Dat HTTP achterhaald is vind ik nogal ver gaan. Ergens (ik zat net een tijdje te zoeken, maar kan het nu niet terugvinden) heb ik zelfs gelezen dat een aantal issues die nu bij syndicatie opkomen perfect worden opgelost in HTTP. Er speelt echter natuurlijk wel het probleem dat HTTP als stateless protocol tegenwoordig in toenemende mate wordt gebruikt voor stateful applicaties.

Als je alles via POST methode moet zou gaan doen dan mis je ook een deel van de zoekmachine optimalisatie.
Zover mij bekend doet de googlebot niet aan POST en zal daar dus niet zoeken...

[Manuzhai]

********** schreef op 08-05-2005 @ 20:40 :
Als je alles via POST methode moet zou gaan doen dan mis je ook een deel van de zoekmachine optimalisatie.
Zover mij bekend doet de googlebot niet aan POST en zal daar dus niet zoeken...

Je mist het idee. De zoekmachine moet ook niet aan POST doen, omdat POST-acties wijzigingen aanbrengen. Het is natuurlijk niet de bedoeling dat een zoekbotje wijzigingen op sites aanbrengt. Dat maakt het ook zo gevaarlijk om wijzigende acties achter gewone GET-links te hangen. Anders zou in publieke omgevingen de Googlebot zomaar alle shizzle gaan verwijderen als er een Delete-linkje gebruikt werd.

Ik kan nog wel om het GET/POST probleem heen; dat is, voor mij, het probleem niet zo op het moment

Wat wel een probleem is, is het volgende

• Geen cookies
• Geen sessie-id in de URLs meegeven

Hoe kan ik dit het beste oplossen, om toch de gebruiker te identificeren wanneer deze een pagina opvraagt?

[Manuzhai]

eddie schreef op 09-05-2005 @ 09:06 :
Hoe kan ik dit het beste oplossen, om toch de gebruiker te identificeren wanneer deze een pagina opvraagt?

Je zou een sessie-ID in de POST-request kunnen zetten, dan staat het niet in een cookie en niet in de URL. Het is echter wel een lelijke oplossing, waarbij je geen normale links meer kan gebruiken.

Een manier om het te omzeilen (=dus geen oplossing) is misschien om user_agents te identificeren.

[Dr HenDre]

Misschien klinkt het stom, maar ik zie het nut niet van geen GET gebruiken voor acties. Ik bedoel als je get request kan faken kan je dat ook met post, dus echt veel veiliger is het niet. Dat t nu per definitie zo is wil het niet zeggen dat je t niet moet doen.

En het probleem met cookies is op zich ook niet al te moeilijk denk ik. Door zowel client side als server side cookies te gebruiken kan je de link leggen die je zoekt.
Je maakt een cookie bij de client met enkel een hash van zn ip en weet ik veel wat. Op de server zet je ook zon cookie met dezelfde hash en zn login gegevens bv. Op het moment dat iemand met zn hash je site bezoekt maak je een derde hash weer met zn ip en nog wat extra, en controleer je of ze overeenkomen. Als ik nu iemands cookie heb gejat met zijn ip erin als hash kan ik het niet meer gebruiken omdat op t moment dat ik inlog mijn ip als t ware wordt vergeleken. Om dit niet bij iedere pagina te doen kan je bv tijdelijk in de database opslaan dat een gebruiker is ingelogd voor laten we zeggen 15 min. Daarna controleer je het weer en weer.

denkfouten voorbehouden

edit:
je gebruikt dus toch cookies maar als het veilig is is dat toch geen probleem, lijkt me

Je ziet het nu niet van GET gebruiken voor acties?
Hoe denk je dat je over het forum browst?

[Kawoutertje]

Dr HenDre schreef op 09-05-2005 @ 11:36 :
Misschien klinkt het stom, maar ik zie het nut niet van geen GET gebruiken voor acties. Ik bedoel als je get request kan faken kan je dat ook met post, dus echt veel veiliger is het niet. Dat t nu per definitie zo is wil het niet zeggen dat je t niet moet doen.

Ik sluit me deels aan bij Dr HenDre. Ik begrijp best de bezorgdheid rond de veiligheid van het gebruiken van GET voor acties, maar ik denk ook dat je net zo goed een POST kan faken (Hoewel een GET faken wel net iets eenvoudiger is).

Ik denk dat het vooral belangrijk is dat je -zowel bij GET als bij POST- de authenticiteit van de gegevens controleert.
Dat je bijvoorbeeld bij een GET-actie controleert of de ingevoerde gegevens kunnen kloppen EN of de gebruiker in kwestie de permissie heeft om deze actie uit te voeren. (zo doe ik het momenteel althans)

Je POST-actie kan je op dezelfde manier controleren. Wat ik doe om dit te controleren, is op de pagina met het form op een bepaalde string te plaatsen die ik dan in een server-sessie zet. De pagina die de POST verwerkt weet welke string dat moet zijn, en kan alsvolgt eenvoudig nagaan of de data idd van de juiste pagina komt.
Bij mijn weten is dit vrij waterdicht, omdat deze string in je serverside-broncode staat en die dus nooit kan worden gelezen tenzij men gewoon de server hackt

Maar ik kan me vergissen

[Dr HenDre]

********** schreef op 09-05-2005 @ 11:43 :
Je ziet het nu niet van GET gebruiken voor acties?
Hoe denk je dat je over het forum browst?

Misschien klinkt het stom, maar ik zie het nut niet van geen GET gebruiken voor acties.

lezen blijft moeilijk

Kawoutertje schreef op 09-05-2005 @ 12:52 :
Ik sluit me deels aan bij Dr HenDre. Ik begrijp best de bezorgdheid rond de veiligheid van het gebruiken van GET voor acties, maar ik denk ook dat je net zo goed een POST kan faken (Hoewel een GET faken wel net iets eenvoudiger is).

Dat is waar ja, zonder get bescherm je je tegen rare scriptkiddies. Maar goed, je kan beter get wel gebruiken als het makkelijker is, en eht goed beveilien, dan post gebruiken en het neit goed beveiligen

Dr HenDre schreef op 09-05-2005 @ 11:36 :
Misschien klinkt het stom, maar ik zie het nut niet van geen GET gebruiken voor acties. Ik bedoel als je get request kan faken kan je dat ook met post, dus echt veel veiliger is het niet. Dat t nu per definitie zo is wil het niet zeggen dat je t niet moet doen.

Natuurlijk kun je veel faken. De probleem met GET acties is dat een GET meestal een link is in het document, wat door, in dit geval Google Web Accelerator, wordt geprefetched. Op het moment dat onder de link een actie zit als 'account opheffen' wordt dit dus direct uitgevoerd zonder dat de gebruiker er op heeft geklikt. Hetzelfde kan dus gebeuren bij zoekmachines e.d.

Dr HenDre schreef op 09-05-2005 @ 11:36 :

je gebruikt dus toch cookies maar als het veilig is is dat toch geen probleem, lijkt me

Juist wel. Ik wil af van cookies

[Manuzhai]

Kawoutertje schreef op 09-05-2005 @ 12:52 :
Ik sluit me deels aan bij Dr HenDre. Ik begrijp best de bezorgdheid rond de veiligheid van het gebruiken van GET voor acties, maar ik denk ook dat je net zo goed een POST kan faken (Hoewel een GET faken wel net iets eenvoudiger is).

Je gaat compleet voorbij aan het Punt. Het Punt is namelijk dat in de RFC van HTTP wordt gezegd dat een GET geen gevolgen mag hebben voor de staat van het systeem (dus geen acties mag uitvoeren). Door dit soort conventies weten bonafide systemen zoals zoekbotjes en Google Web Accelerator dat ze GET links rustig kunnen prefetchen. POST, PUT, DELETE e.d. zijn juist bedoeld om wel iets te veranderen, en daarom is de conventie dat die niet automatisch moeten worden gedaan (omdat de software niet begrijpt wat het "linkje" doet).

[iamcj]

Poging:

De links op je pagina laat je via een javascript lopen.

Als je een pagina uitgeeft, geef je daar een uniek id aan mee.
Als de gebruiker op een link klikt, roep je via javascript een functie aan die de user met de nieuwe pagina opnieuw registreert.

Als de pagina wordt gesloten log je die betreffende pagina weer uit.

iamcj schreef op 09-05-2005 @ 18:17 :
Poging:

De links op je pagina laat je via een javascript lopen.

Als je een pagina uitgeeft, geef je daar een uniek id aan mee.
Als de gebruiker op een link klikt, roep je via javascript een functie aan die de user met de nieuwe pagina opnieuw registreert.

Als de pagina wordt gesloten log je die betreffende pagina weer uit.

Dikke kans dat dit ook geladen wordt...

Maar het grootste probleem hiervan vind ik nog dat het ook niet geindexeerd wordt

iamcj schreef op 09-05-2005 @ 18:17 :
Poging:

De links op je pagina laat je via een javascript lopen.

Als je een pagina uitgeeft, geef je daar een uniek id aan mee.
Als de gebruiker op een link klikt, roep je via javascript een functie aan die de user met de nieuwe pagina opnieuw registreert.

Als de pagina wordt gesloten log je die betreffende pagina weer uit.

Hmm...

*denkt*

is dat niet ongeveer hetzelfde als een sessie-id meegeven in een URL?

********** schreef op 09-05-2005 @ 18:43 :
Dikke kans dat dit ook geladen wordt...

Maar het grootste probleem hiervan vind ik nog dat het ook niet geindexeerd wordt

Dat kan best, maar dat is pas de vierde on-topic reactie

[Manuzhai]

eddie, cookies zijn bedoeld om state bij te houden in het stateloze HTTP. Wat is daar mis mee?

Manuzhai schreef op 09-05-2005 @ 19:02 :
eddie, cookies zijn bedoeld om state bij te houden in het stateloze HTTP. Wat is daar mis mee?

Ten eerste:

User agents should send Cookie request headers (...) with every request.

Dus ook daar waar het niet nodig is (plaatjes, stylesheets, etc) komt het gehele cookie mee met het request.

In principe heb ik alleen maar de gebruikersidentificatie nodig op het moment dat deze een wijziging wil doen in de database (een post maken, aanpassen of verwijderen, een privébericht sturen, etc). Voor het tonen van een forum of een topic is in principe de identificatie niet noodzakelijk. Derhalve hoeft een cookie niet te worden gestuurd.

Ten tweede is het door de gebruiker mogelijk om cookies te weren. Nu kun je een discussie beginnen over dat de gebruiker de keuze moet hebben: indien hij geen cookies wil gebruiken kan hij geen gebruik maken van de functionaliteit - maar die wil ik nu niet voeren.

Ik probeer simpelweg een andere methode te vinden voor een cookie.
Mocht het echt niet willen/kunnen, dan moet ik goed nadenken over de cookie beveiliging (cookie-hijacking bijvoorbeeld). En over dergelijke beveiliging wil ik het nu ook niet hebben

Overigens vind ik het enigzins vreemd dat Google met deze 'uitvinding' komt...
Naar mijn idee is het eigenlijk gewoon een proxy, maar dan lokaal..

En daarnaast zie ik het nut er niet echt van in.
De internet snelheden zijn alsmaar groeiende geweest en dit blijft nog wel even doorgaan. Met de huidige snelheden vraag ik mij ook af wat nou het nut is van zo'n 'accelerator'.

[Engadin]

Als je een server bezoekt die aan een tampondraaidje hangt kan het wel handig zijn.... Maar ik zie veel meer nadelen dan voordelen.

[iamcj]

eddie schreef op 09-05-2005 @ 18:53 :
Hmm...

*denkt*

is dat niet ongeveer hetzelfde als een sessie-id meegeven in een URL?

Ja, maar dan zonder een sessie-id mee te geven in een url

Snap ook wel dat het niet ideaal is, maar soms breng je een ander weer is op een idee.

Kun je ook niet iets met een ip-adres of zoiets dergelijk, kun je de hwnd van de userwindow niet bijhouden? Heeft een computer geen unieke identificatie, die hij meestuurt?

iamcj schreef op 09-05-2005 @ 21:32 :
Ja, maar dan zonder een sessie-id mee te geven in een url

Jah, de url vang je dan af en plak je er alsnog een sessie-id aan

Trouwens, gebruikers kunnen javascript uit hebben staan.

iamcj schreef op 09-05-2005 @ 21:32 :
Snap ook wel dat het niet ideaal is, maar soms breng je een ander weer is op een idee.

Dat is zeker waar.

iamcj schreef op 09-05-2005 @ 21:32 :

Kun je ook niet iets met een ip-adres of zoiets dergelijk, kun je de hwnd van de userwindow niet bijhouden? Heeft een computer geen unieke identificatie, die hij meestuurt?

IP adres gaat niet; denk hierbij aan school-, bedrijfs- en thuisnetwerken.
De hwnd kan ik helaas niet opvragen aan de serverkant.
Een MAC adres zou een unieke identificatie kunnen zijn, maar dan zit ik weer met de netwerken.

Ik wil net zoiets eenvoudigs als ik in mijn TS heb gezegd over de 'Gelezen' status. Zoiets ligt voor de hand, maar je moet er maar op komen. *klopt zichzelf op schouder*

Verder is het mijn bedoeling om alleen gebruikersidentificatie te hebben op pagina's waar het nodig is, zoals het posten van een bericht. Op enig ander pagina is het niet nodig, aangezien de informatie daarop niet afhankelijk is van de gebruiker (tenzij er met 'negeerlijsten' wordt gewerkt, maar dat is weer een ander verhaal...)

[Manuzhai]

eddie schreef op 09-05-2005 @ 21:04 :
In principe heb ik alleen maar de gebruikersidentificatie nodig op het moment dat deze een wijziging wil doen in de database (een post maken, aanpassen of verwijderen, een privébericht sturen, etc). Voor het tonen van een forum of een topic is in principe de identificatie niet noodzakelijk. Derhalve hoeft een cookie niet te worden gestuurd.

Dan moet je scripts die wel een sessie nodig hebben in een apart gedeelte van je path zetten, en het cookie beperken tot dat path van je site... Dan wordt ie niet meer meegestuurd voor de rest.

Voor de rest zie ik de lol van deze onderneming nog steeds niet in.

Manuzhai schreef op 10-05-2005 @ 10:53 :
Voor de rest zie ik de lol van deze onderneming nog steeds niet in.

Het heeft (o.a.) te maken met de geile Google Web Accelerator.

Deze cached/prefetched volgens mij ook de cookies e.d.

Verder vind ik cookies niet 'mooi' voor een website, net zoals sessie-id's in de link.

Wat ik me afvraag: Hoe werkt HTTPS/SSL? Volgens mij heb je daar geen sessies of cookies nodig en weet de server zelf wie verbonden is. Toch?

[Enlightenment]

HTTP over SSL is een keep-alive verbinding. Dus je blijft verbinding houden. Misschien heeft dat er wat mee te maken?

Enlightenment schreef op 11-05-2005 @ 20:35 :
HTTP over SSL is een keep-alive verbinding. Dus je blijft verbinding houden. Misschien heeft dat er wat mee te maken?

Ah. Dat zou kunnen. Zoiets lijkt me niet handig voor een forum a la scholieren.com. Beetje belastend voor de server enzo, kwa connecties