Die Daten, die du wegschreibst, sind per Definition manipulierbar. Denn du willst ja ein lebendes System, und keinen statischen HTML-Dump. Ich kenne die angesprochenen Seiten ein bisschen - da ist ja viel User-Interaktion hinter.
Es sieht mir so aus, als ob du aus Unsicherheit ueber die Sicherheit ein Design erdenkst, von dem du *glaubst*, dass es irgendwie magisch deine Probleme loest - weil du den front-facing Teil einem "Profi" ueberlaesst. Das ist ja per se erstmal loeblich, so zu denken, statt breitbrustig anzunehmen, dass das schon alles werden wird.
Aber ganz ehrlich - wenn du was schaffen willst, das etwas besonderes ist, dann wirst du dich damit auseinandersetzen muessen, eine Webanwendung zu schreiben, die so, wie sie ist, der Oeffentlichkeit direkt zur Verfuegung steht. Es gibt keine magische Loesung.
Und auf der anderen Seite - ohne Sicherheit in Webanwendungen klein reden zu wollen - denke ich ueberschaetzt du das, was von einem Hoster so gemacht wird. Der installiert auch nur jeweils aktuelle Versionen von zB Apache, und anderen Pakteten, macht nur benoetigte Ports auf, usw. Und wenn es wirklich ernst wird mit deinem System (also, es live geht und Leute sich darauf tummeln), dann kannst du dir da zur Not auch Hilfe holen von Leuten, die bezueglich der Administration mehr Erfahrung haben. Und zB SE-Linux aufsetzen, oder so.
Die Dinge, die nur du selbst machen kannst, nein, *musst*, sind aber viel wichtiger: eine Webanwendung, die mit den richtigen Mechanismen zur Authorisierung ausgestattet ist (nicht wie das Diaspora-Debakel...). Darum kommst du nicht herum.
Und da hat ein Framework wie TurboGears oder Django (letzteres kenne ich da nicht so) Vorteile. In TG2 kannst du zB Controller und Actions bezueglich bestimmter User-Eigenschaften wie Gruppenzugehoerigkeit usw. schuetzen.
Webapplikation mit Python programmieren
Diese Frameworks sind nicht schlecht, grade mal bissl geschaut. Man kann ja gut um dieses Gerüst seinen eigenen Kram drumherum bauen.
Ich habe übrigens nicht den Anpruch, dass das übermorgen fertig sein soll.
Bis ich da hin komme, fehlt noch sehr, sehr viel.
Es ist eben nur das "Endziel".
Wenn ich in Urlaub fahre, weiß ich ja auch, wo es hin gehen soll.
Ohne en fernes Ziel vor Augen habe ich das Problem, dass ich mich nicht motivieren kann. Also einfach so aus "Jux und Dollerei" bissl vor mich hin coden ist nicht so meins.
Selbst wenn ich jetzt anfange, mein eigenes Webminiframework zu basteln, und später doch auf was fertiges gehe, ist es nicht verloren. Auch wenn man was fertiges nimmt, sollte man sich ja etwas auskennen.
Die Beste Maßnahe zur Erhöhung der Sicherheit dürfte wohl das sehr genaue Prüfen und Parsen aller Usereingaben sein.
Wo kommen die meißten Angriffe her? Wahrscheinlich über das Webinterface/Frontend.
Ich habe übrigens nicht den Anpruch, dass das übermorgen fertig sein soll.
Bis ich da hin komme, fehlt noch sehr, sehr viel.
Es ist eben nur das "Endziel".
Wenn ich in Urlaub fahre, weiß ich ja auch, wo es hin gehen soll.
Ohne en fernes Ziel vor Augen habe ich das Problem, dass ich mich nicht motivieren kann. Also einfach so aus "Jux und Dollerei" bissl vor mich hin coden ist nicht so meins.
Selbst wenn ich jetzt anfange, mein eigenes Webminiframework zu basteln, und später doch auf was fertiges gehe, ist es nicht verloren. Auch wenn man was fertiges nimmt, sollte man sich ja etwas auskennen.
Die Beste Maßnahe zur Erhöhung der Sicherheit dürfte wohl das sehr genaue Prüfen und Parsen aller Usereingaben sein.
Wo kommen die meißten Angriffe her? Wahrscheinlich über das Webinterface/Frontend.
-
deets
Naja, klar sind Usereingaben das A&O. Schliesslich sind sie das, was deine Anwendung ausmacht. Ausserdem gibt's natuerlich auch noch sowas wie Pufferueberlauefe usw.
Deine Ansicht, dass du nichts verlierst, weil du jetzt alles selbstmachst + spaeter dann auf ein bestehendes Framework wechselst teile ich nicht. Der Punkt ist ganz einfach der - Sinn & Zweck der Frameworks ist dir Arbeit ueberall da abzunehmen, wo schon bekannt ist, dass sie eh jeder machen muss. Eine Template-Sprache auswaehlen, Formulare darstellen & Eingaben validieren, Encodings, Content-typen, File-Uploads, ORM - alles das und noch mehr.
Natuerlich kann man das auch selbst stricken. Aber wenn du das tust, verschwendest du viel Zeit auf Dinge, die andere schon gemacht haben fuer dich. Ausserdem sind deine Entwuerfe aller Vorraussicht nach nicht wirklich so gut, denn die Frameworks sind ja basierend auf der Erfahrung vieler, was so notwendig ist und wie und was nicht. Du faengst an was zu machen, und ploetzlich stellst du fest "ups, diese Sache jetzt geht nicht so einfach, da muss ich ja alles umschmeissen." Und gerade bei selbstgestricktem ist die Gefahr hoch, dass dein Code danach zu spezifisch ist.
Auch hier habe ich wieder die direkte Erfahrung. Unsere "Legacy-App" ist vor 6-7 Jahren entstanden. Da war die Webframework-Welt noch ein bisschen ueberschaubarer - aber gegeben hat's schon was. Trotzdem hat man alles selbst gemacht. Unter den Folgen leiden wir noch heute. Es ist sehr, sehr viel Arbeit, Funktionalitaeten umzuziehen nach TurboGears. Obwohl die ja theoretisch dasselbe machen. Praktisch machen sie es aber anders, und alles, was so drumrum an Hilfsfunktionalitaeten und so entsteht, ist alles auf ein FW zugeschnitten.
Und *gerade* unter dem Sicherheitsaspekt ist der Rueckgriff auf etwas bestehendes IMHO zu empfehlen - denn da gibt es viele Augen mehr, die Probleme erkennen.
Deine Ansicht, dass du nichts verlierst, weil du jetzt alles selbstmachst + spaeter dann auf ein bestehendes Framework wechselst teile ich nicht. Der Punkt ist ganz einfach der - Sinn & Zweck der Frameworks ist dir Arbeit ueberall da abzunehmen, wo schon bekannt ist, dass sie eh jeder machen muss. Eine Template-Sprache auswaehlen, Formulare darstellen & Eingaben validieren, Encodings, Content-typen, File-Uploads, ORM - alles das und noch mehr.
Natuerlich kann man das auch selbst stricken. Aber wenn du das tust, verschwendest du viel Zeit auf Dinge, die andere schon gemacht haben fuer dich. Ausserdem sind deine Entwuerfe aller Vorraussicht nach nicht wirklich so gut, denn die Frameworks sind ja basierend auf der Erfahrung vieler, was so notwendig ist und wie und was nicht. Du faengst an was zu machen, und ploetzlich stellst du fest "ups, diese Sache jetzt geht nicht so einfach, da muss ich ja alles umschmeissen." Und gerade bei selbstgestricktem ist die Gefahr hoch, dass dein Code danach zu spezifisch ist.
Auch hier habe ich wieder die direkte Erfahrung. Unsere "Legacy-App" ist vor 6-7 Jahren entstanden. Da war die Webframework-Welt noch ein bisschen ueberschaubarer - aber gegeben hat's schon was. Trotzdem hat man alles selbst gemacht. Unter den Folgen leiden wir noch heute. Es ist sehr, sehr viel Arbeit, Funktionalitaeten umzuziehen nach TurboGears. Obwohl die ja theoretisch dasselbe machen. Praktisch machen sie es aber anders, und alles, was so drumrum an Hilfsfunktionalitaeten und so entsteht, ist alles auf ein FW zugeschnitten.
Und *gerade* unter dem Sicherheitsaspekt ist der Rueckgriff auf etwas bestehendes IMHO zu empfehlen - denn da gibt es viele Augen mehr, die Probleme erkennen.
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Naja, ich finde das macht weniger Sinn als andersrum. Wenn man ein fertiges Framework nimmt, nutzt und kennt dann weiß man was dessen Vorteile und Nachteile sind. Man kann dann, mit dem Wissen was man erreichen kann und wie es "richtig" geht, sich was eigenes basteln, wenn man nicht mit dem fertigen zufrieden ist. Sich aber von Grund auf ein brauchbares Framework aufzubauen ist wesentlich schwerer, weil man nicht weiß wie man Sachen besser machen kann.Electron hat geschrieben:Selbst wenn ich jetzt anfange, mein eigenes Webminiframework zu basteln, und später doch auf was fertiges gehe, ist es nicht verloren. Auch wenn man was fertiges nimmt, sollte man sich ja etwas auskennen.
Ja. Und das kommt meist, weil die Entwickler keine Ahnung haben und ignorant sind. Wenn man ein sicheres System implementieren will sollte man schauen, was für häufige Angriffsszenarien existieren (Stichwort XSS, CSRF, SQL-Injection, Spamversand) und wie man diese angeht. Wenn man etwas unübliches machen will, wie etwa deine Multi-Frontend-Sache, dann ist es oftmals sinnvoll Leute mit Ahnung zu fragen, ob das 'ne gute Idee ist was man da bastelt.Electron hat geschrieben:Wo kommen die meißten Angriffe her? Wahrscheinlich über das Webinterface/Frontend.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Da möchte ich selbst nochmal einhaken: Gerade da haben bestehende Webframeworks schon einiges an Lösungen. Django etwa nutzt ein ORM, so dass typische SQL-Injections unmöglich werden, bietet in Templates Autoescaping, wodurch XSS-Lücken verhindert werden und bietet eine CSRF-Middleware, die sich darum kümmert CSRF-Attacken zu verhindern. Out-of-the-Box. Man muss nichts selbst implementieren sondern ist einfach sicher.deets hat geschrieben:Und *gerade* unter dem Sicherheitsaspekt ist der Rueckgriff auf etwas bestehendes IMHO zu empfehlen - denn da gibt es viele Augen mehr, die Probleme erkennen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Hallo.
Da habt ihr natürlich recht. Ich bin wie gesagt noch ganz am Anfang, ist momentan alles noch die Phase dass ich mir überlege wie ich alles umsetzen könnte. Ich denke ich werde ein paar "Trockenübungen" machen, d.h. irgendwelche kleinen Sachen machen um die Grundlagen zu lernen und dann recht bald auf ein fertiges System umsteigen, und mich dann darauf konzentieren, das zu modden, d.H. ein eigenes Template und Addons zu machen. So dass es nachher so aussieht wie ich mir das vorstelle.
Welche Systeme ich verwende, weiß ich noch nicht. Es kommt vor Allem drauf an, dass keine Lizenzkosten anfallen, man den Kram auch kommerziell legal kostenfrei verwenden kann. An zweiter Stelle steht die Funktion.
Wenn ich php nutzen würde, würde ich auf folgendes setzen: Wordpress, phpBB, Mediawiki, osCommerce. Dazu müsste ich dann Templates machen, um alle Systeme optisch aufeinander anzupassen. Außerdem müsste ich "Bridge Scripts" machen, um den Datenaustausch zwischen den versch. System hinzubekommen. Funktionen wie mein Punktesystem müsste ich Addon mit Anbindung an die anderen Systeme realisieren. Ein Photoalbum+Filemanager auf PHP Basis habe ich selber programmiert, ansonsten hätte sich da sicherlich auch noch eine OpenSource Lösung gefunden.
Um im Server-Dateisystem die Userspaces (Quasi ein Hosting-Account für jeden User, Für Bilder, Dateien und eine HTML-User-Seite) anzulegen, brauche ich auch noch Shellscripts, die im Anmeldevorgang irgendwann angestoßen werden.
Die abrechnungsrelevanten Daten (Sie sind nicht dazu gedacht, Geld zu kassieren, sondern es läuft über die Punkte als Belohnung für Aktivität, Shopeinkäufe, anklicken von Werbung) müssen mit einer zuverlässigen Backup Lösung permanent auf einen externen Backup Space in Kopie abgespeichert werden.
Für Navicat, als DB Backend+Backupsystem muss ich auch noch einen "Ersatz" finden.
Mit pyton kenne ich mich noch nicht so gut aus, da weiß ich nicht, welche Sachen ich als Grundlage nutzen könnte. Ich installiere mir grade einen neuen Testwebserver, um mal verschiedene pyton OpenSource Sachen zu testen. Die Sachen müssen nicht nur privat kostenfrei sein, sondern auch im "kleinkommerziellen" Einsatz. Alles was Lizenzkosten verursacht, ist von vorne herein schonmal raus.
Meine Communitywebseite soll mich schließlich kein Geld kosten. Sie soll mindestens Kostenneutral laufen, besser noch einen kleinen Gewinn abwerfen.
Da habt ihr natürlich recht. Ich bin wie gesagt noch ganz am Anfang, ist momentan alles noch die Phase dass ich mir überlege wie ich alles umsetzen könnte. Ich denke ich werde ein paar "Trockenübungen" machen, d.h. irgendwelche kleinen Sachen machen um die Grundlagen zu lernen und dann recht bald auf ein fertiges System umsteigen, und mich dann darauf konzentieren, das zu modden, d.H. ein eigenes Template und Addons zu machen. So dass es nachher so aussieht wie ich mir das vorstelle.
Welche Systeme ich verwende, weiß ich noch nicht. Es kommt vor Allem drauf an, dass keine Lizenzkosten anfallen, man den Kram auch kommerziell legal kostenfrei verwenden kann. An zweiter Stelle steht die Funktion.
Wenn ich php nutzen würde, würde ich auf folgendes setzen: Wordpress, phpBB, Mediawiki, osCommerce. Dazu müsste ich dann Templates machen, um alle Systeme optisch aufeinander anzupassen. Außerdem müsste ich "Bridge Scripts" machen, um den Datenaustausch zwischen den versch. System hinzubekommen. Funktionen wie mein Punktesystem müsste ich Addon mit Anbindung an die anderen Systeme realisieren. Ein Photoalbum+Filemanager auf PHP Basis habe ich selber programmiert, ansonsten hätte sich da sicherlich auch noch eine OpenSource Lösung gefunden.
Um im Server-Dateisystem die Userspaces (Quasi ein Hosting-Account für jeden User, Für Bilder, Dateien und eine HTML-User-Seite) anzulegen, brauche ich auch noch Shellscripts, die im Anmeldevorgang irgendwann angestoßen werden.
Die abrechnungsrelevanten Daten (Sie sind nicht dazu gedacht, Geld zu kassieren, sondern es läuft über die Punkte als Belohnung für Aktivität, Shopeinkäufe, anklicken von Werbung) müssen mit einer zuverlässigen Backup Lösung permanent auf einen externen Backup Space in Kopie abgespeichert werden.
Für Navicat, als DB Backend+Backupsystem muss ich auch noch einen "Ersatz" finden.
Mit pyton kenne ich mich noch nicht so gut aus, da weiß ich nicht, welche Sachen ich als Grundlage nutzen könnte. Ich installiere mir grade einen neuen Testwebserver, um mal verschiedene pyton OpenSource Sachen zu testen. Die Sachen müssen nicht nur privat kostenfrei sein, sondern auch im "kleinkommerziellen" Einsatz. Alles was Lizenzkosten verursacht, ist von vorne herein schonmal raus.
Meine Communitywebseite soll mich schließlich kein Geld kosten. Sie soll mindestens Kostenneutral laufen, besser noch einen kleinen Gewinn abwerfen.
-
deets
Alle dir vorgeschlagenen Frameworks sind open source. Das ist also nicht das Problem.
Die "Trockenuebungen" klingen wieder nach selbst-machen. Das ist nicht sinnvoll. Generelles Wissen ueber HTTP ist natuerlich immer gut, aber in dem Mass, wie du das brauchst, solltest du das schon mit PHP gelernt haben.
Mir macht allerdings noch deine Liste von Basistechnologien "Sorge". Wenn du da schon hast, was du dir vorstellst, dann wuerde ich das - ganz pragmatisch - auch einfach *alles* mit PHP machen. Denn mir waere nicht bekannt, das es in der Python-Welt vergleichbares gibt. Hinweis darauf ist zB dieses Forum hier - ist ja auch phpBB
Das ist sicher kein prinzipieller technischer Grund, aber aus welchen Gruenden auch immer gibt es solche Systeme nicht off-the-open-source-shelf. Ich wuerde mir das also sehr gut ueberlegen, ob es wirklich Python sein muss (so sehr ich es persoenlich PHP vorziehe).
Last but not least hoert sich dieses Hosting-Accont-gedoens nach ziemlichem Unfug an. Meine Anwendung verwalten ~1.000.000 User. Mein SysAdmin wuerde mir den Hintern versohlen, wenn auch nur fuer *einen* davon ein Shell-Skript laufen wuerde, geschweige denn User-Accounts angelegt werden!
Ich kenne mich mit MySQL nicht aus, ich bevorzuge Postgres. Aber ich denke beide Systeme sind leistungsfaehig genug, um saemtliche deiner Userdaten inklusive Binaerdaten als BLOBs zu speichern. Wenn es da unerwartet Probleme gibt, ist es ein leichtes, das ueber einen externen Storage (also HD, memcached usw, inklusive Dinge wie S3) auszulagern. Dazu muessen die auch nicht irgendwie mit verschiedenen User-Rechten abgelegt werden, die Authorization ist immer die Aufgabe deiner Webanwendung.
Last but not least ist ein Testwebserver ebenfalls der falsche Weg. Sowas brauchst du schlicht nicht. Die gesammelte Python-Framework-Mannschaft kommt mit jeweils eigenen Servern daher, die zum entwickeln voellig ausreichen.
Wenn du dann mal soweit bist, das ganze auf einen Server zu bringen, kannst du dir da immer noch Gedanken machen. Ich tendiere momentan zu nginx + supervisord fuer die Paster-Server-Prozesse, aber da gibt es eine Vielzahl von Optionen - die alle im Moment voellig irrelevant sind
Die "Trockenuebungen" klingen wieder nach selbst-machen. Das ist nicht sinnvoll. Generelles Wissen ueber HTTP ist natuerlich immer gut, aber in dem Mass, wie du das brauchst, solltest du das schon mit PHP gelernt haben.
Mir macht allerdings noch deine Liste von Basistechnologien "Sorge". Wenn du da schon hast, was du dir vorstellst, dann wuerde ich das - ganz pragmatisch - auch einfach *alles* mit PHP machen. Denn mir waere nicht bekannt, das es in der Python-Welt vergleichbares gibt. Hinweis darauf ist zB dieses Forum hier - ist ja auch phpBB
Das ist sicher kein prinzipieller technischer Grund, aber aus welchen Gruenden auch immer gibt es solche Systeme nicht off-the-open-source-shelf. Ich wuerde mir das also sehr gut ueberlegen, ob es wirklich Python sein muss (so sehr ich es persoenlich PHP vorziehe).Last but not least hoert sich dieses Hosting-Accont-gedoens nach ziemlichem Unfug an. Meine Anwendung verwalten ~1.000.000 User. Mein SysAdmin wuerde mir den Hintern versohlen, wenn auch nur fuer *einen* davon ein Shell-Skript laufen wuerde, geschweige denn User-Accounts angelegt werden!
Ich kenne mich mit MySQL nicht aus, ich bevorzuge Postgres. Aber ich denke beide Systeme sind leistungsfaehig genug, um saemtliche deiner Userdaten inklusive Binaerdaten als BLOBs zu speichern. Wenn es da unerwartet Probleme gibt, ist es ein leichtes, das ueber einen externen Storage (also HD, memcached usw, inklusive Dinge wie S3) auszulagern. Dazu muessen die auch nicht irgendwie mit verschiedenen User-Rechten abgelegt werden, die Authorization ist immer die Aufgabe deiner Webanwendung.
Last but not least ist ein Testwebserver ebenfalls der falsche Weg. Sowas brauchst du schlicht nicht. Die gesammelte Python-Framework-Mannschaft kommt mit jeweils eigenen Servern daher, die zum entwickeln voellig ausreichen.
Wenn du dann mal soweit bist, das ganze auf einen Server zu bringen, kannst du dir da immer noch Gedanken machen. Ich tendiere momentan zu nginx + supervisord fuer die Paster-Server-Prozesse, aber da gibt es eine Vielzahl von Optionen - die alle im Moment voellig irrelevant sind
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Siehst du, da hättest du mit dem von deets angesprochenen Deliverance die Möglichkeit alle diese Systeme über das gleiche System zu Themen, statt für jedes sich in die spezifischen Theming-Lösungen einarbeiten zu müssen.Electron hat geschrieben:Wenn ich php nutzen würde, würde ich auf folgendes setzen: Wordpress, phpBB, Mediawiki, osCommerce. Dazu müsste ich dann Templates machen, um alle Systeme optisch aufeinander anzupassen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Also ich habe bei mir zuhause auf einem extra Rechner einen Testserver.
Natürlich könnte ich auch auf dem Live Server entwickeln.
Auf meinem PC habe ich Windows drauf. Da ginge es im Prinzip auch, abr ich bevorzuge den Linux Testserver.
Unter PHP habe ich testweise ein kleines Webseitenframework selbst gemacht. Wegen meiner Frickelei (Einen Homeserver als Speichererweiterung und Flexibilitätserweiterung für den Billig-Webspace) musste ich das auch.
Unter PHP weiß ich was ich nehmen würde, weil ich mich damit schon etwas länger befasse. Da kenne ich mich aus und weiß was es so gibt.
Im intenen Testetrieb habe ich folgendes:
Ich habe eine funktionierene Wordpress<->phpBB<->Photoalbum+Filemanager Bridge.
Ich habe ein eigenes WP und ein phpBB Template, 100% optische Übereinstimmung habe ich jedoch noch nicht. Man sieht beidem auch noch das Grundsystem deutlich an, habe die Standardtemplates modifiziert.
Der Photoalbum und Filemanager ist selbstgemacht. Sie arbeiten ohne eigene Datenbank. Sie sind Dateibasierend, und nutzen die phpBB Datenbank nur lesend.
Das Script legt unter var/www/webseite/users ein Verzeichnis an, und stellt dem User 10 MB Webspace ohne php/CGI Support zur Verfügung.
Der User erhält eine Subdomain in der Form User0815.meineseite.net
Der User kann dort eine richtige Homepage abgelegen, die auch direkt aufrufbar ist. Der Inhalt wird direkt über den Webserver ausgeliefert.
Das Photoalbum Script ließt die Bilder ebenfalls direkt vom Webspace ein, und gibt sie wieder aus. Man kann die Bilder aber auch direkt normal verlinken.
Läuft derzeit alles unter PHP. Sicher, man kann auch PHP basierend Shellscripts machen. Aber PHP ist dafür ja ursprünglich nicht gemacht.
Pyton wäre mir lieber. Damit hätte ich eine Sprache für alles.
Mit Pyton kann man ja sogar GUI Programme machen.
Einmal pyton lernen und diese Sprache zukünftig für alles nutzen. Das wäre fein.
@Leonidas: Ja das stimmt das Deliverance könnte ich recht gut verwenden.
Natürlich könnte ich auch auf dem Live Server entwickeln.
Auf meinem PC habe ich Windows drauf. Da ginge es im Prinzip auch, abr ich bevorzuge den Linux Testserver.
Unter PHP habe ich testweise ein kleines Webseitenframework selbst gemacht. Wegen meiner Frickelei (Einen Homeserver als Speichererweiterung und Flexibilitätserweiterung für den Billig-Webspace) musste ich das auch.
Unter PHP weiß ich was ich nehmen würde, weil ich mich damit schon etwas länger befasse. Da kenne ich mich aus und weiß was es so gibt.
Im intenen Testetrieb habe ich folgendes:
Ich habe eine funktionierene Wordpress<->phpBB<->Photoalbum+Filemanager Bridge.
Ich habe ein eigenes WP und ein phpBB Template, 100% optische Übereinstimmung habe ich jedoch noch nicht. Man sieht beidem auch noch das Grundsystem deutlich an, habe die Standardtemplates modifiziert.
Der Photoalbum und Filemanager ist selbstgemacht. Sie arbeiten ohne eigene Datenbank. Sie sind Dateibasierend, und nutzen die phpBB Datenbank nur lesend.
Das Script legt unter var/www/webseite/users ein Verzeichnis an, und stellt dem User 10 MB Webspace ohne php/CGI Support zur Verfügung.
Der User erhält eine Subdomain in der Form User0815.meineseite.net
Der User kann dort eine richtige Homepage abgelegen, die auch direkt aufrufbar ist. Der Inhalt wird direkt über den Webserver ausgeliefert.
Das Photoalbum Script ließt die Bilder ebenfalls direkt vom Webspace ein, und gibt sie wieder aus. Man kann die Bilder aber auch direkt normal verlinken.
Läuft derzeit alles unter PHP. Sicher, man kann auch PHP basierend Shellscripts machen. Aber PHP ist dafür ja ursprünglich nicht gemacht.
Pyton wäre mir lieber. Damit hätte ich eine Sprache für alles.
Mit Pyton kann man ja sogar GUI Programme machen.
Einmal pyton lernen und diese Sprache zukünftig für alles nutzen. Das wäre fein.
@Leonidas: Ja das stimmt das Deliverance könnte ich recht gut verwenden.
Also der Deliverance könnte vermutlich sogar eine der besten Lösungen sein.
Der kann wohl auch Serverübergreifend arbeiten.
Damit könnte das "Cloaking" und Re-Theming ziemlich gut funktionieren.
D.H. dass man auf den ersten Blick den Ursprungsserver des Output gar nicht sieht.
Außerdem ein starkes Re-Theming, so dass man auf den ersten Blick kaum noch sieht, dass es phpBB ist.
Und genau das will ich ja erreichen.
Muss das unbedingt mal testen.
Der kann wohl auch Serverübergreifend arbeiten.
Damit könnte das "Cloaking" und Re-Theming ziemlich gut funktionieren.
D.H. dass man auf den ersten Blick den Ursprungsserver des Output gar nicht sieht.
Außerdem ein starkes Re-Theming, so dass man auf den ersten Blick kaum noch sieht, dass es phpBB ist.
Und genau das will ich ja erreichen.
Muss das unbedingt mal testen.
-
deets
du bist schon wieder so fixiert auf "security by obscurity". deliverance verhaelt sich in dieser beziehung wie ein transparenter proxy. und damit sind *alle* angriffszenarien genauso gegeben. wenn eine luecke in phpbb ausgenutzt werden kann, dann nuetzt deliverance nix dagegen.
sonst wuerden doch alle leute einfach nur nen transparenten proxy fahren, und gut ist mit sicherheitsluecken...
trotzdem ist es natuerlich ein sehr interessantes + gutes stueck software, gerade fuer deinen anwendungszweck. ein single-sign-on musst du aber noch selbst irgendwie basteln.
sonst wuerden doch alle leute einfach nur nen transparenten proxy fahren, und gut ist mit sicherheitsluecken...
trotzdem ist es natuerlich ein sehr interessantes + gutes stueck software, gerade fuer deinen anwendungszweck. ein single-sign-on musst du aber noch selbst irgendwie basteln.