Du må være registrert og logget inn for å kunne legge ut innlegg på freak.no
X
LOGG INN
... eller du kan registrere deg nå
Dette nettstedet er avhengig av annonseinntekter for å holde driften og videre utvikling igang. Vi liker ikke reklame heller, men alternativene er ikke mange. Vær snill å vurder å slå av annonseblokkering, eller å abonnere på en reklamefri utgave av nettstedet.
  2 7630
Om jeg lager en loggingside, med coockie – uten at det trenger å være relevant, hvor jeg ønsker egne tilganger inne på den innloggede siden. For eksempel: legge til informasjon på en Mysql e.l. Er et alternativ til eksempel slik?
Det er en public folder som er min hjemmeside, der ligger det til eksempel: dbconf.php, index.html og innlogget.php hvor den siste siden er den includet i index.html om du er logget inn. Er det da slik at jeg kan for eksempel lage /mappeforinnlogginformasjon/mysqloppdatering.php og includ den kun for root – derfor include den via index.html – eller er dette en fjompete måte?
Hva med å søke seg litt frem?
Posten din var et uleselig intetsigende skriv. Du får sikkert bedre svar om du beskriver hva du vil litt mer konkret.
Hvordan får du inkludert filer i index.html? Du vil nok bruke php her.

Les deg opp litt på semantikk, skum gjennom litt sider som omhandler login med SQL, sessions/cookies.
Limited edition
Moff's Avatar
Som nevnt ovenfor, posten din er nærmest uleselig. Det virker som du bare har trykket på det foreslåtte ordet i midten på telefonen din og håpet på det beste.

Ut i fra hva du spør om (eller, det jeg tror du spør om), så vil det bli vanskelig å søke frem informasjon, fordi det virker som om du ikke helt vet hva du skal søke etter.

