VNC stopt er mee :(
username in url bij het bezoeken van de profiel pagina
Ik had dit gevonden maar ik vraag me af of dit de goede manier is om gebruikers hun eigen profiel pagina te geven? En ik vroeg me af of $_SERVER['REQUEST_URI'] nog wel bestaat? en ik kon nergens vinden waar die 3 voor is achter $getName?
Ik heb het iets aangepast, en het is dit geworden:
Code (php)
1
2
3
4
5
6
2
3
4
5
6
$getName = explode("/",$_SERVER['REQUEST_URI']);
mysqli_query($result,"SELECT first_name FROM users WHERE url='$getName[3]'");
$num_rows = mysqli_num_rows($result);
if($num_rows == 0){
header ("Location: 404");
}
mysqli_query($result,"SELECT first_name FROM users WHERE url='$getName[3]'");
$num_rows = mysqli_num_rows($result);
if($num_rows == 0){
header ("Location: 404");
}
Maar het gaat al gelijk bij de eerste regel mis $getName blijft leeg.
Gewijzigd op 21/09/2017 13:38:57 door Erwin b
Code (php)
1
print_r($getName);
Er staat niks in de array
Quote:
Maar het gaat al gelijk bij de eerste regel mis $getName blijft leeg.
Ik bedoel meer letterlijk, waarom 3?
Het bestand profile.php staat in de root. Ik gebruik Xampp en het staat in de htdocs. Als dat is wat je bedoeld?
Ik had gekeken bij w3school.com maar daar is niks te vinden over $_SERVER['REQUEST_URI']. Bestaat die nog wel?
Gewijzigd op 22/09/2017 13:07:08 door Erwin b
Als je het nog iets mooier wilt hebben (bijv. /user/naam) moet je in/via je .htaccess via een rewrite rule die profile.php wegwerken.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
$getName = explode("/",$_SERVER['REQUEST_URI']);
$result = mysqli_query($connect,"SELECT first_name FROM users WHERE url = '$getName[3]'");
$num_rows = mysqli_num_rows($result);
if($num_rows == 0){
header ("Location: index.php");
}
print_r ($result);
print_r($getName);
$result = mysqli_query($connect,"SELECT first_name FROM users WHERE url = '$getName[3]'");
$num_rows = mysqli_num_rows($result);
if($num_rows == 0){
header ("Location: index.php");
}
print_r ($result);
print_r($getName);
Ik had eigenlijk verwacht dat $getName wel in $result zou zitten of zit ik nou helemaal verkeerd? de uitkomst van de arrays zijn:
Code (php)
1
2
2
Notice: Undefined offset: 3 in C:\xampp\htdocs\profile.php on line 11
mysqli_result Object ( [current_field] => 0 [field_count] => 1 [lengths] => [num_rows] => 2 [type] => 0 ) Array ( [0] => [1] => profile.php )
mysqli_result Object ( [current_field] => 0 [field_count] => 1 [lengths] => [num_rows] => 2 [type] => 0 ) Array ( [0] => [1] => profile.php )
Daarnaast zit je nog met het feit dat een (ge-slugify-de) gebruikersnaam UNIEK moet zijn binnen je tabel. Als er twee gebruikers zijn die dezelfde slug/naam hebben dan zal gebruiker twee nooit meer gevonden worden :-). Ik zelf genereer die slug slechts één maal voor een gebruiker en sla hem dan op in de database tabel. De kolom in de tabel -die ik gewoon "slug" noem krijgt een UNIQUE beperking. Vervolgens vind ik de juiste gebruiker *gegarandeerd* terug in de tabel aan de hand van de slug die dus zo uit de URL komt (en dus niet aan de hand van de gebruikersnaam).
Daarnaast bevat REQUEST_URI de oorspronkelijke (encoded) URL. Dit bijvoorbeeld in tegenstelling tot $_GET, die enkel URL-gedecodeerde querystring-variabelen bevat.
De mysqli_query() aanroep is mogelijk ook vatbaar voor SQL-injectie.
In het artikel is (zoals zo vaak) weer sprake van een aanpak waarbij .htaccess de URL mapt naar een specifiek script. Als dit het enige is wat de website dient te doen is dat ok, maar vaak heb je meerdere pagina's dan enkel profielpagina's. In dat geval wil je eigenlijk dat je .htaccess generiek is, je wilt niet voor elke URL nieuwe RewriteConditions en RewriteRules gaan opstellen. Dit wordt al snel een onoverzichtelijke brei. Dit heeft wel tot gevolg dat je dus voor je hele site iets moet verzinnen waarbij je de afhandeling van URL --> script regelt via PHP zelf. Het idee is dat je de routing-administratie delegeert naar code (in plaats van alles proberen te regelen in .htaccess).
Een goed begin (in .htaccess) zou een strategie zijn waarbij je *alle* requests doorstuurt naar de voordeur (de zogenaamde single point of entry) van je applicatie, doorgaans index.php. Van daaruit verwerk je het request verder.
Dit heeft ook andere voordelen: omdat je applicatie maar één ingang heeft hoef je dus ook niet meerdere standalone scripts te voorzien van dezelfde code (includes, aanmaken database-connectie etc.) en hoef je dus ook niet meerdere scripts te onderhouden, maar slechts één.
Ook uit oogpunt van security is dit beter, als je over tijd meer beveiliging toevoegt kan er ook geen sprake zijn van een situatie waarin je mogelijk een standalone script vergeet te patchen, er is immers maar één ingang in je applicatie.
Gewijzigd op 03/10/2017 17:52:16 door Thomas van den Heuvel
Ik zou dit niet bestempelen als "tijdsverlies" omdat zo'n oefening je dwingt om na te denken over een gestructureerde aanpak en codeflow. Dit kan veel inzicht opleveren. Een framework heeft ook een leercurve, deze investering is op eenzelfde wijze ook geen "tijdsverlies".
Ook staat het niet vast dat je continu zwaar zou moeten ingrijpen in (eigen) code. Daarnaast heeft alle code een houdbaarheidsdatum en heeft alle code onderhoud nodig, dit is geen uniek kenmerk (althans niet per definitie :p) voor zelf gerolde code.
Je hebt het over "intensief gebruik", daarmee bedoel je een professionele site en/of een site met veel traffic? Ook dan kan een lichtgewicht oplossing soms beter zijn dan jezelf een (standaard) framework aanmeten.
Tis maar net waar je comfort zone ligt. En om echt tot een objectief oordeel te komen over wat het "beste" is of zou zijn -in een specifieke situatie want "het beste" bestaat niet- zou je alle opties moeten overwegen en misschien ook moeten proberen.
Ik ben het met je eens dat zelfbouw leerzaam is. In dat opzicht zou men kunnen kiezen om een eigen (mini) framework te gaan maken. Maar ik vind persoonlijk dan echt wel dat de tijd die daar in gestopt wordt als studietijd gezien moet worden en er moet geen tijd gebruikt worden om het framework "perfect" te maken. Ook moet het framework enkel gebruikt worden voor leerdoeleinden en niet voor projecten die gemaakt worden voor betalende opdrachtgevers.
Met intensief gebruik bedoel ik meer dat je classes of methods vaker hergebruikt gaan worden. Als voorbeeld met de slugs: In eerste instantie zal een string-slug gebouwd kunnen worden voor die gebruikersnaam maar in tweede instantie voor een heel ander gedeelte van de website zal misschien een datum-slug gewenst zijn. De slugifier zal dan misschien aangepast of uitgebreid moeten worden om ook datums om te kunnen zetten naar een slug.
Ten slotte je laatste opmerking:
Terecht dat een ieder zelf mag bepalen wat voor hem of haar het beste is. Maar het blijft een feit dat een compleet framework een behoorlijk pakket aan classes bevat, zelfs als het een lichtgewicht pakket is. Als je dan commercieel denkt dan weet je dat als je zelf alles gaat uitvinden (en niet alleen het wiel :p) dat daar gigantisch veel uren in gaan zitten waar je geen inkomen voor terugkrijgt en dat terwijl er frameworks zijn die gratis tot je beschikking staan waar vele professionele programmeurs aan gewerkt hebben en goed bijgehouden worden en regelmatig van updates voorzien worden.
Toevoeging op 03/10/2017 20:30:36:
UPDATE
Ook hebben de bekende frameworks een goede documentatie, zijn er op youtube veel films te vinden die de beginner op weg helpen en er zijn zelfs boeken te koop. Mocht dat allemaal niet voldoende zijn kun je nog terug vallen op een forum als deze omdat er duizenden gebruikers zijn die wellicht al veel bekender zijn met het framework dan jijzelf.
Code (php)
1
C:\xampp\htdocs\profile.php
Frank en thomas bedankt voor de uitgebreide reacties. @ Frank, ik denk er zeker niet te makkelijk over. Ik heb er al vele vele uren in gestopt en weet dat het voor mij nog een grote onbekende puzzel is. Maar de aanhouder die wint blijf ik maar denken :)
Een slugifier en framework zeggen me nog niks. Wat ik zo zie van de slug code, zie ik totaal niet hoe dit een username uit de database zou halen en deze de profile.php in de url zou vervangen?
Welke framework raden jullie aan?
Zoals FB of dergelijke sites gebruiken die allemaal de methode met een slug?
Bekijk deze users tabel:
Code (php)
1
2
3
4
5
2
3
4
5
id naam woonplaats slug
-----------------------------------------------------------
1 Frank Nietbelangrijk Leiden frank-nietbelangrijk
2 Frank Nietbelangrijk Haarlem frank-nietbelangrijk-1
-----------------------------------------------------------
-----------------------------------------------------------
1 Frank Nietbelangrijk Leiden frank-nietbelangrijk
2 Frank Nietbelangrijk Haarlem frank-nietbelangrijk-1
-----------------------------------------------------------
en ik doe
Code (php)
1
SELECT * FROM users WHERE naam='Frank Nietbelangrijk' LIMIT 1
Dan zal ik altijd user met id 1 krijgen en nooit user met id 2
Als ik echter dit doe
Code (php)
1
SELECT * FROM users WHERE slug='frank-nietbelangrijk-1' LIMIT 1
dan krijg ik altijd de juiste.
Stel een gebruiker typt deze url in:
http://mysite.nl/profile/frank-nietbelangrijk-1
dan haal je dus "frank-nietbelangrijk-1" uit de URL en zoek je daarop de juiste gebruiker uit de database.
Frameworks die ik zou willen benoemen:
Symfony
- Veel leerwerk
- veel CLI tools o.a. om zo snel mogelijk code te schrijven.
- Gebruikt Doctrine. (is een Object georiënteerde relationele database manager)
- Gebruikt Twig. (is een template engine)
Laravel
- Medium leerwerk
- veel CLI tools
- Gebruikt Blade (template engine)
CakePHP
- Minder leerwerk
- CLI tools
- Geen template engine
Erwin b op 21/09/2017 13:37:52:
Hallo ik wil graag de username in de url als iemand is ingelogd en naar zijn/haar profiel pagina gaat.
Bedoel je nu, dat het gaat om iemands EIGEN profiel, om te bewerken?
Want dan kun je niet vertrouwen op wat in de url staat: dat kan iedereen zo maar aanpassen.
Dan moet je ergens uit de sessions achterhalen om welke user het gaat. Voor "de mooi" zou je weliswaar de naam in de url kunnen zetten, maar dan mag je daar verder niets mee doen.
Maar meer gebruikelijk is iets in deze trant:
Om je eigen profiel in te kijken of te bewerken:
Code (php)
1
http://mysite.nl/my-profile/show
Om een ander zijn profiel te bekijken:
Code (php)
1
http://mysite.nl/profile/frank-nietbelangrijk-1
Met de nadruk op het woord "eenzelfde". Het lijkt mij bijvoorbeeld niet wenselijk om twee gebruikers te hebben:
Frank Nietbelangrijk
en
Frank Niétbelangrijk
Strict genomen zijn deze van zichzelf niet identiek, maar nadat je deze nickname door een slugifier haalt hebben deze wellicht dezelfde uitkomst.
Een andere manier om iemand uniek te identificeren is, zoals eerder genoemd, een (autoincrement) id:
/profile/88/henk