[PHP/(My)SQL] voor dummies - deel 55

Met wat voorwerk kun je dat script véél efficienter maken.. Enkele voorbeelden:

*gebruik eerst array_key_search oid, grote kans dat de meeste browsers er dan al uitrollen zonder dat je die hele tabel 400 keer op en neer moet

* foreach: niet gebruiken. Foreach gebruikt een kopie van de array waar je um op zet, dus als je array om en nabij de 300 kb is en je foreach in foreach in foreach lust ben je niet slim bezig

* Verschillende keren zie je parent=naamxxxx staan. Kijk eens of je daar een numerieke verwijzing aan kan hangen, gaat veel sneller

* Splitsen van browserherkenning en info in verschillende bestanden, bijvoorbeeld met binary trees

* Erg omslachtig natuurlijk, maar databases zijn erg goed in het snel opzoeken van dit soort informatie in dit soort tabellen

etc

EDIT, oh enneh


Wat is er mis met $brows[ $t['parent'] ] ?

-

[ Bericht 94% gewijzigd door Geqxon op 10-02-2008 21:15:13 ]

quote:

Op zondag 10 februari 2008 20:16 schreef Chandler het volgende:

[..]

Ja ja Brouwser

Maaruh gewoon, ik wil deze statistieken bewaren

Dan is het toch voldoende om $_SERVER['HTTP_USER_AGENT'] op te slaan bij iedere request?

Ik heb nu een functie gemaakt die idd de meest gangbare browsers detecteerd, maar om er zeker van te zijn ga ik nu ook gewoon de browser string opslaan!

Ps. Is het handig om alle data zoals, dag, maand, jaar, cookies, plugins, referer, zoekwoorden en dergelijke infomatie in 1 tabel te zetten of is het handiger om dit in apparte tabellen te zetten?

quote:

Op zondag 10 februari 2008 23:01 schreef Chandler het volgende:
Ik heb nu een functie gemaakt die idd de meest gangbare browsers detecteerd, maar om er zeker van te zijn ga ik nu ook gewoon de browser string opslaan!

Ps. Is het handig om alle data zoals, dag, maand, jaar, cookies, plugins, referer, zoekwoorden en dergelijke infomatie in 1 tabel te zetten of is het handiger om dit in apparte tabellen te zetten?

Is dat niet nog simpeler? Enkel de browser-string opslaan, en pas bij het uitlezen deze "encoden" ?

quote:

Op zondag 10 februari 2008 23:01 schreef Chandler het volgende:
Ik heb nu een functie gemaakt die idd de meest gangbare browsers detecteerd, maar om er zeker van te zijn ga ik nu ook gewoon de browser string opslaan!

Die functie werkt toch ook op basis van de browserstring? Dus meer heb je echt niet nodig.

Trouwens, een browserstring is manipuleerbaar. Je kunt er geen 100% garantie uit halen. Ik heb zo snel geen voorbeeld van een programma waar je die string volledig zelf kunt bepalen, maar er zijn vast wel van die programma's.

quote:

Op zondag 10 februari 2008 23:47 schreef Light het volgende:

[..]

Die functie werkt toch ook op basis van de browserstring? Dus meer heb je echt niet nodig.

Trouwens, een browserstring is manipuleerbaar. Je kunt er geen 100% garantie uit halen. Ik heb zo snel geen voorbeeld van een programma waar je die string volledig zelf kunt bepalen, maar er zijn vast wel van die programma's.

Er zijn legio plugins voor FireFox waar je het mee kan doen, ikzelf gebruik "Modify Headers", kan je alles zelf invullen

"User Agent Switcher".

Waarom wil je in godensnaam al die dingen opslaan? Als je zo graag die dingen wil hebben ga dan gewoon je apache logs parsen?

quote:

Apache/2.0.59 (Unix) mod_perl/1.99_17-dev Perl/v5.8.6 mod_ssl/2.0.59 OpenSSL/0.9.8e PHP/5.2.3 Server at www.ericbruggema.nl Port 80

Edit: Je hebt realtime statistieken die je aanbied oid? Dan schiet het inderdaad niet op.

