Frage individuelle User-Domains aufschalten

[xSTVNx]

Mahlzeit,

Auf meiner Webseite gibt es User-Shops. Aktuell haben deren URLs folgendes Schema:

http://domain.tld/usershop                    <!-- Startseite -->
http://domain.tld/usershop/warenkorb        <!-- Warenkorb -->
http://domain.tld/usershop/kategorie1        <!-- Kategorie -->
http://domain.tld/usershop/kategorie2        <!-- Kategorie -->
http://domain.tld/usershop/kategorie3        <!-- Kategorie -->
http://domain.tld/usershop/-xxxxxxxxxx        <!-- einzelner Artikel -->

Ich würde nun gern die Möglichkeit anbieten, dass man eine eigene Domain aufschalten kann, sodass die entsprechenden URLs dann bspw. wie folgt lauten:

http://usershop.tld                  <!-- Startseite -->
http://usershop.tld/warenkorb          <!-- Warenkorb -->
http://usershop.tld/kategorie1        <!-- Kategorie -->
http://usershop.tld/kategorie2        <!-- Kategorie -->
http://usershop.tld/kategorie3        <!-- Kategorie -->
http://usershop.tld/-xxxxxxxxxx        <!-- einzelner Artikel -->

Dass die URL im DOM geändert wird, habe ich schlicht dadurch erreicht, dass in einem Datenbank-Feld custom_domain die Domain hinterlegt wird, sowie durch custom_domain_active aktiviert wird. Und die Konstante für die interne Verlinkung entspricht eben entweder custom_domain oder der Kombination aus Slug des Usershops und der Domain meiner Webseite.

Nun ist eben meine Frage: Wie schalte ich die Userdomains auf?
Gibt es da mehrere Lösungen? Falls ja, welche ist die eleganteste?
Welche Probleme gibt es evtl.? Was sind eure Erfahrungen?
usw.

Danke und LG :)

 

[Aaron3219]

Wenn ich dich richtig verstanden habe, dann kann ich mich auf deiner Seite registrieren, einen User-Shop aufmachen und meinen Shop unter http://domain.tld/aaronsshop/ o.ä. aufrufen. Jetzt hast du vor, dass ich meinen Shop auch unter http://aaronsshop.tld/ aufrufen kann.

Ansatz #1 - Die URL z.B. mit der History Web API verändern

Ein möglicher Ansatz, bei dem es allerdings daran scheitert, dass es schlichtweg nicht möglich ist. Die Dokumentation sagt bereits:

The new URL must be of the same origin as the current URL; otherwise, pushState() will throw an exception.

Das ist auch gut so, denn ansonsten könntest du ja z.B. auf eine Fake Google-Seite gehen, die allerdings einfach die URL so verändert, dass es nun die richtige Google-URL ist.

Wenn du also deinen Domain-Namen und die Top-Level Domain nicht ändern kannst, könnte man sich ja fragen, ob man nicht einfach für jeden User eine Domain registriert.

Ansatz #2 - Jeder User kriegt seine eigene Domain

Selbst wenn wir Komplikationen durch bereits vergebene Domain-Namen ausklammern, wird auch dieser Ansatz nichts werden. Dazu muss man verstehen, wie Domains registriert werden.

Eine Registry (Network Information Center) verwaltet Domains. Die Domains müssen dann auf sogenannten Nameservern in einer Zonendatei hinterlegt sein. Die Zonendatei verweist auf die Nameserver und so weiter...

Dieser Ansatz kommt also auch nicht infrage, zumal du erst eine Registrierungsorganisation werden müsstest.

Mögliche Lösung - Jeder User kriegt seine eigene Subdomain

Was möglich ist, ist, dass jeder User seine eigene Subdomain bekommt, also z.B. http://aaronsshop.domain.tld/. Dies lässt sich durch die richtigen Einstellungen des Servers (nginx.conf, .htaccess, etc.) und entsprechendes Routing innerhalb der Applikation verhältnismäßig einfach umsetzen.

Das ganze nennt sich im übrigen Multi-Tenant-Applikation. Subdomains für jeden "Tenant" ist eine valide Umsetzung.

 

[xSTVNx]

Wenn ich dich richtig verstanden habe, dann kann ich mich auf deiner Seite registrieren, einen User-Shop aufmachen und meinen Shop unter http://domain.tld/aaronsshop/ o.ä. aufrufen. Jetzt hast du vor, dass ich meinen Shop auch unter http://aaronsshop.tld/ aufrufen kann.

Genau das ist mein Anliegen, korrekt. :)

