[Alg] Rechten voor iedereen/world

[gvanh]

Nu ik een werkend rechtensysteem heb, waarin alle rechten/permissies op de juiste manier aan gebruikers en rollen kunnen worden toegekend, zit ik met een dilemma. Ik heb een rol gemaakt "World", waarmee binnen het CMS systeem kan worden aangegeven welke pagina's/items op de website aan iedereen getoond mogen worden, dus ook zonder dat ze zijn ingelogd.

Echter, in de huidige opzet kan ik pas checken op rechten op het moment dat er een gebruiker is ingelogd ... dan gaat het hele mechanisme van autorisatie werken; aan de gebruiker worden rollen gekoppeld en daaraan ontleend hij zijn rechten. Maar omdat een "normale" bezoeker in het systeem niet inlogt, kan ik dus ook niet controleren op rechten.

Wanneer ik wel een soort "standaard" login zou maken voor deze "normale" bezoekers, dan werpt dat een extra barrière op, aangezien het systeem in PHP op basis van sessies (en dus cookies) werkt. Dat zou betekenen dat de normale website niet kan worden bekeken door bezoekers die geen cookies accepteren ... da's wellicht niet heel vriendelijk.

Is er iemand die hier ook tegenaan is gelopen en hoe heb je dat dan opgelost? Of pleegt men dit op een standaard manier op te lossen?

Ik hoop dat iemand me een tip kan geven. Alvast veel dank!

[elevator]

Als je geen sessie vindt, kan je toch uitvan van een userid -1, 0 of 'anonymous' oid? Of wat bedoel je precies met dat het systeem werkt op basis van?

[Verwijderd]

Gewoon een anonymous user aanmaken. Als een gebruiker cookies niet aan heeft staan dan geef je via de url je session id mee. Het is echter de vraag of je dit wel wil omdat je dan op een pagina met bijvoorbeeld 20 objecten 21 keer een controle op permissies moet uitvoeren.

[ Voor 38% gewijzigd door Verwijderd op 27-07-2005 12:08 ]

[alienfruit]

Ik heb in mijn systeem een rol "Anonymous Users" waarbij er een gebruiker zit met de naam "WEBUSER" deze heeft voor nu altijd alleen leesrechten voor de site. Ik kijk eerst of de gebruik WEBUSER leesrechten heeft voor het domain. Mijn systeempje gaat er altijd vanuit dat wanneer er geen userid beschikbaar is in een koekie of sessie, dat er sprake is van een anonieme bezoeker, en wordt de userid met harde hand gezet na de id -3 (magic number dat webuser representeert ). Ook als een gebruik uitlogt gaat de userid na -3.

Vervolgens kan je dan gewoon door gaan met de authorisatie, omdat de gebruik niet echt veel leesrechten heeft, bijvoorbeeld alleen op bepaalde objecten. Kan de gebruiker niet naar beveiligde pagina (de Anonymous Role heeft hier geen leesrechten)... werkt tot heden prima hier

[gvanh]

@Gordijnstok:

Maar wanneer je de controle niet zou uitvoeren (en daarmee de systeem-belasting waarover jij praat vermijdt), hoe maak je dan een onderscheid tussen beveiligde en niet-beveiligde pagina's? Is daar een andere oplossing voor?

Als een gebruiker cookies niet aan heeft staan dan geef je via de url je session id mee.

Soms wordt bij gebruik van sessies ineens "automagisch" aan de URL een ?sessionID=blabla o.i.d. toegevoegd. Hoe werkt dit precies? Is er een instelling waarmee ik PHP dat zelf laat regelen, of moet ik dan altijd zorgen dat die sessieID wordt toegevoegd aan elke URL?

EDIT: Geloof dat ik dit zelf al gevonden heb ... uit de beschrijving op php.net maak ik op dat - wanneer cookies niet beschikbaar zijn - PHP sowieso altijd (sinds PHP v4.2.0) de sessie id in the URL meegeeft.

[ Voor 16% gewijzigd door gvanh op 27-07-2005 12:24 ]

[Verwijderd]

Het hangt van je aanpak af. Als jij het je kunt veroorloven om die 21 queries uit te voeren volgens een flexibel permissie model zou het kunnen.

Misschien kun je met een oplossing komen zodat je met de minste queries toch een heel object en haar childs op permissies kunt controleren, evt. door snelle lookup tables te maken met de combinaties tussen object en permissies+groep.

Of er bestaat ook nog de mogelijkheid om een gehele pagina te cachen op basis van een unieke token van een totaalplaatje aan permissies. Hangt een beetje van je aanpak af.

