[PHP/(My)SQL] voor dummies - Deel 77

quote:

Op vrijdag 27 november 2009 22:24 schreef GlowMouse het volgende:
waar is je GROUP BY?

tx dat soort dingen vergeet ik af en toe

Weet iemand een goede tutor over werken met gebruikers, rechten, rechten groepen etc?

http://net.tutsplus.com/tutorials/php/a-better-login-system/

een ACL tutorial

Tnx, ik ga er mee bezig! erg lange maar duidelijke tutor!

Verder heb ik nog een vraag.

Ik wil alle urls kunnen herschrijven en via index.php laten lopen

bv

van http://ww.domein.nl/gebruiker/berichten/lees/123
naar index.php?arg=gebruiker/berichten/lees/123

en

van http://ww.domein.nl/gebruiker/berichten/lees/123 ?html=aan
naar index.php?arg=gebruiker/berichten/lees/123&html=aan

hoe krijg ik dat voor elkaar? (ook andere subs zoals /gebruikers en /login, etc moeten worden herschreven) ik heb het al geprobeerd met iets zoals dit

1 2 3 4 5 6 7 8 9 10

Options +FollowSymLinks RewriteEngine On RewriteRule ^([^/]+)/([^/]+)/([^/]+)/([^/]+)/([^/]+)/([^/]+)/([^/]+)$ index.php?arg=$1/$2/$3/$4/$5/$6/$7&{QUERY_STRING}  RewriteRule ^([^/]+)/([^/]+)/([^/]+)/([^/]+)/([^/]+)/([^/]+)$ index.php?arg=$1/$2/$3/$4/$5/$6&{QUERY_STRING}  RewriteRule ^([^/]+)/([^/]+)/([^/]+)/([^/]+)/([^/]+)$ index.php?arg=$1/$2/$3/$4/$5&{QUERY_STRING}  RewriteRule ^([^/]+)/([^/]+)/([^/]+)/([^/]+)$ index.php?arg=$1/$2/$3/$4&{QUERY_STRING}  RewriteRule ^([^/]+)/([^/]+)/([^/]+)$ index.php?arg=$1/$2/$3&{QUERY_STRING}  RewriteRule ^([^/]+)/([^/]+)$ index.php?arg=$1/$2&{QUERY_STRING}  RewriteRule ^([^/]+)$ index.php?arg=$1&{QUERY_STRING}

maar dat werkt op een of andere manier niet...

Werkende code