Aber das müsste doch gehen, wenn bspw. der User in der Domain die Nameserver von meinem Hoster (all-inkl) angibt, und ich dann die entsprechenden (Nur welche?) Zeilen in die .htaccess-Datei schreibe, oder?

Mögliche Lösung - Jeder User kriegt seine eigene Subdomain

Was möglich ist, ist, dass jeder User seine eigene Subdomain bekommt, also z.B. http://aaronsshop.domain.tld/. Dies lässt sich durch die richtigen Einstellungen des Servers (nginx.conf, .htaccess, etc.) und entsprechendes Routing innerhalb der Applikation verhältnismäßig einfach umsetzen.

Das ganze nennt sich im übrigen Multi-Tenant-Applikation. Subdomains für jeden "Tenant" ist eine valide Umsetzung.

Das ist mir (noch) nicht möglich (ist aber eh geplant als Standard), weil ich dazu, so wie ich es verstanden habe, erst ein Paket brauche, dass wildcards bietet. (Sonst müsste ich alle Subdomains von Hand erstellen, und diese sind eh begrenzt...)

Das wäre zwar fürs Erste okay, aber ich denke das richtige Domains nutzerfreundlicher wären. ;)

 

[xSTVNx]

Ich bin nun tatsächlich dem Ziel weit näher als ich es für möglich hielt. Augenscheinlich macht mir nurnoch eine RegEx einen Strich durch die Rechnung.

Mein aktueller Stand bzw. Schrittfolge:

1. Ich habe testweise bei einer Domain, die ich bei einem anderen Anbieter habe, die Nameserver meines Hosters (all-inkl) eingetragen. (Nachfolgend als usershop.tld genannt.)
   
   
2. Ich habe die Domain dem Hauptverzeichnis meines Projektes zugewiesen. (Nachfolgend als projekt.tld genannt.)
   
   
3. Ich habe in der .htaccess ganz am Ende folgendes eingefügt:
   

   RewriteCond %{HTTP_HOST} ^usershop.tld
   $RewriteRule ^(.*)$ shop.php?shop=usershop

   
   
4. a) In meiner MySQL-Datenbank habe ich in der Tabelle shop die Spalten domain und domain_active erstellt.
   b) Ich habe in domain die usershop.tld und in domain_active eine 1 eingetragen.
   
   
5. Am Anfang meiner shop.php wird die Konstante SHOP konstruiert:

   $s_slug = $_GET["shop"]; // $s_slug = 'usershop';
   $s_domain = sfwl("domain","shop","slug",$s_slug); // $s_domain = 'usershop.tld';
   
   if( !empty($s_domain) && $s_domain != null ){ # CUSTOM DOMAIN
       define( "SHOP",    "http://".$s_domain );
   } else {
       define( "SHOP",    url()."/".$s_slug ); // url() = 'http://projekt.tld';
   }

   
   Falls unklar ist, was meine Funktionen url() und sfwl() genau tun:
   
   url() gibt in diesem Fall lediglich http://projekt.tld zurück.
   
   sfwl() führt ein mysqli_query nach Schema SELECT ... FROM ... WHERE ... LIKE ... LIMIT 1 durch, gibt in diesem Fall also usershop.tld zurück.
   
   
