Php integreren in css

[Verwijderd]

Heey,

Ik heb en vraagje! Ik heb de basis van mijn website geschreven in CSS, en nu wil ik hier een PHP contactformulier in integreren. Ik heb al gezocht op Google, maar hier kan ik die informatie niet goed terugvinden.

Zou iemand me kunnen vertellen wat ik moet doen om dit werkend te krigen?

Groetjes,

Ingrid

[Arethusa]

Welkom op GoT

Volgens mij haal je wat door elkaar. HTML is bedoelt om de structuur van de website op te maken. CSS is bedoelt om je pagina te stylen.

Volgens mij wil jij PHP integreren in je HTML code. Daarover is genoeg te vinden.

Mocht ik het mis hebben dan hoor ik het graag.

[ Voor 6% gewijzigd door Arethusa op 14-08-2009 14:33 ]

[BtM909]

Je kan een website niet schrijven in CSS en je hoeft dus geen PHP te integreren

Als 't om een HTML pagina gaat wat je hebt gestyled met CSS, dan kan je in je HTML toch gewoon je PHP includen en je HTML output vervolgens stylen met CSS?

[r0b]

CSS is opmaak; kleurtjes, fonts, positioneren van elementen, etcetera. Dat heeft niets te maken met PHP.

Als je webserver PHP ondersteund hoef je alleen maar een form in je HTML aan te maken (i.e., een aparte pagina genaamd contact.html met een <form> tag) die de form action op jephpbestand.php heeft staan. Zodra een gebruiker vervolgens iets submit, voert hij jephpbestand.php uit.
In dit PHP bestand kan je vervolgens ermee doen wat je wilt; opslaan in een database, versturen als mail, etc..

form: http://www.w3schools.com/html/html_forms.asp
mailen: http://www.w3schools.com/PHP/php_mail.asp

Bijvoorbeeld; je form heeft action method POST naar mail.php, met 1 textinput met de naam "name", 1 textinput met de naam "email" en een textarea genaamd "message".
mail.php zou dan zoiets kunnen bevatten:

PHP:

<?php
// Het formulier geeft inhoud aan $_POST['name'] mee (textinput name="name"), doe er hier iets mee
$name = htmlentities($_POST['name']);
// Zelfde geval
$messsage = htmlentities($_POST['message']);
// Nogmaals hetzelfde
$form = htmlentities($_POST['email']);
// Naar wie sturen we de mail
$to = "[e-mail]";
// Het onderwerp dat we meegeven aan de mail
$subject = "Mail from website";
// Minimale headers
$headers = "From: $from";
// Mail it!
mail($to,$subject,$message,$headers);
// Doe iets na het mailen
echo "Mail Sent.";
?>

Quick'n'dirty en ongetest. Verbeteringen aan bovenstaande zouden (o.a.) kunnen zijn: extra beveiliging, spam control (captcha?), x-mails per IP-adres, nette fourmelding bij het direct proberen te bereiken van dit bestand, etc.

[ Voor 64% gewijzigd door r0b op 14-08-2009 14:44 ]

[Verwijderd]

Zo das nog eens een snel antwoord

Bedankt! Ga ik ff proberen

Groetjes Ingrid

[r0b]

Verwijderd schreef op vrijdag 14 augustus 2009 @ 14:43:
Zo das nog eens een snel antwoord

Bedankt! Ga ik ff proberen

Groetjes Ingrid

Lees liever de links door die ik gepost heb; daar heb je veel meer aan dan simpelweg copy/pasten.
Bovenstaande is al het absoluut minimale dat je kan hebben, voor een goed werkend contactformulier moet je veel meer checks uitvoeren. Evt. checken op geldigheid/syntax van een opgegeven emailadres, etc.

[BtM909]

r0b schreef op vrijdag 14 augustus 2009 @ 14:46:
[...]

Lees liever de links door die ik gepost heb; daar heb je veel meer aan dan simpelweg copy/pasten.
Bovenstaande is al het absoluut minimale dat je kan hebben, voor een goed werkend contactformulier moet je veel meer checks uitvoeren. Evt. checken op geldigheid/syntax van een opgegeven emailadres, etc.

Waarom doe je er dan een voorbeeld bij die volledig buiten de context van dit topic gaat

[r0b]

BtM909 schreef op vrijdag 14 augustus 2009 @ 14:48:
[...]

Waarom doe je er dan een voorbeeld bij die volledig buiten de context van dit topic gaat

Huh? Buiten de context?
Het was bedoeld om de link tussen form name in HTML -> $_POST verwerken in PHP te laten zien.

[Cartman!]

Met een voorbeeld dat zo lek is als een mandje dat je aan een beginner geeft die niet echt moeite wil doen te begrijpen waar ie mee bezig is (zo lijkt het althans gezien de gebruikte termen). Niet zo handig imo. Ik denk dat de TS eens een boek moet gaan lezen en eerst de basis eens moet begrijpen.

[r0b]

Cartman! schreef op vrijdag 14 augustus 2009 @ 23:35:
Met een voorbeeld dat zo lek is als een mandje dat je aan een beginner geeft die niet echt moeite wil doen te begrijpen waar ie mee bezig is (zo lijkt het althans gezien de gebruikte termen). Niet zo handig imo. Ik denk dat de TS eens een boek moet gaan lezen en eerst de basis eens moet begrijpen.

Hetzelfde voorbeeld staat op de links die ik gaf; verschil is dat ik alles nog even door htmlentities haal.
Als ik het dus niet gepost had, had TS ongetwijfeld een nog slechtere versie gebruikt.

