|
|
2007. 02. 20.
Jött a következő bugreport: ha egy új számítógépen megnyitják az Abesse weboldalát (ezt), akkor az Internet Explorer 7 panaszkodik, hogy a NAME.DLL-ben levő ActiveX control-t szeretné használni a weblap.
Ez valóban nem túl szép dolog egy publikus portálról... rövid Googlézés után megtaláltam ezt a KB cikket, ami leír egy megoldást, viszont az nem túl szép -- nem nem szeretnék turkálni a fájlrendszerben azért, hogy egy portál működjön.
Rövid gondolkodás után a következő kódot másoltam be a master page-be -- ugyanaz a hatása, mint a KB cikkben említett módosításnak, viszont jóval kevésbé kell hozzá a rendszer mélyére nyúlni:
<script type="text/javascript" language="javascript">
ProcessImn = function() { };
</script>
2007. 02. 16.
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.
Továbbra is próbálom megoldani az anonim elérést a blogrendszerrel, de van még hova fejlődni.
Tegnap jött Blázi, hogy nem működik az RSS feed a blogokhoz a nyilvános weblapon. Két kattintás után nyilvánvalóvá vált, hogy miért: azért, mert az RSS-es linkek arra a lapra mutatnak, amit nem sikerült megoldani, hogy anonim felhasználók is elérhessenek (/Lists/Posts/ViewPost.aspx?ID=postId). Erre a workaround az lett, hogy a megfelelő .aspx-et kiemeltem a site gyökerébe, és mindenhol átírtam a rámutató linkeket.
Igen ám, de másfél nap kísérletezés után sem sikerült megoldani, hogy az RSS-ekben átírjam a linket. Jött a B. megoldás: hátha az ISA Server 2006-on lehet reguláris kifejezés alapú linkátírást csinálni. De nem, az ISA 2006 ezt nem tudja. Mi legyen?
A megoldást végül Debre Attila szállította: Ionic's ISAPI Rewrite Filter-nek hívják, ingyen van, és ugyanazt csinálja, mint a mod_rewrite az Apache világban.
Ez az utility azért is hasznos, mert mikor a www.abesse.hu MOSS 2007 alapokra helyeződött, a régi, Google által jól ismert lapok eltűntek a keresők szeme előtt, tehát jelenleg a PageRank-jük 0. Az átirányítás viszont segíthet abban, hogy az új, MOSS 2007 által menedzselt oldalak is előrébb lépkedjenek a találati listán, mivel a Google keresője így ismeri a hozzájuk vezető utat. Na meglátjuk, hogy mennyi idő visszaszerezni egy ilyen 4-5-ös PageRank-et… sőt, ezzel a régi külső linkek is működőképesek maradnak.
2007. 02. 14.
Üdvözlet!
A legelső, amiről szeretnék írni, az mindenképpen a MOSS 2007 blog site-ja. Ez elméletileg arra való, hogy könnyen és gyorsan lehessen vele blog site-okat létrehozni, személyreszabni, publikálni.
Gyakorlatilag viszont ezer és egy problémába futottam bele, amik közül néhányat megoldottam, néhányat nem sikerült. Azon, hogy hogyan kell a blog kinézetét testre szabni, átverekedtem magam (annak ellenére, hogy nem kevés CAML-lel kellett megküzdenem. Ez a SharePoint 2007 listákat leíró nyelve -- többek között a lista megjelenését írja le, úgy, hogy az XML-alapú CAML-be kell HTML darabkákat ágyazni. Nem túl szép a dolog...).
Legyőztem azt a problémát is, hogy én, a cég egyik SharePoint-os embere lévén, elég sokféle adminisztrátor vagyok a MOSS szemében, és valamiért Content Deployment során szereti a nevemet lecserélni a nemesen egyszerű System Accountra.
Abba viszont beletörött a bicskám, hogy hogyan lehet megoldani, hogy anonim felhasználók is megnézhessék a hozzászólásokat. Eszerint a bejegyzés szerint nem én vagyok az egyetlen, aki ezzel a problémával küzd, csak sajnos az RTM verzióig sem sikerült kijavítani ezt a dolgot. Megpatkoltam olyképpen, hogy a Post.aspx-et áttettem a lista alól a site gyökerébe, és működik is -- viszont arra még nem jöttem rá, hogy hogyan lehet rávenni az RSS-t, hogy az így módosított linkeket dobja ki.
Hogy anonim felhasználók írjanak kommenteket, arra már gondolni sem merek -- a használt infrastruktúránkból adódóan ez nem is működhetne (hiszen minden nap felülcsapja a nyilvános szerveren levő adatbázist a Content Deployment), de némileg frusztráló, hogy ha akarnám, se tudnék ilyet csinálni.
Ezért a kedves olvasó hiába is tudja a megoldást erre a problémára, nem tudja elmondani nekem, hogy mit rontok el :)
Viszont: van nekünk egy szép belső portálunk is, amin elsőre látszik, hogy SharePoint-tal készült, és az fényesen működik -- ahhoz képest, hogy milyen kevés ideje került be a köztudatba, az emberek használják: írnak cikkeket a wiki-re, játszanak a My Site-tal, jönnek hozzám, hogy ezt meg ezt esetleg lehetne-e... tök jó!
 |
|
|
|
|
|