6. Die einzubindenden Unterseiten (bzw. Fragmente, welche dann in Kombi mit Header, Footer usw. die Unterseite bilden) für Warenkorb, Merkliste, Produktübersicht, Produkt-Detailseite usw. des Shops durch die URL ermittelt. Für den Warenkorb und die Merkliste klappt das ganz einfach so:
   

   if( urlc() == SHOP.'/merkzettel/') { ... }
   if( urlc() == SHOP.'/warenkorb/')  { ... }

   (Die urlc()-Funktion gibt lediglich die aktuelle URL zurück.)
   
   Jetzt hapert es aber bei der Produkt-Detailseite.
   Jedes Produkt hat eine 10-stellige ID bestehend a-z & 1-9.
   Die URL eine Produkt-Detailseite hat das Schema http://projekt.tld/usershop/-XXXXXXXXXX/ bzw. http://usershop.tld/-XXXXXXXXXX/, also zu beachten wäre das der ID vorangestellte --Zeichen.
   
   Ich habe es so versucht:
   

   if( ( preg_match( '/('. SHOP .'\/-[a-z0-9]{10}\/)/', urlc() ) ){
       ...
   }

   
   Ich erhalte damit lediglich die Fehlermeldung: Warning: preg_match(): Unknown modifier '/' in ... on line ...
   
   Escape ich die / evtl. schlichtweg falsch?

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

So, ich hoffe ich konnte den Stand der Dinge nachvollziehbar schildern und hätte nun 2 konkrete Fragen:

1. Was ist an der in Punkt 6 genannten RegEx falsch? (hat sich erledigt)
   
   
2. Ist mein ganzer Lösungsansatz "sauber" oder sorgt das ganze Vorgehen eher für riesengroßes Kopfschütteln bei den Experten? (Falls Letzteres würde ich mich sehr über sachliche und erkenntnisreiche Kritik freuen.)

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Edit:

Bei der RegEx ist mir zumindest schonmal klar, dass das http:// in der SHOP-Konstante wohl einen Fehler verursachen wird, daher werde ich mal versuchen die Delimiter der RegEx von / ... / in # ... # zu ändern.

Edit 2:

Ich habe die preg_match-Funktion nun erfolgreich so abgeändert, dass dass die RegEx funktioniert und ich via $matches[1] auch gleich noch die Produkt-ID zur Verfügung habe:

preg_match( '#'. SHOP .'\/-([a-z0-9]{10})\/#', urlc(), $matches )

 

[Aaron3219]

Aber das müsste doch gehen, wenn bspw. der User in der Domain die Nameserver von meinem Hoster (all-inkl) angibt, und ich dann die entsprechenden (Nur welche?) Zeilen in die .htaccess-Datei schreibe, oder?

Um diesen Ansatz mal abzukürzen: Du wirst keine Domains registrieren können. Das, was ich erklärt habe, ist ja nur die oberste Spitze des Eisberges. Ein interessantes Thema, aber für einen Forenbeitrag zu groß. Es gibt ja schließlich Gründe, warum große Firmen (wie 1&1) die Domains registrieren.
Was gehen würde ist, dass du, oder der User selbst, für jeden User eine eigene Domain bei einem Domainregister kaufst. Jede Domain müsste dann auf deine Server pointen.

Das ist mir (noch) nicht möglich (ist aber eh geplant als Standard), weil ich dazu, so wie ich es verstanden habe, erst ein Paket brauche, dass wildcards bietet.

Das ist falsch. Eine Wildcard-Subdomain ist eine Server-Einstellung. Bei 1&1 kannst du z.B. eine Subdomain angeben, die folgende Struktur hat: *.deine-domain.de. Das ist eine Wildcard-Subdomain. Theoretisch könntest du jetzt (mit richtigen Servereinstellungen) was du willst davor schreiben und würdest die Seite besuchen können. Richtiges Routing + Einstellungen sorgen dann dafür, dass nur Subdomains besucht werden können, die als User hinterlegt sind.

Es gibt allerdings einen Haken. Man muss, um SSL-Schutz anbieten zu können, ein Wildcard-Zertifikat kaufen. Dieses Zertifikat bewirkt, dass du auch auf deinen Subdomains SSL-Schutz hast. Das ist dieses Wildcard-Paket, von dem du sprichst.



Antwort auf deinen 2. Beitrag:
Deine Applikation scheint mir sehr komplex zu sein. Multi-Tenancy Applikationen zu entwickeln, dann auch noch mit (Sub-)Domains für jeden User, ist ein Unterfangen, dass ohne das richtige Framework für einen einzelnen Menschen eine Lebensaufgabe ist. Auch mit einem Team ist es so unglaublich viel Mehraufwand, dass es sich überhaupt nicht lohnen würde, ohne Framework zu arbeiten. Ich habe letztes Jahr auch mal eine sehr, sehr komplexe Applikation mit Multi-Tenancy-Support gebaut.

Da du mit dem LAMP-Stack arbeitest (obwohl ich persönlich mit dem LEMP-Stack (Nginx statt Apache) besser umgehen kann), kann ich Laravel als Framework nur empfehlen. Dieses liefert durch die Community bereits ein Multy-Tenancy Package, dass in der Community sehr berüchtigt ist und welches Standardmäßig mit Subdomains arbeitet. Ich rate dir dringend ab, hier ohne Framework weiterzuarbeiten. Mit dem Package brauchst du dich auch um Servereinstellungen so gut wie nicht mehr kümmern.

Wenn du deine Applikation sicher und stabil, ohne viel Boilerplate-Code machen möchtest und das ohne Framework, wünsche ich dir viel Spaß bei der Implementierung von Routing, Middleware, Component-Baukasten-Systemen (wie Vue-Compontens oder Laravel Blade Templates), Multy-Tenancy-Support, Helper-Functions für weniger Boildercode, Models (OOP sollte dir ja ein Begriff sein), etc.
Das ist nur die Spitze des Mount Everest!