Darek przeprowadzil ostatnio maly rekonesans po dostepnych domenach i dal mi cynk, ze domena zine.net.pl jest wolna :) Gdy sprawdzalem ja jakis czas temu, to byla w uzyciu przez jakis site muzyczny (choc moge sie mylic), ale zdaje sie autorzy zrezygnowali, wiec teraz domena trafila do nas. Dzieki wsparciu Ziemka Borowskiego z DCS (dzieki!!) zine.net.pl praktycznie od reki moglem delegowac na serwery hostedwindows.pl.
Przy okazji przejrzalem logi serwisu i okazuje sie, ze na strone zina sporo osob wchodzi przez google, gdzie zine funkcjonowal jako zine.aspnet.pl, czy tez zine.hostedwindows.pl (nie mowiac juz o najswiezszych linkach po postach na wss.pl oraz codeguru.pl, ktore wskazuja na zine.hostedwindows.pl). Oczywiscie serwis ma ustawione odpowiednie host headers i wlasciwie nie byloby z tym problemu, gdyby nie to, ze chcialbym jednak ustalic jedna nazwe dla calego serwisu. A zatem osoby, ktore korzystaja z linkow wskazujacych na zine.aspnet.pl (i nie tylko) byly z automatu przekierowywane na zine.net.pl, tak, zeby w przyszlosci korzystaly jednak z tej nazwy.
W pierwszej chwili myslalem, zeby poprosic Ziemowita z DCS o pomoc i odpowiednie ustawienie aplikacji na poziomie IIS'a, ale jakos nie moglem sobie uswiadomic gdzie taki redirect mozna ustawic. Gdybym mial dwie aplikacje w IIS'ie, to oczywiscie na drugiej mozna ustawic w host headers wszystkie te, z ktorych chce zrezygnowac i jako sciezke aplikacji wskazac przekierowanie na pierwsza, na ktorej w host headers mam zine.net.pl. Problem w tym, ze w ramach hostingu nie mam takiego komfortu, wiec pomyslalem wtedy (za rada Ziemka Skowronskiego) o niestandardowych naglowkach w ustawieniach IIS (Location), ale to rozwiazanie u mnie przynajmniej nie dzialalo. Szukalem troche czegos o .htaccess dla IIS, ale dosyc szybko odpuscilem.
Wtedy przypomnialem sobie, ze w DotNetNuke funkcjonuja aliasy serwisu (konfigurowane w ramach samej aplikacji) i w przypadku gdy tylko jeden jest ustawiony, to niezaleznie od ustawionych host headers na poziomie IISa nastepuje automatyczny redirect. HTTPAliasses dzialaja we wspolpracy z URLRewriter HttpModule wspierajcym Friendly URLs dla DNN, a tu juz jest bardzo blisko do samego rozwiazania.
Zine.net postawiony jest jednak na CommunityServerze, a nie DotNetNuke i oczywiscie zajrzalem do zarejestrowanego w web.config modulu CommunityServer.CSHttpModule z CommunityServer.Components.dll. Po chwili przegladania kodu moja uwage przykul WWWStatus - ustawienie dostepne w pliku communityserver.config z dostepnymi trzema opcjami: Remove, Require badz Ignore. W przypadku ustawienia 'Remove' zapytania przychodzace na www.domena.com sa automatycznie przekazywane na domena.com (domyslna opcja csa!!) i w przegladarce mamy adres bez 'www' na poczatku. W przypadku 'Require' sytuacja ma sie odwrotnie i 'www' zawsze wystepuje w adresie, Ignore natomiast pomija calkowicie sprawdzanie adresu. W pierwszej chwili chcialem 'poprawic' ten kawalek kodu CSa, ale w rezultacie napisalem caly nowy modul implementujacy IHttpModule do tego jakze prostego zadania. Chcac w przyszlosci uniezaleznic sie od koniecznosci kompilacji kodu w celu poprawienia jednego adresu skorzystalem z System.Configuration.ConfigurationSection z System.Configuration.dll, dzieki czemu podstawowe parametry moge wrzucic do web.config i poprawiac je niezaleznie od kodu modulu. Ponizej kod samego modulu (jest na tyle krotki, ze bez problemu mozna go umiescic w calosci):
using System;
using System.Collections;
using System.Collections.Generic;
using System.Configuration;
using System.Text;
using System.Text.RegularExpressions;
using System.Web;
using System.Xml;
namespace pl.net.zine.Rewriter
{
//modul do przekierowywania
public class ZineRewriter : IHttpModule
{
private static List<Regex> regexes = new List<Regex>();
public void Init(HttpApplication app)
{
ZineRewriteHandler zrh = (ZineRewriteHandler)ConfigurationManager.GetSection("ZineGroup/Rewrite");
if (regexes.Count == 0)
{
foreach (string url in zrh.From.Split(';')) //kilka roznych adresow do przekierowania w jedno miejsce
{
regexes.Add(new Regex(url, RegexOptions.Compiled | RegexOptions.IgnoreCase));
}
}
app.BeginRequest += new EventHandler(BeginRequest);
}
void BeginRequest(object sender, EventArgs e)
{
ZineRewriteHandler zrh = (ZineRewriteHandler)ConfigurationManager.GetSection("ZineGroup/Rewrite");
HttpApplication application = sender as HttpApplication;
Uri url = application.Context.Request.Url;
Regex regex = regexes.Find(delegate(Regex r) { return r.IsMatch(url.ToString()); });
if (regex != null) //default dla Regex = null jak nic nie znaleziono
{
String redirectURL = regex.Replace(url.ToString(), zrh.To);
application.Context.Response.Redirect(redirectURL);
}
}
public void Dispose() { }
}
//obsluga sekcji w web.config
public class ZineRewriteHandler : ConfigurationSection
{
public ZineRewriteHandler(){}
[ConfigurationProperty("From", IsRequired = true)]
public String From
{
get { return (String)this["From"]; }
set { this["From"] = value; }
}
[ConfigurationProperty("To", IsRequired = true)]
public String To
{
get { return (String)this["To"]; }
set { this["To"] = value; }
}
}
}
Odpowiednie sekcje web.config wygladaja mniej wiecej tak:
<configuration>
<configSections>
<sectionGroup name="ZineGroup">
<section
name="Rewrite"
type="pl.net.zine.Rewriter.ZineRewriteHandler, pl.net.zine.Rewriter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
allowLocation="true"
allowDefinition="Everywhere"
/>
</sectionGroup>
<!--inne sekcje-->
</configSections>
<ZineGroup>
<Rewrite
From="//[a-z0-9.-]*\.(hostedwindows|aspnet|winweb)\.pl"
To="//zine.net.pl"/>
</ZineGroup>
<system.web>
<httpModules>
<add name="ZineRewriter" type="pl.net.zine.Rewriter.ZineRewriter, pl.net.zine.Rewriter"/>
<!--inne moduly-->
</httpModules>
<!--inne sekcje-->
</system.web>
<!--reszta pliku-->
</configuration>
Takie proste ustawienia, zawierajace tylko jedna regule sa dobre dla takiego serwisu jak ten, gdzie nie potrzeba nic wiecej. Zauwazmy jednak, ze taki modul mozna postawic na aplikacji iisowej z ustawionym pustym host headers (default) i sterowac przekierowaniami do odpowiednich serwisow zaleznie od przychodzacego zapytania. Co wiecej, w host headers na iisie nie ma jak ustawic wildcardow (np. '*'), czyli np. dla zapytan typu ala.zine.net.pl, kot.zine.net.pl, ktore sa prawidlowo przekierowywane z dnsa, a nie sa explicite ustawione w host headers aplikacji zine'a, trafiaja na aplikacje z defaultem - czyli w przypadku tutejszego hostingu jest to hostedwindows.pl (mozna sprawdzic! :) ). Wowczas takie zapytania latwo przekazac wlasnie korzystajac z takiego 'gatewaya', ktorego jak widac mozna w miare szybko zaimplementowac. Oczywiscie nalezaloby wowczas nieco rozwinac sekcje konfiguracyjna modulu i udostepnic liste regul zamiast pojedynczego wpisu.
Przy powazniejszych zabawach mozna pomyslec o asynchronicznej obsludze zdarzenia BeginRequest obiektu aplikacji (cos na wzor "app.AddOnBeginRequestAsync(new BeginEventHandler(beginRequestAsync), new EndEventHandler(endRequestAsync));"), posilkujac sie przykladami Jeffa Prosise'a zamieszczonymi w ostatnim MSDN Magazine
Uwaga koncowa: zine.net.pl co prawda ma ustawionego MX'a w DNSie (dzieki, Ziemek!), ba - ma nawet odpowiedni rekord SPF (!!!), ale nie ma odpowiednich kont pocztowych zdefiniowanych na serwerze pocztowym i dlatego prosze nie wysylac na adres tytulowy zadnych maili - do odwolania :)