Als je dus rechten gaat controleren, zou je dus iets krijgen als:

pagina (controleer rechten)
- component navigatie (controleer rechten)
- link in navigatie naar pagina (controleer rechten)
- component artikel (controleer rechten)
- component opinie (controleer rechten)

Als je een flinke navigatie hebt zul je hier direct een flinke klap mee uitdelen aan de server want dan moet je bij elke link controleren of de pagina de vereiste rechten heeft.

[ Voor 30% gewijzigd door Verwijderd op 27-07-2005 14:20 ]

[alienfruit]

Ach, extra server kost minder dan de uren die je soms besteed aan het tunen. 12 * 90euro = 1080euro incl./jaar. Dat is toch stuk goedkoper dan als je een paar dagen aan finetunen e.d. werkt

[gvanh]

Ja, ik heb het nu dus voor elkaar om - bijvoorbeeld - met één enkele query een volledige mappenstructuur, inclusief geërfte permissies binnen te halen. Op dezelfde manier werkt het ook met groepen pagina's, sjablonen, etc.

Als het allemaal werkt zal ik 'ns wat queries gaan loggen, om een indruk te krijgen van hoe vaak bepaalde functies worden aangeroepen en hoeveel tijd dit kost.

@alienfruit
Waar regel jij voor 90 euro per maand een dedicated/managed/mission critical server?

[ Voor 14% gewijzigd door gvanh op 27-07-2005 14:24 ]

[alienfruit]

Offerte aanvragen bij een webhosting gerelateerd forum/website
Maar het ging om een dedicated server, ik vond het wel netjes.

[ Voor 35% gewijzigd door alienfruit op 27-07-2005 14:32 ]

[gvanh]

Gaat het tegen de regels van GoT in om namen te noemen?

[alienfruit]

http://www.google.nl/sear...=Zoeken&meta=lr%3Dlang_nl

[Verwijderd]

alienfruit schreef op woensdag 27 juli 2005 @ 14:20:
Ach, extra server kost minder dan de uren die je soms besteed aan het tunen. 12 * 90euro = 1080euro incl./jaar. Dat is toch stuk goedkoper dan als je een paar dagen aan finetunen e.d. werkt

Maar jouw oplossing is totaal niet vergelijkbaar met zijn situatie. Jij zet hard een id voor een webuser, maar een component kan ook bijvoorbeeld een permissieset hebben van een extranet user. Daar moet je wel op controleren, en je praat dan niet meer over finetunen, maar over voorkomen dat je server totaal plat gaat door de hoeveelheid queries die je afvuurt bij een enkele pagina.

Daarbij vergeet je even overigens de operational costs voor een extra server. Een extra server is een argument wat ik te vaak hoor, en wat totaal niet onderbouwd de discussie in wordt geduwd zonder rekening te houden met andere factoren. Wie gaat namelijk die server onderhouden?

[alienfruit]

Nou wie denk je bij een dedicated server <g> Verder werk ik niet bij een bedrijf waar het plaatsen van een server extra in een kostenplaatje van duizenden euro's gaat lopen. Maar goed het beheer en onderhoud (beveiligingsupdate e.d.) van de servers zat bij ons in de prijs inbegrepen. Maar goed als je interesse hebt in de Excel sheet die kosten/baten uitgereken tussen optimalisatie en extra server, dan wil ik die best wel mailen

Maar als er een gebruiker is ingelogd heb je ook niet meer de magische webuser id meer, op het moment dat die er niet is worden gekeken naar rechten van de gebruiker. Maar goed, heb ook nog niet te maken gehad met extranet gebruikers e.d.

Maar goed ik heb er nog eventjes over nagedacht, als je wilt kijken of een component de juiste rechten heeft, dan kan je dit tot op zekere hoogte "slim" aanpakken, of doormiddel van een koppeltabel (component_key, has_permissions, etc.). Maar goed nu ik er even over nagedacht heb tijdens de korting wandeling na de theepot Als je nou kijkt of de gebruiker/role leesrechten heeft op parent component, als de gebruiker/role dit niet heeft. Mis je dus de rechten. Het idee hierachter (wast allang verwerkt/besproken hier) van mij is dat je leesrechten nodig hebt op de parent om te kijken of deze parent/component childs heeft. Als je dus parent/component niet kan ophalen/lezen, kan je ook niet kijken of er nog meer is. Oftewel klaar is kees. Als je dit nou via een koppeltabel verwerkt, kan je heel snel via een JOIN ofzo alle records ophalen waarvoor de gebruiker rechten heeft.

[ Voor 74% gewijzigd door alienfruit op 27-07-2005 16:06 ]