Du nevner et par ulike ting her, som jeg er litt usikker på om du forstår betydningen av.
Cookie: Dette er en tekstfil som en server (nettside) kan sende til en klient (besøkende), med instruks om å lagre i en gitt periode. Klienten velger selv om den vil godta lagring av cookies. Serveren kan ikke garantere at den blir akseptert, og den får heller ikke beskjed om den blir avvist. Klienten kan også lage sine egne cookies og redigere innholdet i dem, så du må aldri anta at innholdet i en cookie er trygt.
MySQL: MySQL er en type database. Databaser lagrer informasjon, og er typisk vesentlig raskere til å behandle informasjon enn andre lagringsmåter. Når vi snakker om nettsider bruker vi gjerne begrepet "flatfiler" om data som er lagret i vanlige filer, slik du ville lagret et notepad-dokument. Flatfiler fungerer, men det er altså vesentlig tregere enn å bruke en database. Databaser lagrer også teknisk sett i filer de også, men de bruker et format som er optimalisert for rask lesing og skriving. Det finnes mange typer databaser. De fleste er relativt like, men alle har sine fordeler og ulemper. MariaDB er en variant av MySQL som er svært populær, og ofte vil du ikke merke om du jobber på en MariaDB eller en MySQL-database. Andre alternativer, som har større forskjeller, inkluderer MSSQL (Microsoft sin variant) og MongoDB (en såkalt "NoSQL"-variant, som blant annet ikke opererer med faste kolonner, slik MySQL og MSSQL gjør). Av disse er MariaDB og MySQL de letteste å lære seg, fordi de har svært bred støtte og det finnes nærmest uendelig mange diskusjonstråder om dem på nettet, og derfor er det lett å finne svar på det du lurer på.
"Public folders" og PHP: PHP er et programmeringspråk som driver mesteparten av dagens internett. PHP fungerer som et tillegg til webserveren. Du kan kjøre PHP på de aller fleste webservere, og du kan også kjøre det separat som et eget program på PC-en din om du vil (slik du også kan med for eksempel Python og Ruby). Jeg tror ikke det er noen webservere som har PHP innebygget, men de fleste tilbydere som leier ut webhotell tilbyr også PHP som standard. I likhet med svært mange språk som brukes til nettsider så er PHP et "serversidet-språk", som betyr at koden er lagret og kjører på serveren, ikke på klienten. Så lenge webserveren er konfigurert riktig, så skal det derfor være umulig for en normal besøkende å lese PHP-koden din. Klienten kan be serveren om å kjøre PHP-filen, og koden vil da bli lastet inn - men selve koden blir aldri overført til klienten. Den kjøres ferdig, og klienten vil kun se det som eventuelt kommer ut av skriptet underveis.
Including/requiring: Et sentralt konsept i språk som PHP, Python, JavaScript og tilsvarende er muligheten til å splitte koden ut i flere filer. Det kan være mange grunner til at du ønsker å splitte koden i flere filer; ofte fordi det er ryddigere, men også fordi det gjør det lettere å gjenbruke kode på tvers av flere prosjekter. I PHP er det flere kodeord for å hente inn kode fra en annen fil. Include henter en fil og gir en warning hvis filen ikke eksisterer. Require henter filen og stopper skriptet (fatal error) hvis filen ikke finnes, og require_once fungerer som require - men den vil ikke inkludere en fil hvis den allerede har blitt inkludert i det samme skriptet tidligere (derav navnet "once"). Including og requiring har altså ingenting med problemstillingen din å gjøre, det er bare noe utviklere gjør for å holde orden på ting. Det er imidlertid en potensiell fallgruve med å spille filer, som jeg ofte ser nye utviklere gjør feil. Klienten kan normalt sett be serveren om å kjøre alle PHP-filer hvis de har URL-en til dem. Hvis du har en PHP-fil som autentiserer og autoriserer klienten, som inkluderer et "hemmelig" skript hvis klienten er kjent, da må du passe på at en klient ikke bare kan kjøre den "hemmelige" filen ved å bruke en direkte URL-til den, og dermed omgå hele autoriseringsprosessen. Det er selvsagt mulig å blokkere filer fra klienten uten å bruke PHP. Jeg anbefaler at du gjør det, men det kan også løses med PHP-kode. Hvis du bruker en Apache-server, så kan du for eksempel blokkere alle filer untatt index.php-filen via .htaccess-filer. Og som en fotnote, du skriver at du vil inkludere PHP-kode i en HTML-fil; det går selvsagt ikke an. HTML er klientside, og kan heller ikke inkludere eller kjøre PHP-kode.
Root: "Root" kan bety mye forskjellig i denne konteksten. Som regel snakker vi om administrator-brukeren på et Linux-system, men det kan også være rotmappen til en webserver (document root). Å "inkludere noe kun for root" gir uansett ikke mening. Jeg tror kanskje du snakker om å inludere filer kun for påloggede brukere, eller kanskje bare en spesiell bruker. Hvem vet. Det eneste jeg vil si om dette er at hvis du på ett eller annet vis har en fiks idé om å blande inn root-brukeren på en Linux-maskin i systemet ditt, dropp det umiddelbart. Du må for all del ikke finne på å kjøre en prosess som har noe med nettsiden din å gjøre på root-brukeren.

De fleste webservere har støtte for pålogginger uten bruk av noe eksternt skript. På en Apache-server ville du brukt en .htpasswd til å lagre brukernavn og passord, og satt en regel i en .htaccess-fil som sier at mappen din krever pålogging. Det er klønete, men det fungerer hvis du bare ønsker å blokkere tilgang til en mappe.

Her er et veldig utrygt og enkelt eksempel på et login-skript i PHP:

Kode

<?php

// Informasjon om pålogget bruker
$isLoggedIn = false;		// Er brukeren pålogget?
$loggedInUsername = null;	// Brukernavn for pålogget bruker

// Brukernavn => passord
$users = array(
	'Moff'		=> 'fisk',
	'JuiceGutten'	=> 'bever',
	'Hater_mordin'	=> 'lampe'
);

// Sjekk om brukeren har sendt inn pålogginsinformasjon
if(isset($_POST['username']) && isset($_POST['password'])) {
	// Finn riktig brukernavn
	foreach($users as $username => $password) {
		if(strtolower($username) == strtolower($_POST['username']) && $_POST['password'] == $password) {
			// Match!
			
			// Lagre informasjon
			$isLoggedIn = true;
			$loggedInUsername = $username;
			
			// Sett en cookie slik at vi husker dette til neste gang
			$expires = time() + 60 * 60 * 24 * 14; // 14 dager fra nå
			setcookie('username', $username, $expires, '/');
			
			break;
		}
	}
} else if(isset($_GET['logout'])) {
	// Logg ut
	setcookie('username', null, time());
} else {
	// Sjekk om det finnes en cookie
	if(!empty($_COOKIE['username'])) {
		$isLoggedIn = true;
		$loggedInUsername = $_COOKIE['username'];
	}
}