Ik ben alleszins geen expert, maar het lijkt mij in ieder geval minder erg dan het voorbeeld hier?

[ Voor 10% gewijzigd door r0b op 15-08-2009 10:49 ]

[Verwijderd]

r0b schreef op zaterdag 15 augustus 2009 @ 10:46:

Hetzelfde voorbeeld staat op de links die ik gaf; verschil is dat ik alles nog even door htmlentities haal.
Als ik het dus niet gepost had, had TS ongetwijfeld een nog slechtere versie gebruikt.

Post liever alleen iets als je het zelf ook begrijpt. Die htmlentities functie is in deze context helemaal fout.

Er is nog steeds mogelijk met het formulier te klooien door headers te injecteren via $_POST['email'].

[r0b]

Verwijderd schreef op zaterdag 15 augustus 2009 @ 10:56:
[...]

Post liever alleen iets als je het zelf ook begrijpt.

Ik dacht het redelijk in de smiezen te hebben, maar schijnbaar niet.

Die htmlentities functie is in deze context helemaal fout.

Hmm, ok, help me dan even op weg graag: wat is er precies fout aan in deze context?

Er is nog steeds mogelijk met het formulier te klooien door headers te injecteren via $_POST['email'].

Klopt, en? Met de eerdere voorbeelden - en het uitvoerige commentaar - moet het vrij makkelijk zijn dit te verhelpen.
Dat dit geen 100% oplossing is, is ook nooit de bedoeling geweest. Had ik het dan niet moeten posten? Wellicht niet. Maar dan had TS wel een ander iets uit 2003 gevonden wat nog veel lekker was (1:1 kopieren van alles zonder überhaupt énige checks)

Ik ben het met je eens dat ze veel beter en boek kan kopen en stap-voor-stap beginnen, maar dat kunnen we niet forceren. We kunnen wel stapsgewijs dingen aanleren ("learn while doing")

Maargoed, als mijn voorbeeld dus zo slecht is dan is dat misschien ook niet helemaal slim ..

[ Voor 32% gewijzigd door r0b op 15-08-2009 11:11 ]

[Verwijderd]

Je moet user input niet vertrouwen. User input kan alles zijn, inclusief exact hetgene je niet wilt. JE zult dus user input moeten controleren. Controleren kan door te kijken of de invoer voldoet aan gestelde eisen. Als dat niet zo is doe je niets met de input en laat je bijvoorbeeld een foutmelding zien. Wat ook kan is dat je iets controleert door user input zo te wijzigen dat er niet meer in kán staan wat jij niet accepteert.

In dit voorbeeld wil je niet dat mensen email headers manipuleren. Je geeft ze de mogelijkheid hun emailadres als afzender te gebruiken, maar je geeft kwaadwillenden een kans om iets in te voeren als:

code:

[e-mail]
Cc: [e-mail]

Dat is dus inclusief crlf.

Wat moet je doen om dit te voorkomen? Zorgen dat wat ingevoerd wordt altijd zo wordt gecontroleerd dat er geen email header injection meer mogelijk is. De htmlentities functie doet niet exact wat de bedoeling is en laat het mogelijke (en in jouw script aanwezige) lek dus open.

Ik zou in dit geval controleren of het een geldig emailadres is (en dus geen vreemde tekens bevat) en een foutmelding geven als dat niet zo was. Als gebruikers ook hun naam konden opgeven zodat je "Naam" <[e-mail]> zou krijgen, zou je de naam dus zo moeten escapen dat er geen dubbele quote " in voor kan komen (tenzij geëscapet).

[r0b]

Verwijderd schreef op zaterdag 15 augustus 2009 @ 11:55:
Je moet user input niet vertrouwen. User input kan alles zijn, inclusief exact hetgene je niet wilt. JE zult dus user input moeten controleren. Controleren kan door te kijken of de invoer voldoet aan gestelde eisen. Als dat niet zo is doe je niets met de input en laat je bijvoorbeeld een foutmelding zien. Wat ook kan is dat je iets controleert door user input zo te wijzigen dat er niet meer in kán staan wat jij niet accepteert.

Dan ben ik dan ook volledig met je eens.

In dit voorbeeld wil je niet dat mensen email headers manipuleren. Je geeft ze de mogelijkheid hun emailadres als afzender te gebruiken, maar je geeft kwaadwillenden een kans om iets in te voeren als:

code:

[e-mail]
Cc: [e-mail]

Dat is dus inclusief crlf.

Wat moet je doen om dit te voorkomen? Zorgen dat wat ingevoerd wordt altijd zo wordt gecontroleerd dat er geen email header injection meer mogelijk is. De htmlentities functie doet niet exact wat de bedoeling is en laat het mogelijke (en in jouw script aanwezige) lek dus open.

Ik zou in dit geval controleren of het een geldig emailadres is (en dus geen vreemde tekens bevat) en een foutmelding geven als dat niet zo was. Als gebruikers ook hun naam konden opgeven zodat je "Naam" <[e-mail]> zou krijgen, zou je de naam dus zo moeten escapen dat er geen dubbele quote " in voor kan komen (tenzij geëscapet).

Zo had ik er nog niet eens tegenaan gekeken, ik zat meer in een "oppassen voor enge characters"-idee vastgeroest; goed punt.

Ik ga http://shiflett.org/blog/2005/jan/xss-cheatsheet eens even verder doornemen (artikel uit 2005 .. mja..)

[ Voor 8% gewijzigd door r0b op 15-08-2009 12:09 ]