Ma jött Rich, hogy milyen jó lenne, ha lenne a nyilvános weblapunkon üzenetküldési lehetőség, mert hiába van kinn az e-mail cím csak képként, és nem szövegként, az okos spammerbotok szövegfelismeréssel abból is kinyerik a szöveget. Azt hiszem, fejlődök -- ez nagyjából két hete is felmerült, és akkor kerek perec elmondtam, hogy ilyet nem tudok, ma viszont nagyjából két óra munka után előállt a megoldás.

 

Az első gondolata az embernek a könyv szerinti megoldás -- az üzeneteket tároljuk egy SharePoint listában, aztán arra a listára vegyünk fel egy event handlert, ami, ha érkezik egy új elem, küld egy e-mailt. Ez azonban több sebből is vérzik: egyrészt a nyilvános webszerverünk adatait minden éjjel fejbecsapjuk, és egy belső szerverről Content Deploy-oljuk ki az új tartalmat, másrészt a blogos kalandjaim tapasztalata az, hogy képtelen vagyok megoldani, hogy anonim módon adatokat lehessen felvenni egy Publishing Site-ra.

 

Rövid gondolkodás és nagyjából húsz perc SharePoint Designer-rel való harc után előállt az első megoldás, ami minden PHP fejlesztőnek is először eszébe jutna: csináltam két ASPX-et, az egyik feldob egy formot, amit átküld a másik címére, a másik pedig a form-ból kinyert üzenetet elküldi e-mailben, és HTTP redirect-tel továbbküldi a böngészőt egy másik oldalra.

 

¡Que bien! -- van egy működő megoldásunk, ami viszont nem túl szép: sok C# kód van az ASPX-ekben, amikbe bele van drótozva az SMTP szerver neve meg a e-mailcím, ahova az üzeneteket küldeni kellene. Ugyan az üzenetet fogadó ASPX-szel nem tudok mit kezdeni, oda mindenképpen kell kód, viszont a formot feldobó lap egy részét kiemelhetem egy Web Part-ba, és a Web Part paraméterei között szerepelhet az e-mailcím meg az SMTP szerver neve is.

 

Eltartott egy darabig, amíg végiggondoltam, hogy a fogadóoldalon levő kód honnan is fogja megtudni a küldő Web Part paramétereit, de aztán végül megoldottam -- a HTTP referrerből ki lehetett venni a forrásoldalt, az SPContext.Current-ből pedig a a Site Collection-t, ahol vagyunk. Az e-mailküldő kódot is áttettem a Web Part osztályába, hogy minél kevesebb kód legyen az ASPX-ben (SharePoint Designer-rel nem nagyon kényelmes C# kódot írni, arra való a Visual Studio...), aztán meglepődve tapasztaltam, hogy az ASPX lapokon levő kódnak több Code Access Security joga van, mit a Web Part osztályoknak. Hál'Istennek a WSS_Medium jogosultsági szinttel lehet a SharePoint objektummodellt is használni, meg lehet levelet is küldeni, úgyhogy nem kellett saját jogosultsági szintet csinálni, elég volt egy sort átírni a web.config-ban. Ha kellett volna, valószínűleg kiegyezek az ASPX-ben levő kóddal inkább...

 

A következő szint az lenne, hogy ne legyen kód egyáltalán ASPX-ekben. Az kellene, hogy valahogy meg tudjak hívni egy kliensoldalról C# kódot a szerveren, de erre nem láttam semmilyen lehetőséget -- valahogy megoldja a Central Administration is, tehát biztos vagyok benne, hogy lehet, viszont mára már nem maradt erőm utánanézni, hogy az hogyan működik.

 

Per pillanat az sem működik, hogy több ilyen Web Part legyen egy lapon, mert fix ID-ket és függvényneveket tesz a HTML-be. Ezt meg lehetne oldani, de nem hiszem, hogy sor fog erre kerülni: nekünk tökéletesen megfelel így is, és többet dolgozni a szükségesnél a You Aren't Gonna Need It elv alapján teljesen felesleges.