[CSS] email "bubble" maken

vrijdag 1 april 2011 20:46

Acties:

0 Henk 'm!

Topicstarter

Momenteel maak een simpele email client met de PHP imap functies.
Alles gaat goed wat PHP betreft, maar ik heb nog 1 probleem bij het laten zien van een email...
Een HTML email (wat van mij gewoon mag) is in principe een volledige (statische) webpagina.
Nu heb ik het probleem dat als ik zo'n email in een DIV open (met HttpRequest), de CSS van die email invloed heeft op de rest van m'n pagina en de layout aanpast.
Nou zijn er natuurlijk andere opties die ik geprobeerd heb:
1) HTML email inladen in een IFRAME werkt, maar ik gebruik ze liever niet. Plus dat ik in de layout (mailregels "klappen uit") dan weer moet gaan klooien met de hoogte van de IFRAME.
2) Proberen met Perl RegExp (preg_replace, preg_match_all etc.) de CSS te veranderen, zodat alles beperkt blijft tot binnen de DIV waarin ie geladen wordt.
Helaas ben ik geen expert in RegExp, maar kan zo al op m'n klompen aanvoelen dat er honderden uitzonderingen zullen zijn op de regels die ik dan wel zou kunnen maken.

Zie ik iets over het hoofd, of zijn dit echt m'n enige opties ?

Iedereen wil terug naar de natuur, maar niemand wil lopend...

vrijdag 1 april 2011 20:54

Acties:

0 Henk 'm!

C0rnelis

Is inline-css geen optie?
Voor de rest snap ik sowieso zo niet waarom jouw css de rest van de pagina kan beinvloeden als je dit gewoon afschermt.

code:

1
2
3

<p id="myemail">
email content
</p>

Als je hiermee alle css begint met '#myemail' mag niet hier geen elementen daarbuiten beinvloeden..

vrijdag 1 april 2011 21:17

Acties:

0 Henk 'm!

MichielioZ

Topicstarter

C0rnelis schreef op vrijdag 01 april 2011 @ 20:54:
Is inline-css geen optie?
Voor de rest snap ik sowieso zo niet waarom jouw css de rest van de pagina kan beinvloeden als je dit gewoon afschermt.
code:
1
2
3
<p id="myemail">
email content
</p>
Als je hiermee alle css begint met '#myemail' mag niet hier geen elementen daarbuiten beinvloeden..

Dank je voor de input, maar volgens mij begrijp je niet helemaal wat ik bedoel...
Het probleem doet zich niet voor bij email die ik zelf zou willen maken, maar bij het laten zien van een ontvangen email.
Als ik zoiets in een DIV zet, krijg je dus zoiets:

HTML:

<div id="mijnemail">

<html>
 <head>
    <style type="text/css">
     body { background: red; }
    </style>
</head>
<body>
<!--EMAIL BODY-->
</body>
</html>

</div>

(Alles in de DIV komt dus binnen als email)

Iedereen wil terug naar de natuur, maar niemand wil lopend...

vrijdag 1 april 2011 22:16

Acties:

0 Henk 'm!

C0rnelis