echter wil ik nu nog /layout/* excluden dat dit via index.php loopt, hoe kan ik dat doen?
(oplossing)

[ Bericht 30% gewijzigd door Chandler op 29-11-2009 21:41:13 ]

Ik ben gisteren druk geweest met ACL maar vind het een beetje te groot, is er ook een tutoriaal die een kleinere / simpelere versie behandeld?

Zelf dacht ik aan een opzet van dit.

rollen
rol_combie
rol_waarden

rollen
1 - administrator - mag alles
2 - beheerder - mag bijvoorbeeld alle artikelen beheren
3 - editor - mag zelf artikelen toevoegen (eigen beheren)
4 - gebruiker - mag reageren op poll, artikelen, etc
5 - gast - mag site bezoeken, reageren op artikelen (niet op bv poll)

rol_combie is een link tabel tussen rollen en rol_waarden
rolID
waardeID
laatsteUpdate

rol_waarden bevat waarden waarin staat vermeld welke rechten er zijn bv
id (rolID)
waarde - (poll_may_vote, poll_may_comment, article_add, article_edit, article_edit_other, etc)
laatsteUpdate - datum van update

en eventueel een tabel die rechten aan gebruiker zelf koppelt
rol_combie_gebruiker
rolID
gebruikerID

Of bekijk ik dit nu te simpel? is het volgens jullie meer nodig om ook per gebruiker specifieke rechten toe te kennen?

Ik wil de data van een database in een HTML tabel presenteren. Nu heb ik hiervoor de volgende code:




Alleen nu begrijp ik dus niet wat ik met deze code moet. Is dit nou een HTML code die ik gewoon in de HTML van mijn site kan plaatsen, of is dit een PHP code die in een PHP bestand geplaatst moet worden?

Het versturen van de gegevens naar een database vanuit een formulier werkt als volgt:
De hTML code:


En de PHP code:


Bij dit invoeren van de data naar een database via zo'n formulier is er dus een strikte scheiding tussen PHP en HTML. Ik plak dus de HTML code in mijn html pagina in dreamwaver, en ik maak vervolgens een PHP bestand aan die ik opsla als: "insert.php".
Deze files upload ik vervolgens naar de server en dan doet alles het.

Maar met de bovenste code gaat dit dus niet. Ik weet dus niet of ik er een php file of een html file van moet maken. Of moet ik in de tabel weer een action=output.php toevoegen? En dan de php weer apart opslaan en de tabel code invoegen in de html.

Kan iemand uitleggen hoe dit zit??

Hoi allen.

Ik ben op zoek naar een (liefst) kant en klaar script waarbij ik de voorraad van een tiental artikelen op diverse locaties kan bijhouden met een historie. Zou mooi zijn als er een admin-pagina was waarop men verschillende users kan aanmaken die de voorraad mogen muteren en/of wijzigingen in omschrijvingen kan uitvoeren.

Nu heb ik van alles en nog wat afgezocht, maar in het nederlands vind ik geen hits en als ik ga zoeken op scripts met "stock", dan krijg je aandelen-meuk.

Mocht iemand iets weten (PHP/MySql), let me know ! Ik zoek natuurlijk zelf ook nog even verder maar misschien dat iemand hier al zoiets heeft gezien ergens.....

quote:

Op maandag 30 november 2009 15:20 schreef NoShitSherlock het volgende:
Ik wil de data van een database in een HTML tabel presenteren. Nu heb ik hiervoor de volgende code:
[

daar klopt bijzonder weinig van. wil je het in 1 pagina doen dan kan het bijvoorbeeld zo:


je zult nog wel zelf eea moeten klussen

hmm.. hij laat op heel veel plekken de <?php en ?> weg.. ff op quote drukken ofzo dan

Misschien tijd voor een echte PHP code parser voor FOK!??

het is op fok! tijd voor zoveel echte dingen

quote:

Op maandag 30 november 2009 20:04 schreef hamkaastosti het volgende:
het is op fok! tijd voor zoveel echte dingen

Vind het zo frappant dat ze niet gewoon zaken afmaken ipv steeds uitbouwen maar goed.

Wat is trouwens het verschil tussen ACL en RBAC? kon dat niet echt uit de wiki pagina's halen!

En ik zoek nog steeds (ja nog steeds google aan't lastig vallen) voor een duidelijk nederlandse tutoriaal over een van 2 bovenstaande opties...

Ik heb de ACL tutor doorgelezen en heb nu zelf en opzet gemaakt

tabel gebruikers tabel van de gebruikers
id * int unsigned
naam * varchar * 50

tabel gebruikers_rechten_link (linkt gebruikers aan rechten)
gebr_id
recht_id

tabel gebruikers_groepen_link (linkt gebruiker aan groep(en))
gebr_id
groep_id

tabel gebruikers_groepen (admin, moderators, editors, naam voor verzameling van rechten)
id
titel

tabel gebruikers_groepen_rechten_link (linkt groepen aan rechten)
groep_id
recht_id

tabel gebruikers_rechten (de rechten die de gebruiker kan hebben)
id
recht * varchar * 50 (naam van het recht)
waarde (true/false)

Nu vraag ik mij af hoe ik aan dit tabellen systeem ook 'gasten' kan verbinden? en of iemand wat heeft op te merken (sorry, zo leer ik, dus alle feedback is welkom)

Je moet je gast ook als een gebruiker benaderen.

je gebruiker kan userid 0 zijn.

Ah natuurlijk ennuh is het handig om de geladen rechten op te slaan in een sessie? of per pagina lading alle rechten ophalen?

quote:

Op dinsdag 1 december 2009 18:48 schreef Chandler het volgende:
Ah natuurlijk ennuh is het handig om de geladen rechten op te slaan in een sessie? of per pagina lading alle rechten ophalen?

Bij elke pageload opnieuw ophalen is veiliger, maar in een sessie opslaan zal wel weer een query schelen en dus sneller zijn. Het is een afweging tussen beveiliging en snelheid.

Je zou ook kunnen kiezen voor een tussenweg, zoals alleen opnieuw ophalen van rechten bij een POST, of een timestamp opslaan in de sessie en bijvoorbeeld 10 minuten na die tijd de rechten in ieder geval weer laten ophalen (zodat er geen langdurende sessies met de oude rechten actief blijven).

Veiligheid > Dat beetje performance dat je zou sparen met één query`tje minder.

Tevens TVP.

En chandler, een dergelijke opzet gebruik ik in vrijwel elke applicatie die ik maak; je kunt er immers alle kanten mee uit. Voor de rest leg ik het onderscheid maken tussen een geauthenticeerde gebruiker en een gast op een ander niveau neer, in ieder geval niet op het rechtenniveau. Zo heb ik in veel van mijn applicaties bijvoorbeeld een array met 'safe pages', hetgeen in feite niet meer is dan een array met bestandsnamen (of eventueel functies) waar ook 'gasten' in mogen komen.

Even een vraagje,

ik heb een website volledig gebouwd in HTML en een klein beetje PHP (includes)
Nou wilde ik graag een CMS achter de website bouwen zodat hij makkelijk aanpasbaar is voor andere gebruikers. Welk CMS is aan te raden (makkelijk en waarbij ik de website snel kan overzetten) ?

Ik ben admin van een site (niet zelf gemaakt) en kreeg vandaag een mailtje van de vrouw achter de site. Ze kreeg melding dat de site verhuisd zal worden en het ip zal veranderen. Ik dacht, dat maakt niks uit, maar nu zie ik in de code van index.php dit staan:

Ik neem aan dat ik dat dus zal moeten veranderen : (wat betekent de code eigenlijk?)

quote:

Op woensdag 2 december 2009 18:47 schreef Mirel het volgende:
Ik ben admin van een site (niet zelf gemaakt) en kreeg vandaag een mailtje van de vrouw achter de site. Ze kreeg melding dat de site verhuisd zal worden en het ip zal veranderen. Ik dacht, dat maakt niks uit, maar nu zie ik in de code van index.php dit staan:
[ code verwijderd ]

Ik neem aan dat ik dat dus zal moeten veranderen : (wat betekent de code eigenlijk?)

Waarschijnlijk zul je het IP adres hoeven 83.98.245.150 veranderen naar het nieuwe adres. Dit stukje zelf doet an sich niet zo veel; het kijkt naar de waarde $_SERVER['HTTP_HOST'], als dit localhost of 83.98.245.150 is, dan word de PHP instelling 'error_reporting' op E_ALL gezet (dus alle fouten en waarschuwingen in PHP scripts zullen weergegeven worden) en word de variabele $path op '/pikler' gezet. Alles wat anders us, maakt het $path variabele leeg en stelt géén error_reporting in.

Kortom, dit is een scriptje dat iets doet, afhankelijk van de host waar het op draait.

quote:

Op dinsdag 1 december 2009 19:03 schreef Sirolf het volgende:

[..]

Bij elke pageload opnieuw ophalen is veiliger, maar in een sessie opslaan zal wel weer een query schelen en dus sneller zijn. Het is een afweging tussen beveiliging en snelheid.

Je zou ook kunnen kiezen voor een tussenweg, zoals alleen opnieuw ophalen van rechten bij een POST, of een timestamp opslaan in de sessie en bijvoorbeeld 10 minuten na die tijd de rechten in ieder geval weer laten ophalen (zodat er geen langdurende sessies met de oude rechten actief blijven).

Opslaan maakt het rechtenbeheer niet echt onveiliger. Als jij je hele rechtenstructuur iedere keer moet bereken doet hij elke keer het zelfde. Aangezien je niet om de 5 dagen de rechten gaat aanpassen.

Maak bij de user een kolom aan iets van Rights ofzo, bereken alle rechten en pleur die dan hier in. Volgende keer heb je de rechten berekend en al zo voor je neus staan. Als je dan rechten gaat aanpassen hoef je alleen maar deze kolom bij iedereen (waar de aanpassing van toepassing op is) leeg te maken en dan zal hij deze opnieuw moeten berekenen waarna hij hem weer opslaat en klaar

quote:

Op woensdag 2 december 2009 19:25 schreef Pakspul het volgende:

[..]

Opslaan maakt het rechtenbeheer niet echt onveiliger.

Natuurlijk wel. Als jij je rechten alleen maar sporadisch gaat opslaan, kan dat cruciale fouten veroorzaken. Wat als je net iemand betrapt op het verwijderen van records, en die persoon per direct zijn rechten wilt ontnemen?

Als er iets belangrijk is in een (web)-applicatie, dan is het wel (actuele / realtime) beveiliging. Als je applicatie door één eenvoudig query`tje veiliger wordt, dan zou ik me vooral niet over dat (minieme performance-verlies van) query`tje druk gaan maken. Jouw oplossing om alles in één kolom te gooien is nou ook niet bepaald efficiënt.

quote:

Op woensdag 2 december 2009 19:52 schreef Tuvai.net het volgende:

[..]

Natuurlijk wel. Als jij je rechten alleen maar sporadisch gaat opslaan, kan dat cruciale fouten veroorzaken. Wat als je net iemand betrapt op het verwijderen van records, en die persoon per direct zijn rechten wilt ontnemen?

Vertel mij stap voor stap dan eens hoe dat te werk gaat. Lees dan mijn verhaal nog eens door en zeg dan dat mijn verhaal toch nog correct is.

quote:

Als er iets belangrijk is in een (web)-applicatie, dan is het wel (actuele / realtime) beveiliging. Als je applicatie door één eenvoudig query`tje veiliger wordt, dan zou ik me vooral niet over dat (minieme performance-verlies van) query`tje druk gaan maken.

Dat verklaard waarom windows dus ook alle rechten in een keer berekend en dan vast zet inplaats van ze steeds opnieuw te berekenen.

quote:

Jouw oplossing om alles in één kolom te gooien is nou ook niet bepaald efficiënt.

Efficiënter dan alles rechten ophalen deze helemaal laten berekenen. Als je een ingelogde user hebt haal je toch de informatie van hem op. In iedergeval zijn username, waarom dan ook niet even een extra kolom waar zijn rechten in staan ophalen.

ik heb gewoon een sessie tabel met alle sessies. die koppel ik bij elke request aan de users tabel. voor rechten zou ik d'r een simpele acl class maken die de rechten kan checken adh van info in de users tabel.
Over die extra select of misschien een join op 2 tabellen zou ik me bij de gemiddelde hobbysite absoluut niet druk om maken.

quote:

Op woensdag 2 december 2009 20:00 schreef Pakspul het volgende:
Vertel mij stap voor stap dan eens hoe dat te werk gaat.

Euh, wat snap je niet aan mijn voorbeeld? Als jij een kwaadwillge gebruiker betrapt in jouw systeem, hetgeen misschien wel iemand is die een account gekaapt/gehacked heeft, die van alles aan het verwijderen is, dan wil je die toch meteen zijn rechten kunnen ontnemen? Of wil je dan echt de rechten gaan ontnemen, en braaf gaan wachten tot die gebruiker opnieuw inlogt (of wat dan ook doet waardoor je jouw rechen-update triggert)?

quote:

Dat verklaard waarom windows dus ook alle rechten in een keer berekend en dan vast zet inplaats van ze steeds opnieuw te berekenen.

Windows? Hoezo appels en peren? Sowieso doet Windows dat maar tot een bepaald niveau, voornamelijk op lokaal/workstation niveau. Als ik bijvoorbeeld in een Active Directory een netwerkmap heb waarop ik instel dat een bepaalde groep gebruikers er niet meer in mag komen, dan wordt dat realtime toegepast hoor.

quote:

Efficiënter dan alles rechten ophalen deze helemaal laten berekenen. Als je een ingelogde user hebt haal je toch de informatie van hem op. In ieder geval zijn username, waarom dan ook niet even een extra kolom waar zijn rechten in staan ophalen.

Om te beginnen is een dergelijke kolom niet meer dan een overbodige rotzooi-kolom met, afhankelijk van hoe jij je rechten er in opslaat, waarschijnlijk een lap aan tekstuele data. En nogmaals, waar zit 'm het grote performance- en/of snelheidsverlies in een eenvoudige COUNT() query? Wil je echt zo omslachtig gaan doen om een nota bene onveiliger systeem over te houden, alleen om een simpel query`tje te besparen?

Het kan aan mij liggen, maar als het op veiligheid aan komt, ga je niet 'zuinig' lopen doen.

quote:

Op woensdag 2 december 2009 20:17 schreef Tuvai.net het volgende:

[..]

Euh, wat snap je niet aan mijn voorbeeld? Als jij een kwaadwillge gebruiker betrapt in jouw systeem, hetgeen misschien wel iemand is die een account gekaapt/gehacked heeft, die van alles aan het verwijderen is, dan wil je die toch meteen zijn rechten kunnen ontnemen? Of wil je dan echt de rechten gaan ontnemen, en braaf gaan wachten tot die gebruiker opnieuw inlogt (of wat dan ook doet waardoor je jouw rechen-update triggert)?

Ik heb het nooit gehad over opnieuw inloggen, wanneer je site een pagina verder gaat zal die weer controleren of deze ingelogd is ja of nee en weer spul uit de database halen. Mits je afbent gestapt van het $_SESSION object. Dat kan misschien wat stof doen op waaien in deze discussie want ik haal bij iedere request de gegevens van de gebruiker opnieuw op zodat deze de laatste informatie heeft. Dus dan ziet die ook of de Rechten kolom is gevult ja of nee, als dit niet zo is dan bouwt hij deze opnieuw op en schrijft deze weer weg en dan gaat hij bij de actie die de gebruiker gaat uitvoeren deze weer checken. Zit 0,0 verschil in met real-time aanpassingen.

quote:

[..]

Windows? Hoezo appels en peren? Sowieso doet Windows dat maar tot een bepaald niveau, voornamelijk op lokaal/workstation niveau. Als ik bijvoorbeeld in een Active Directory een netwerkmap heb waarop ik instel dat een bepaalde groep gebruikers er niet meer in mag komen, dan wordt dat realtime toegepast hoor.

AD maakt een copy van de site (folder-systeem/netwerk schijf) in zijn database waar deze allemaal objecten opslaat met de daarbij horende rechten voor de group/gebruiker/etc

quote:

[..]

Om te beginnen is een dergelijke kolom niet meer dan een overbodige rotzooi-kolom met, afhankelijk van hoe jij je rechten er in opslaat, waarschijnlijk een lap aan tekstuele data. En nogmaals, waar zit 'm het grote performance- en/of snelheidsverlies in een eenvoudige COUNT() query? Wil je echt zo omslachtig gaan doen om een nota bene onveiliger systeem over te houden, alleen om een simpel query`tje te besparen?

Het kan aan mij liggen, maar als het op veiligheid aan komt, ga je niet 'zuinig' lopen doen.

Ik maak gebruik van een rechten beheer waarbij je in verschillende groepen kunt zitten en de gebruiker zelf ook nog rechten kan geven. Dus je moet van alle groepen + gebruiker de rechten ophalen. Daarna gaat hij deze allemaal na om te kijken wat er na het hele overerving verhaal nog voor de gebruiker overblijft. Het resultaat hiervan is een array en de rechten van de gebruiker.

Ik ben aan 't werk met een php intranet site en ben bezig met een pop-up divje die je te zien krijgt als je een waarde invult in een tekst vak. In die div krijg je dan een aantal links waar een user op kan klikken. Nu gebruik ik onblur om ervoor te zorgen dat de div weer hidden wordt als je naast het tekstvak klikt.

Klein probleempje met de onblur: De klik voert hem uit voordat hij bij de link is, waardoor de link weg is voordat er op geklikt kan worden. Ofterwijl: Klik => Blur => Link niet meer zichtbaar dus kan hij de link niet meer doorgeven.

Iemand eerder zoiets gehad? De oplossingen op internet vind ik te vies om te gebruiken (timer gebruiken om de div verlaat te verwijderen enzo)

Klinkt als javascript ipv php

@Pakspul, @Tuval.net, @Hamkaastostie;

Ik ga nu middels timestamps checken of er wijzigingen gemaakt zijn in de rechten tabellen, het kost mij dan per 'tabel' een query (oftewel 3 in mijn geval)