if($isLoggedIn) {
	// Pålogget
	echo '
		<h1>Velkommen tilbake, ' . htmlspecialchars($loggedInUsername) . '!</h1>
		
		<p>
			Hva skjer hvis du endrer innholdet i cookien din, mon tro?
		</p>
		
		<p>
			<a href="?logout">Logg ut</a>
		</p>
	';
} else {
	// Ikke pålogget
	echo '
		<h1>Logg inn</h1>
		
		<form method="post" action="?">
			<input type="text" name="username" placeholder="Brukernavn"><br>
			<input type="password" name="password" placeholder="Passord"><br>
			<input type="submit" name="submit" value="Logg inn">
		</form>
	';
}

?>
Grunnen til at dette ikke er trygt er fordi det ikke er noen som helst verifisering av hvor cookien kommer fra. Du kan med andre ord "logge inn" ved å bare opprette en ny cookie med et tilfeldig brukernavn i, og dermed omgå hele innloggingen. Poenget med skriptet er bare å gi deg noen konkrete eksempler på hvilke funksjoner du trenger å bruke for å få systemet til å fungere. Jeg går ut i fra at du ønsker å bruke MySQL til dette, og det er også en smart måte å løse det på. For å bruke MySQL i PHP anbefaler jeg at du tar i bruk PDO-biblioteket. Alternativet til PDO er MySQLi-biblioteket. Jeg foretrekker PDO, selv om det er både fordeler og ulemper med begge. PDO er mer behagelig å jobbe med, spør du meg.

For å løse den åpenbare svakheten i skriptet ovenfor så bør cookien inneholde noe som serveren kan verifisere. En typisk feil mange nye utviklere gjør er å inkludere brukernavn og passord i cookien som sendes til klienten. Dette må du ikke gjøre. Det vil løse problemet, fordi tilfeldige brukere ikke skal klare å gjette hva brukernavn og passord er, og dermed kan de, i teorien, heller ikke forfalske en cookie. Det som imidlertid er problemet er når cookies havner på avveie. Jeg har en "kompis" som hadde det veldig gøy med å stjele andre brukere sin login-session på ulike typer forum, ved å skrive innlegg som inneholdt en link med en Javascript-kode i. Javascript er klientside-kode, og i gamledager var nettlesere helt ukritiske til å kjøre Javascript via adressefeltet, også via linker man trykker på. Siden Javascript har tilgang til cookies, så kunne du kopiere alt innhold i alle cookies for domenet og sende dem til din egen webserver. Derfra var det bare å kopiere innholdet du fikk tilsendt inn i din egen cookie, og forumet trodde plutselig at du var brukeren som trykket på linken. Nå i dag er dette mye vanskeligere, mest av alt fordi ingen moderne nettlesere vil akseptere Javascript i adressefeltet lengre. Et annet tiltak som du bør vurdere er å sette en begrensning på hvor en cookie kan brukes fra, for eksempel knytte den til en IP-adresse. Dette er ikke en helt optimal løsning det heller, fordi de fleste brukere i dag ofte skifter IP, og dermed blir de tvunget til å logge inn ofte. Personlig pleier jeg å la webserveren finne på et helt tilfeldig token (en lang, kryptografisk sikker, random string) som lagres i cookien, som webserveren også lagrer i databasen sin. Sjansen for at noen klarer å gjette en annen brukers token er fantastisk liten akkurat nå, og derfor er dette en trygg måte å gjøre det på. Å lagre noe sensitivt i en cookie er alltid en dårlig idé; du må gå ut i fra at cookies før eller siden blir stjålet. Hvis det skulle skje med et token, så kan du ha en funksjon på nettsiden som sletter alle kjente tokens for en bruker. Dette er den funksjonen som alle store tjenester bruker når du ber om å logge ut alle kjente enheter. Tjenester som Google vil også sende mail til brukerne sine og advare når de oppdager en login som virker suspekt, og gi brukeren mulighet til å blokkere den aktuelle påloggingen. Den store fordelen er at tokenet i seg selv ikke inneholder noe informasjon om brukeren, i alle fall ikke brukernavn og/eller passord.

Når du skal begynne med brukerhåndtering i en database som kommer du garantert til å skape en million sikkerhetshull. Alle nye utviklere gjør dette. Jeg anbefaler at du poster den ferdige koden din her, slik at vi kan komme med tilbakemeldinger på hva som bør fikses før du publiserer det.