technische uitgangspunten
Een beetje een lang bericht, maar ik hoop dat jullie me wat bruikbare adviezen kunnen geven.
Het punt is (eindelijk) daar dat ik nu concreet ga beginnen met het programmeren van m'n cms. Nu zit ik even met een paar gedachten betreffende de technische uitgangspunten waaraan het CMS moet voldoen en dan met name het gebruik van:
1) javascript (en ajax)
2) cookies (en sessies)
1) javascript
Ik zou in mijn cms graag gebruik maken van javascript om 2 redenen. Enerzijds om de usability te verbeteren, anderzijds om AJAX mogelijk te maken. Voor beide zaken is het gebruik van javascript noodzakelijk.
Ik heb dit onderwerp al eens eerder aangesneden. Een jaar geleden zei men hier op het forum dat een website niet afhankelijk moet zijn van javascript. Met andere woorden: een website moet ook zonder javascript goed kunnen werken. Echter, enkele maanden geleden was deze mening gewijzigd en was de mening op het forum dat vrijwel iedereen javascript heeft ingeschakeld en zo niet, dan hebben die gebruikers "pech".
Wat is het voordeel als ik het systeem ook zonder javascript laat werken?
Het systeem werkt overal op ieder systeem en vanaf iedere locatie (ook op openbare locaties waar javascript is uitgeschakeld).
Wat is het nadeel als ik het systeem ook zonder javascript laat werken?
Alles moet "dubbel" worden uitgevoerd. Bij alles wat je doet, moet je voorzieningen treffen om het ook zonder javascript werkend te krijgen. Dit kost enorm veel extra werk en tijd.
MIJN IDEE
Op de loginpagina ga ik afvangen of javascript is ingeschakeld. Hoe? Door het loginscherm via javascript toonbaar te maken (via een write functie, of door het loginscherm op display none te zetten en via javascript op display block. Sugesties zijn welkom!). Als javascript is ingeschakeld ziet men het loginscherm. Als javascript NIET is ingeschakeld, ziet men het loginscherm niet en zal ik via <noscript> een melding tonen dat men javascript moet inschakelen om een goede werking van het systeem te waarborgen. Dit betekent dat mensen die javascript niet hebben ingeschakeld ook niet kunnen inloggen. Van de ene kant "onvriendelijk", van de andere kant wel heel erg duidelijk. Wat vinden jullie van dit idee?
2) cookies
Voor cookies geldt hetzelfde. Als cookies niet zijn ingeschakeld, dan kun je geen gebruik maken van sessies (immers, het sessie-id kan niet worden opgeslagen). Dat je geen gebruik kunt maken van sessies, vind ik geen optie. Ik zou daarom met cookies hetzelfde kunnen doen als met javascript. Heeft men geen cookies ingeschakeld, dan kan men niet inloggen. Ook hiervan hoor ik graag jullie mening.
Ik heb ook nog een specifieke vraag over sessies. Ik heb een keer meegemaakt dat ik een webshop moest maken die in een andere website werd geinclude in een i-frame. En dan blijken je cookies dus ineens niet meer te werken... en dus ook je sessies niet! Ik heb toen het sessie-id in de url meegestuurd en toen werkte het wel. Nu is mijn vraag... moet ik in mijn cms rekening houden met deze situatie? Vanuit veiligheidsoverwegingen ben ik er niet bepaald een voorstander van om het sessie-id via de url mee te sturen. Men kan namelijk via de url heel simpel de sessie-id veranderen en zo proberen om iemand anders sessie over te nemen. Of dit in de praktijk zal lukken weet ik niet, maar het is wel een risico. In de situatie met het i-frame kon het helaas niet anders. Maar nu vraag ik me dus wel af of ik deze optie standaard in mijn cms moet inbouwen, of is dit iets wat je eigenlijk niet moet willen? Sterker nog... zou ik in een toekomstige situatie moeten weigeren om mijn site te laten includen in een i-frame?
Het is een beetje een lang bericht geworden, maar ik hoop dat jullie wat bruikbare tips voor me hebben. Met name ben ik benieuwd wat jullie vinden van het idee om een "waarschuwingstekst" te tonen als men geen javascript / cookies heeft ingeschakeld en ervoor te zorgen dat men in dat geval niet kan inloggen. Let wel, dit idee geldt alleen voor het cms (back-end) deel van de website en niet voor de normale (front-end) bezoekers.
Graag jullie reacties! :-)
Gesponsorde koppelingen:
Over cookies, je kunt cookies gebruiken, maar je kunt ook sessies gebruiken. Cookies heb je als voordeel dat ze fysiek opgeslagen worden en ook fysiek op te halen zijn met als nadelen dat ze kunnen worden uitgeschakeld en dat ze gemanipuleerd kunnen worden.
Sessies heeft als voordeel dat ze werken, los van cookies en dus tijdens een sessie makkelijk te benaderen zijn. Nadeel is dat je ze niet kunt doorgeven aan secundaire vensters, sessies.
In beide gevallen zul je een afweging moeten maken die in jou ogen de beste is. Op beide punten heb je goede argumenten voor en tegen. Zo heb je bijvoorbeeld AJAX only frameworks die compleet op ajax draaien, terwijl je aan de andere kant natuurlijk ook gewoon "normale" frameworks en CMSen hebt die gewoo op request basis werken. Beide werken, de een heeft echter als grondgetal Javascript de ander niet. Dat betekent niet dat X beter is dan Y of Y slechter is dan Z.
Cookies over sessies of vice versa is ook rationeel gezien persoonlijke voorkeur. Ik gebruik persoonlijk alleen maar sessies en bijna nooit cookies. Ik heb liever een alternatief op cookies die altijd werkt.
"Sessies heeft als voordeel dat ze werken, los van cookies en dus tijdens een sessie makkelijk te benaderen zijn."
Dit klopt dus niet. Sessies gebruiken een cookie waarin de sessie-id wordt opgeslagen. Anders herkent de server de browser niet. Om sessies te laten werken, moeten cookies dus zijn ingeschakeld.
Dat gaat ook gepaard met aparte cookies en sessies.
Je kan gelijk welke website in een iframe steken, bv. ook Google. Dat maakt uiteraard niet dat jij daarmee toegang hebt tot de Google sessies...
Javascript (on)afhankelijkheid:
Ik denk dat het een vrij goed idee is om elementen te verbergen, als ze enkel met javascript werken, om dan bij het laden van de pagina zichtbaar te maken.
bv. elk van zo'n element geef je class="javascript", met als css display none (zoals je zelf ook voorstelt voor die checkbox)
Met jQuery geeft dat simlpelweg
Code (php)
1
2
3
2
3
$(function(){
$('.javascript').css('display', 'block');
});
$('.javascript').css('display', 'block');
});
Ik denk ook dat je vooral een verschil moet maken tussen de gewone gebruiker (misschien toch niet javascript-afhankelijk maken) en de moderatoren/contributers.
Van die laatste groep mag je wel verwachten dat ze maar een browser met javascript hebben (nu ja, dat sugereer je zelf ook wel wat).
dubbel werk:
Sowieso, wanneer je met javascript valideert (vooral dan formulieren), moet je de validering in php over doen. Zelfs van moderatoren.
't zijn maar wat losse gedachten die in me opkomen
Ik vind jou oplossing goed, al zou ik de echte code anders doen. Een website moet gewoon gebruik maken van JS en heb je dat uit staan, dan heb je pech. Die moeten een melding krijgen en hun JS aanzetten. Anders kunnen ze er geen gebruik van maken. Al denk ik dat er heel weinig mensen JS echt uit hebben staan (ik zou eigenlijk wel een testje willen doen, bezoekers op 1 pagina tellen met PHP en met JS en dan kijken wat de verschillen zijn na een week).
Een voorbeeldje hoe ik JS zou afvangen: http://jsbin.com/avireh/2 (klik op edit in jsbin rechtsboven voor de code)
Gewijzigd op 06/02/2012 10:18:24 door Wouter J
Wat vind jij van het meesturen van de sessie-id in de url? (in geval cookies niet zijn ingeschakeld?) Of gewoon de cookies ook verplicht stellen, hetzelfde als bij javascript??
Maar, voor alle andere (dus niet-sessie) cookies zou ik de gebruiker zelf laten bepalen of hij die wilt toestaan. En dan niet via de browser, maar via de instellingen van je website. Dit gaat in de toekomst waarschijnlijk toch verplicht worden via de overheid, dus waarom daar niet al mee beginnen?
Als de gebruiker cookies helemaal heeft uitgeschakeld kan hij niet inloggen. Dat hoef jij niet te controleren, dat kan gewoon niet, omdat die sessie cookie niet kan worden ingesteld.
Alle andere cookies zijn per definitie geen sessie cookies, want die zet jij zelf. Met uitzondering wellicht van een cookie die je wilt gebruiken voor permanente login.
Daar heb je een goed punt. Echter, ik wil de gebruiker wel laten weten dat hij niet kan inloggen omdat hij zijn cookies uit heeft staan. Maar, dat is inderdaad een leuke... want... je doet een pagina-aanroep, de gebruikersnaam en het wachtwoord worden gecontroleerd. Stel dat ze kloppen dan zou in de sessie iets worden opgeslagen waaruit blijkt dat hij is ingelogd. Echter, we hebben geen sessie, dus er wordt ook niks opgeslagen!
Maar dat betekent dus ook dat ik nooit kan controleren of hij z'n sessie-cookies wel of niet heeft aanstaan. Om dit te controleren zou ik namelijk via een header de pagina opnieuw moeten aanroepen en kijken of de sessie-cookie geset is. Maar dan moet PHP wel weten dat de pagina opnieuw is aangeroepen. Dit zou je normaal kunnen regelen via de sessie... maar aangezien die niet werkt! Hahaha... :-)))
Volgens mij kan je dus nooit controleren of er een sessie-cookie aanwezig is. Of zie ik iets over het hoofd nu?
Ga er van uit dat iemand die niet ingelogd is geen sessies nodig heeft, en dus je site als read-only ziet.
Wel ingelogd -> cookies staan sowieso aan.
Stel je voor, jij krijgt van mij een gebruikersnaam en wachtwoord. Vervolgens probeer je in te loggen en het werkt niet. Je hebt echter geen idee waarom het niet werkt. Ik zou dan graag een melding willen tonen dat het niet werkt omdat de cookies niet zijn ingeschakeld.
Heel stom dat ik daar niet aan heb gedacht, maar ik kan natuurlijk gewoon een andere url aanroepen!
Dus men gaat naar /login men klikt op de knop om de inloggegevens te versturen en ik vang die bijv. op in /login/check. Als die url wordt aangeroepen dan weet ik dat ik een sessie zou moeten hebben. Zo niet, dan werken de cookies dus niet :) En wellicht kan het nog mooier door vanuit /login een header te geven naar /login/check dan krijgen ze meteen al die melding.
Soms is het zo simpel :)
Wouter J op 06/02/2012 10:15:38:
Een website moet gewoon gebruik maken van JS en heb je dat uit staan, dan heb je pech. Die moeten een melding krijgen en hun JS aanzetten. Anders kunnen ze er geen gebruik van maken.
Dit is ook simpel (gedacht). Dus alle searchbots hebben ook pech!
Veelal heeft javascript betrekking op usability zaken, dus of zo'n searchbot daar veel van merkt vraag ik me af. Wel ben ik benieuwd hoe dat zit met ajax calls.
Stel je hebt een productoverzicht met 20 artikelen en de navigatie werkt via ajax. Dus als je op pagina 2 drukt dan wordt er een ajax call gedaan en verschijnen de volgende 20 artikelen. Ik vraag me af of die dan geindexeerd worden door een search-bot...
Wat je laatste punt betreft: nee, want je links zijn SE vriendelijk.
Euh, wat bedoel je precies?
Ze worden niet gecachet omdat m'n links SEO vriendelijk zijn? Dat klinkt een beetje tegenstrijdig..?
Ger van Steenderen op 06/02/2012 13:36:04:
Dit is ook simpel (gedacht). Dus alle searchbots hebben ook pech!
Searchbots hoeven (mogen) van mij niet inloggen. Hoe weet een searchrobot nou dat hij moet inloggen?
AJAX content vraag ik me ook af, maar zoals je wel in mijn voorbeeld kon zien zorg ik juist dat een zoekrobot precies weet wat er is ookal heeft hij JS uit staan...
Ger van Steenderen op 06/02/2012 16:19:22:
Sorry dat ik je in verwarring breng, maar ik had dus over AJAX.
Ja, maar wat bedoel je dan precies? Dat ze wel of niet geindexeerd worden door een zoekmachine?