[ Bericht 53% gewijzigd door fokME2 op 11-02-2008 00:08:20 ]

quote:

Op zondag 10 februari 2008 23:01 schreef Chandler het volgende:
Ik heb nu een functie gemaakt die idd de meest gangbare browsers detecteerd, maar om er zeker van te zijn ga ik nu ook gewoon de browser string opslaan!

Ps. Is het handig om alle data zoals, dag, maand, jaar, cookies, plugins, referer, zoekwoorden en dergelijke infomatie in 1 tabel te zetten of is het handiger om dit in apparte tabellen te zetten?

Het is niet handig om dat nu allemaal op te slaan. Ten eerste ga je nooit al die info nodig hebben of gebruiken en ten tweede hoef je niet alles te berekenen - sla alleen de data op waaruit je de info kan destilleren,gewoon in ruwe vorm. Dan maak je later wel een scriptje om de benodigde velden te berekenen. Als je het on the fly gaat bereken met dat scriptje dat je hebt gepost dan trek je de server snel op zijn bek denk ik.

@Iedereen; het scriptje dat browscap.ini parst ga ik niet gebruiken. Aangezien het toch nogal wat preformance vraagt van de server. Ik doe nu gewoon 2 dingen voor mijn statistieken script. 1 is de $_SERVER['HTTP_USER_AGENT'] opslaan plus dat ik deze string op een paar bekende browsers check, en deze sla ik ook weer op.

Iemand nog een antwoord op mijn gebruik van de database? is dit te behappen wat ik doe of moet ik apparte tabellen voor alle onderdelen gebruiken?

[PHP/(My)SQL] voor dummies - deel 55

quote:

Op maandag 11 februari 2008 08:04 schreef Chandler het volgende:
@Iedereen; het scriptje dat browscap.ini parst ga ik niet gebruiken. Aangezien het toch nogal wat preformance vraagt van de server. Ik doe nu gewoon 2 dingen voor mijn statistieken script. 1 is de $_SERVER['HTTP_USER_AGENT'] opslaan plus dat ik deze string op een paar bekende browsers check, en deze sla ik ook weer op.

Iemand nog een antwoord op mijn gebruik van de database? is dit te behappen wat ik doe of moet ik apparte tabellen voor alle onderdelen gebruiken?

[PHP/(My)SQL] voor dummies - deel 55

Deze vraag is al vaker langsgeweest, ook op Tweakers.... dus met even zoeken moet je er wel komen

