Helyettesítő karakter DNS és dinamikus aldomainek

Szabadidőmben (ha!) Azon dolgoztam, hogy beburkoljam Vadmadarak korlátlan térképe alkalmazás egy vállalati alkalmazással, amely lehetővé teszi az emberek számára, hogy megtervezzék saját áruház-lokátorukat. Saját szoftver fejlesztése mint szolgáltatási megoldás jó néhány éven át célom volt, és ez egy nagyszerű lehetőség.

Két olyan kulcsfontosságú jellemző van a polcról, amelyeket be akartam rakni az alkalmazásba, és amelyek hatalmas kihívásnak bizonyulnak, ezért meg akartam vitatni őket abban az esetben, ha valaha is ugyanezt akarja csinálni. Mindkét szolgáltatás mindennapos az alkalmazásokban, de rájöttem, hogy bár mindennaposak, sok tárhelyszolgáltató valójában nem támogatja őket!

Célom egy önkiszolgáló alkalmazás felépítése, ahol az ügyfél beállíthatja saját aldomainjét (http://aldomain.myapplicationdomain.com), vagy akár saját aldomainjüket is alkalmazzák (http://aldomain.domain.com). Annak érdekében, hogy önkiszolgáló legyen, megköveteli a megoldás programozásának képességét - de hozzáfér a tartománynév-kiszolgáló konfigurációs fájljaihoz, amelyek a tárhely-fiókok többségével nem elérhetőek! A kérdés a Wildcard DNS támogatása, vagyis annak lehetővé tétele, hogy bármely aldomain a szerver tartományára mutasson. Más szavakkal, a test.domain.com, a www.domain.com vagy az any.domain.com mind ugyanarra a helyre mutat. Nem számít, mit írsz - működni fog.

Az alkalmazásokon kívül ez valójában egy nagyon szép funkció, amelyet engedélyeztek - akár a blogodon is. Lehetővé tenné, hogy bárki írjon bármi.domain.com és elhozni őket yourdomain.com. Meglepődne azon, hogy hány rossz link mutat a blogjára vagy webhelyére. Ez elmaradhat a forgalomtól, ha az illető nem ismeri fel, hogy a link hibája.

A folyamat úgy működik, hogy átírja az aldomainet egy lekérdezési karaktersorozatba, mielőtt az weboldalt a webszerver ténylegesen megjelenítené ... így az subdomain.domain.com-ot az Apache szerverek valójában domain.com?what=subdomain-ként értelmezik egy htaccess fájl használatával:

# Bontsa ki a domain.com aldomain részét
RewriteCond% {HTTP_HOST} ^ ([^ \.] +) \ .Domain \ .com $ [NC]
 
# Ellenőrizze, hogy az aldomain része nem www, és ftp és mail
RewriteCond% 1! ^ (Www | ftp | mail) $ [NC]
 
# Minden kérést átirányít egy php szkriptre, amely az aldomain argumentumaként megy át
RewriteRule ^. * $ Http://www.sajatdomain.com/%1 [R, L]

Van néhány további információ a fájlokról, amelyeken szerkesztenie kell V-nessa.net. Ne feledje, hogy a fájlok a tárhelyszolgáltatótól függően nem feltétlenül találhatók meg a megadott helyen. Tárhelyszolgáltatóm valóban nagyon támogatja a beavatkozókat, de figyelmeztetnek arra, hogy ezzel érvénytelenítheti az ügyfélszolgálatot. A „saját felelősségedre történő feltörés” mellett nem fognak segítséget nyújtani neked sem.

Dolgozni fogok az alkalmazás többi részének fejlesztésén, ahelyett, hogy leragadnék az aldomain fejlesztésén. Igazából adni fogok CakePHP egy lövés, amelyet keretként használhatunk hozzá!

Utolsó megjegyzés: egy kicsit csapkodom ezeket a dolgokat. Meg vagyok áldva a fejlesztő csapatok munkájával, hogy rájöjjek ezekre a dolgokra. Önmagamban kicsit veszélyes vagyok. Minden visszajelzést és segítséget értékelünk!

3 Comments

  1. 1

    Nagyon cool. Amikor a SliceHost-nál voltam, a regisztrátor névkiszolgálóját helyettesítő DNS-sel használtam, és az Apache-t úgy konfiguráltam, hogy a szokásos tartományfájlokból konfigurálatlan aldomaineket szolgáltasson.

    Nagyon érdekelt, hogy megnéztem a CakePHP keretrendszert, de a kapcsolatod halott 🙂

    A CakePHP a címen található http://cakephp.ORG

    • 2

      Arra gondoltam, hogy megyek a regisztrációs útvonalon is, Alex. Ez egy remek ötlet - valószínűleg a legjobb módszer ennek kezelésére.

      Elnézést a holt link miatt - ez most kijavítva.

  2. 3

Mit gondolsz?

Ez az oldal Akismet-et használ a levélszemét csökkentése érdekében. Ismerje meg, hogyan dolgozik a megjegyzésed.