Ik snap hem, jij vind het dus raar dat de style body tag de rest van de body ook rood kleurt. Of vind je het niet raar? Je zoekt daar dus sowieso iets voor, hoe vaak komt het voor dat een email een style block heeft? (Ik weet wel van een paar emailhosts dat die styleblocks gewoon niet ondersteunen.

1 optie die waarschijnlijk niet optimaal is, is dat je bij je eigen css overal !important neeren de selectors heel goed maakt zodat deze de e-mails niet beinvloeden. Op deze manier kan de css van je e-mail voorgaande css niet overschrijven

vrijdag 1 april 2011 23:45

Acties:

0 Henk 'm!

mocean

Als je geldige HTML wil houden, kan je sowieso geen head/html/body tags in een <div> gaan stoppen. Die zullen er sowieso uit moeten. De <style> in een div is ook al ongeldige HTML.

Wil je het goed aanpakken, dan moet je het <style> blok eruit halen, de <body> in de e-mail verplaatsen naar je <div id="mailbody"> o.i.d. en dan de Style parsen en aan je head <style> toevoegen (met overal voor de tags toegevoegd: #mailbody). Heel veel regexp zal dat niet worden.

Let ook op spam met <script>, onload="" Javascripts etc. of <iframe> in emails die moet jer er ook echt uitfilteren want is een enorm security risk.

Koop of verkoop je webshop: ecquisition.com

vrijdag 1 april 2011 23:50

Acties:

0 Henk 'm!

spone

Vaak zie je voor dit soort constructies een iframe gebruikt worden, zodat de email zelf geïsoleerd is van de rest van de pagina. Dit zie je bijvoorbeeld bij Exchange (owa), dingen als RoundCube, SquirrelMail en Horde.

[ Voor 25% gewijzigd door spone op 01-04-2011 23:51 ]

i5-14600K | 32GB DDR5-6000 | RTX 5070 - MacBook Pro M1 Pro 14" 16/512

vrijdag 1 april 2011 23:59

Acties:

0 Henk 'm!

mocean

spone schreef op vrijdag 01 april 2011 @ 23:50:
Vaak zie je voor dit soort constructies een iframe gebruikt worden, zodat de email zelf geïsoleerd is van de rest van de pagina. Dit zie je bijvoorbeeld bij Exchange (owa), dingen als RoundCube, SquirrelMail en Horde.

Iframe is makkelijker ja, neemt niet weg dat je nog steeds moet filteren (regexps?) op allerlei javascripts & (i)frames

Koop of verkoop je webshop: ecquisition.com

zaterdag 2 april 2011 15:19

Acties:

0 Henk 'm!

MichielioZ

Topicstarter

mocean schreef op vrijdag 01 april 2011 @ 23:59:
[...]

Iframe is makkelijker ja, neemt niet weg dat je nog steeds moet filteren (regexps?) op allerlei javascripts & (i)frames

Je hebt gelijk, had er nog niet direct aan gedacht dat ik sowieso moest filteren en ben daarom aan de slag gegaan met RegExps.
Volgens mij als ik de volgende "grote" opdelingen eerst maak, moet ik er wel uitkomen:
- Haal de strings op van alles tussen 'script'-, 'style'- en de 'body'-tag(s)
- Laat 'script' weg, pas 'style' aan (lastig, maar denk wel te doen)
- Haal iframes uit de 'body' en zet daarna de inhoud ervan in een DIV of eventueel een iframe (weet niet of dat dan nog nodig is ?!)

Ik ga maar eens aan de slag dan...

Iedereen wil terug naar de natuur, maar niemand wil lopend...

zaterdag 2 april 2011 15:22

Acties:

0 Henk 'm!

Verwijderd

HTML en regular expressions zijn bijna altijd een no-go. Gebruik een volwaardige HTML parser.

zaterdag 2 april 2011 15:52

Acties:

0 Henk 'm!

MueR

Admin Tweakers Discord

is niet lief

Je zult inderdaad een wat betere manier moeten verzinnen. Blind met strip_tags script verwijderen beschermt namelijk voor geen meter tegen onmouseover, onclick en andere scripts.

Anyone who gets in between me and my morning coffee should be insecure.

zaterdag 2 april 2011 18:12

Acties:

0 Henk 'm!

MichielioZ

Topicstarter

MueR schreef op zaterdag 02 april 2011 @ 15:52:
Je zult inderdaad een wat betere manier moeten verzinnen. Blind met strip_tags script verwijderen beschermt namelijk voor geen meter tegen onmouseover, onclick en andere scripts.

strip_tags was ik sowieso niet van plan te gebruiken...
Ik kan inderdaad een "full-fledged" HTML Parser gebruiken, maar is dat geen overkill ?!
Als ik er alle 'script'-tags uitgooi, dan de html in de 'body' (die tag gaat zelf ook weg, dus geen onload of zoiets meer) opschoon door 'onclick','onchange' etc. eruit te halen (zoveel opties zijn er niet lijkt me) en dan nog alle iframes eruit gooi, heb ik dan nog iets belangrijks over het hoofd gezien ?!
Zover ik kan bedenken kan bovenstaande met een paar slimme RegExp regels op te lossen zijn namelijk...

Iedereen wil terug naar de natuur, maar niemand wil lopend...

zaterdag 2 april 2011 22:22

Acties:

0 Henk 'm!

mocean

Er zijn wel meer JS tags dan onclick & onchange, let daarop: onload, onerro etcr. En ook nog via css expressions zelfs zijn vervelende dingen mogelijk

Koop of verkoop je webshop: ecquisition.com

zondag 3 april 2011 14:13

Acties:

0 Henk 'm!

MichielioZ

Topicstarter

Ok, waarschijnlijk ben ik gewoon weer eigenwijs, maar heb nu het volgende ondervangen:
Alle 'script' en 'iframe' tags eruit gegooid.
De 'style' en 'link' (naar stylesheets) moet ik nog aanpassen en/of verwijderen.
Ik werk daarna alleen nog maar met de code tussen de 'body' tag, waar ik de volgende events al uitgehaald heb:
http://www.w3.org/TR/html4/interact/scripts.html#events
Ten slotte laad ik alles in een iframe als het om HTML email blijkt te gaan. (Tekst gaat rechtstreeks in de DIV)

Nogmaals, waarschijnlijk gewoon eigenwijs van mij, maar ik kan niet echt dingen bedenken die ik hiermee niet ondervang (maar moet dus nog kijken hoe ik CSS ga doen).

Iedereen wil terug naar de natuur, maar niemand wil lopend...

zondag 3 april 2011 19:59

Acties:

0 Henk 'm!

drm

f0pc0dert

Het grootste nadeel van regexpen in dergelijke gevallen is dat je eigenlijk bijna altijd moet blacklisten i.p.v. whitelisten. Blacklisten is geen goeie securitymethode, omdat je er dan vanuit gaat dat je alle mogelijk schadelijke combinaties van tekens bedacht hebt. Whitelisten is veiliger omdat je dan kunt bedenken wat allemaal zonder twijfel veilig is. Aangezien de oplossing voor whitelisten al gauw is dat je de boel moet gaan parsen, is het direct handiger om een echte parser te gebruiken. Je zou bijvoorbeeld een DOMDocument kunnen inlezen en daar vervolgens een XSLT tegenaan kunnen gooien, die gewoon alleen die tags op die manier opmaakt die jij toe wilt staan. Als de parser dan over zijn nek gaat, mag je er vanuit gaan dat de HTML niet in orde is en kun je volgens het MIME multi-part/alternative principe terugvallen op de plain tekst variant die in de meeste gevallen in de mail aanwezig zal zijn, of terugvallen op een text/plain weergave van de oorspronkelijke HTML met een strip_tags() eroverheen.

Overkill is trouwens geen argument, zeker niet als het om security gaat.

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

maandag 4 april 2011 18:11

Acties:

0 Henk 'm!

mocean

Voor PHP is er een mooie PEAR class die e.e.a. kan afhandelen:
Mail_Mime. Ik gebruik die zelf ook naar tevredenheid.

DOMDocument zal vaak failen (denk ik), het is ongelooflijk wat voor slechte/ongeldige HTML en MIME mails er verstuurd worden.

Koop of verkoop je webshop: ecquisition.com

dinsdag 5 april 2011 09:10

Acties:

0 Henk 'm!

moozzuzz

mocean schreef op maandag 04 april 2011 @ 18:11:
Voor PHP is er een mooie PEAR class die e.e.a. kan afhandelen:
Mail_Mime. Ik gebruik die zelf ook naar tevredenheid.

DOMDocument zal vaak failen (denk ik), het is ongelooflijk wat voor slechte/ongeldige HTML en MIME mails er verstuurd worden.

Ik dacht ook meteen aan Mail_mime. Verder je style blocks converteren door elke } te vervangen door } #myemail

code:

1 2	string styleblock; styleblock = '#emailblock' + styleblock.stringreplace('}','} #emailblock');

Onderwerpen