Volgens mij (uit m'n hoofd) is de meest gangbare manier om alles apart in 1 tabel, maar na een week / maand / jaar / etc. samen te vatten in een nieuwe tabel met alleen de totalen. Op die manier blijft je logtabel te behappen, en kan je gemakkelijk de overzichten maken

Het lijkt me niet onverstandig om aparte tabellen maken voor de browsers, schermresolutie, etc. en daar alleen de unieke waarden in opslaan. Dan heb je in je logtabel alleen nog een ID nodig, dat lijkt me een stuk sneller en eenvoudiger te verwerken...

Ik heb even gezocht op Tweakers en daar staat dat het handiger is om alles in 1 tabel te stoppen ik ben dus al goed bezig! maar denk dat het toch handiger is voor mij om een tabel voor tekst en een tabel voor nummeriek op te zetten. Zo splits ik wat data en zal het zoeken / lezen van records sneller gaan!

Daar ben ik weer eens.

Momenteel ben ik met een scriptje bezig waarbij de pagina die je voorgeschotelt krijgt afhankelijk is van welk persoon de pagina bekijkt. Nu kan ik dat uiteraard met een login script doet, maar aangezien het nogal vaak gebruikt moet worden is dat niet erg gebruiksvriendelijk.

Nu zit ik hier op het bedrijfsnetwerk en zijn mensen uiteraard al ingelogd. LDAP dus.

Ondertussen kan ik al info uit de LDAP server lezen, maar ik wil nu de credentials waar mensen mee zijn ingelogd vergelijken met de server om te authenticeren. Maar..., ik dnek dat ik het niet goed benader, want je credentials worden denk ik niet in de header info meegestuurd ofzo? Is dit uberhaupt mogelijk?

quote:

Op maandag 11 februari 2008 11:52 schreef Swetsenegger het volgende:
Daar ben ik weer eens.

Momenteel ben ik met een scriptje bezig waarbij de pagina die je voorgeschotelt krijgt afhankelijk is van welk persoon de pagina bekijkt. Nu kan ik dat uiteraard met een login script doet, maar aangezien het nogal vaak gebruikt moet worden is dat niet erg gebruiksvriendelijk.

Nu zit ik hier op het bedrijfsnetwerk en zijn mensen uiteraard al ingelogd. LDAP dus.

Ondertussen kan ik al info uit de LDAP server lezen, maar ik wil nu de credentials waar mensen mee zijn ingelogd vergelijken met de server om te authenticeren. Maar..., ik dnek dat ik het niet goed benader, want je credentials worden denk ik niet in de header info meegestuurd ofzo? Is dit uberhaupt mogelijk?

Draait de webserver toevallig in hetzelfde domain als waar de gebruikers ingelogd zijn? of is dan een optie. Werkt enkel onder IIS, voor Apache heb je mod_ntlm nodig.

quote:

Op maandag 11 februari 2008 12:02 schreef Geqxon het volgende:

[..]

Draait de webserver toevallig in hetzelfde domain als waar de gebruikers ingelogd zijn?
[ code verwijderd ]

of
[ code verwijderd ]

is dan een optie. Werkt enkel onder IIS, voor Apache heb je mod_ntlm nodig.

Hij draait in hetzelfde domain, onder apache
mod ntlm heb ik volgens mij al, ik ga ff checken, thanks

-edit- herinner me nu dat ik me een jaar geleden al eens de tering gezocht heb. mod_ntlm is in apache2 vervangen door mod_auth_sspi

[ Bericht 10% gewijzigd door Swetsenegger op 11-02-2008 13:06:47 ]

@Chandler: Als ik jou was zou ik die server strings opslaan voor de stats en dan met een cronjob periodiek de info bereken etc. Dan lopen je grafieken wel xx tijd achter, maar dan heb je denk ik wel de meeste performance.

Als ik als gebruiker de pagina laad, dan sla je alleen mijn browser-string op en merk ik verder geen traagheid.

@Swetsenegger: Met LDAP authorisatie heb ik ook eens gespeeld en het werkte goed. Ik dacht dat ik er een classe voor had gebruikt. Misschien dat ik het thuis nog kan vinden.

Zoals ik al eerder in dit topic aangaf ben ik bezig met een oop-cms. Alles gaat lekker alleen loop ik tegen een probleempje aan. Inloggen gaat goed, session-variables worden geset, en de user wordt doorgestuurd naar de index page. Daar include ik een 'safe-file' die check of de session is aangemaakt, die safe.php ziet er zo uit:



Echter blijft de safe-file redirecten naar de login-page. Ik heb getest of de session is geset en dit is zeker weten het geval. Zien jullie wat ik verkeerd doe, want dit is erg frustrerend :(

ps: Heb deze manier van werken al in een andere website gebruikt en daar werkte het perfect. Met een safe.php en een safe_admin.php beveiligde ik de pages, met een redirect naar login.php. Dit was echter wel zonder classes..

quote:

Op maandag 11 februari 2008 13:16 schreef fokME2 het volgende:

@Swetsenegger: Met LDAP authorisatie heb ik ook eens gespeeld en het werkte goed. Ik dacht dat ik er een classe voor had gebruikt. Misschien dat ik het thuis nog kan vinden.

Ik had alles blijkbaar al eens geconfigureerd, en de login is nu transparant (met IE, met elke andere browser krijg je gewoon een login prompt). Maar.... ik wil nu de username terug vinden van degene die op de pagina zit. De suggesties van geqxon geeft niets terug en ook $_SERVER['PHP_AUTH_USER'] geeft niets terug.

Swets, wat mij bij staat is dat als je de boel met .htaccess en .htpasswd beveiligd, dat Internet Explorer dan eerst met de username en password van de domein-gebruiker in probeert te loggen. Misschien een optie?

quote:

Op maandag 11 februari 2008 13:58 schreef Geqxon het volgende:
Swets, wat mij bij staat is dat als je de boel met .htaccess en .htpasswd beveiligd, dat Internet Explorer dan eerst met de username en password van de domein-gebruiker in probeert te loggen. Misschien een optie?

Nee, de authenticatie op zich werkte al, ik kon alleen nog niet achterhalen wie de ingelogde gebruiker was. In principe mag elke gebruiker van het domein op die pagina komen, maar afhankelijk van de gebruiker kan het zijn dat je andere opties hebt.

$_SERVER['REMOTE_USER']; does the trick

quote:

Op maandag 11 februari 2008 13:40 schreef Tarabass het volgende:
Zoals ik al eerder in dit topic aangaf ben ik bezig met een oop-cms. Alles gaat lekker alleen loop ik tegen een probleempje aan. Inloggen gaat goed, session-variables worden geset, en de user wordt doorgestuurd naar de index page. Daar include ik een 'safe-file' die check of de session is aangemaakt, die safe.php ziet er zo uit:
[ code verwijderd ]

Echter blijft de safe-file redirecten naar de login-page. Ik heb getest of de session is geset en dit is zeker weten het geval. Zien jullie wat ik verkeerd doe, want dit is erg frustrerend

ps: Heb deze manier van werken al in een andere website gebruikt en daar werkte het perfect. Met een safe.php en een safe_admin.php beveiligde ik de pages, met een redirect naar login.php. Dit was echter wel zonder classes..

Laat de login.php eens zien, want volgens mij set je je cookies niet goed.

Edit: En dit gaat uiteraard ook niet werken:



Want een header sturen na output is natuurlijk te laat.

quote:

Op maandag 11 februari 2008 13:40 schreef Tarabass het volgende:
Zoals ik al eerder in dit topic aangaf ben ik bezig met een oop-cms. Alles gaat lekker alleen loop ik tegen een probleempje aan. Inloggen gaat goed, session-variables worden geset, en de user wordt doorgestuurd naar de index page. Daar include ik een 'safe-file' die check of de session is aangemaakt, die safe.php ziet er zo uit:
[ code verwijderd ]

Echter blijft de safe-file redirecten naar de login-page. Ik heb getest of de session is geset en dit is zeker weten het geval. Zien jullie wat ik verkeerd doe, want dit is erg frustrerend

ps: Heb deze manier van werken al in een andere website gebruikt en daar werkte het perfect. Met een safe.php en een safe_admin.php beveiligde ik de pages, met een redirect naar login.php. Dit was echter wel zonder classes..

Waarschijnlijk gaat het ophalen van de sessie data niet goed in je safe include. Initialiseer je de sessie wel goed?
Die safe include is overigens niet echt oop.
Het idee achter OOP is dat je functionaliteit groepeert in logische bouwblokken waaruit je je applicatie opbouwt. Het is dan logisch om een session class te maken, waar je alle session management in regelt. Eventueel zou je die sessie class deel kunnen laten uitmaken van de user class (als in: wel aparte classes maar een user object bevat/encapsuleert een session object). Het idee is dan dat je een objectmethode maakt (bijv $user->isLoggedIn()) die je overal kan gebruiken. Deze methode van de class user kijkt dan in de sessie (maw in het sessie object dat in het user object zit) van betreffende user of alles ok is en geeft dan een 1 (ingelogd) of een 0 (niet ingelogd) terug. Aan de hand daarvan kun je dan de gevraagde pagina tonen of redirecten naar de loginpagina.

quote:

Op maandag 11 februari 2008 14:18 schreef Dzy het volgende:

[..]

Laat de login.php eens zien, want volgens mij set je je cookies niet goed.

Edit: En dit gaat uiteraard ook niet werken:
[ code verwijderd ]

Want een header sturen na output is natuurlijk te laat.

De login gebruikt een functie in een class om in te loggen en eventueel cookies te zetten.

Cookies worden zo gezet:

Als je je code even duidelijk indent zie je dat hij dus altijd over de if constructie met isset(cookie) heen knalt. Daarom moeten je cookies wel niet goed staan. Ik hoop dat je wel session_start ook aanroept he?