Webapplikation mit Python programmieren

[Electron]

Hallo.

Ich möchte eine Webapplikation programmieren, und möchte dafür Phyton nutzen. Und zwar in Kombination mit PHP.

Der Kern der Webapplikation, also Datenbankzugriff, Datenverarbeitung, Zugriff auf Sockets und Tunnel, Schnittstellenzugriff und die systemnahe Programmierung möchte ich in Phyton machen.
Das Ausgabetemplate möchte ich in PHP machen. Außerdem möchte ich eine GUI Software machen, die sowohl unter Linux als auch Windows lauffähig sein soll.

Das System wird sich über mehrere Rechner (Coresystem mit Datenbank und Datenhaltung, Webserver, Anwender-PC) erstrecken. Der Datenaustausch zwischen den Teilsystemen müsste wohl am Besten über Sockets zu realisieren sein.

Der Webserver selbst soll eine 0815 v-Server LAMP Installation sein (oder gar nur ein Mietwebspace), das ist der Grund, warum ich für die Webausgabe auf PHP setzen werde. Phyton ist bei Standard Webservern nicht ganz so verbreitet.
Das Core System mit der Datenbank und der Filebase und dem Kernprogramm ist eine individuelle Installation. Anfangs steht dieser Server zuhause am DSL, später vielleicht mal als v-Server/Dediserver bei Hetzner)
Für das Backend möchte noch eine kleine GUI Anwendung haben, die man idealerweise unter Linux und unter Windows zum Laufen bekommen kann. Natürlich könnte ich für das Backend auch ein Webinterface machen, aber mit einem lokalen GUI Programm auf dem Anwender-PC habe ich gewisse Vorteile, beispielsweise kann ich eine automatische Datensynchronisierung einbauen. ein DB Backup import/export ist auch einfacher da ich viele zwischenschritte automatisieren kann. (Sonst müsste ich NAVICAT kaufen, oder via Webinterface/ssh ein Shellscript anstoßen und die Datei manuell runterladen)

Hat jemand hier Erfahrungen mit sowas und kann mir ein paar Tipps geben?

[Electron]

P.S. Hört sich vielleicht etwas weit gegriffen an. Aber man sollte ja schonmal wissen wo man hin will, um die richtige Richtung einzuschlagen Am Anfang muss ich logischerweise erst mal ein paar kleinere Übungen machen.

Diese 3-geteilte Applicaton (Backend, Core, Frontend) deren Teilbereiche auf getrennten Rechnern laufen, ist das, was ich als Langzeitziel vor habe, dahin soll die Reise gehen. Das Endprodukt soll übrigens ein Webframework/CMS/Forum mit integriertem Onlineshop sein ("kommerzielle" Communitypage, Webung- und Shopfinanziert) . Klar, bis ich dort bin dauert es noch ne Weile, aber nicht schlimm, über Nacht wird man nicht zum Profi.

[Hyperion]

Also für mich hört sich diese Idee schlecht an. Ich wüßte spontan keine einfache Möglichkeit, wie Du PHP in ein WSGI basiertes Framework einbinden kannst. Du müßtest also an der Stelle, wo andere Frameworks ihre Templates rendern irgend wie den PHP-Interpreter aufrufen und ihm die Daten übergeben. Das klingt für mich schon ziemlich ineffizient, zumal Du die Daten ja auch noch entsprechend serialisieren musst, da Du nicht einfach Python-Objekte an einen Subprozess durchreichen kannst. Zudem muss dann bei jedem Request ein neuer PHP-Prozess initiiert werden.

Da stellt sich doch die Frage: Wieso willst Du keine Template-Engine für Python nutzen? Zumal viele Frameworks ihre eigene Template-Engine mitbringen und ihre internen Strukturen dafür ausgelegt sind. Was bietet Dir PHP hier mehr als diese Templates?

Ich habe so den leisen Verdacht, dass Du noch keine wirkliche Ahnung davon hast, wie Webframeworks unter Python funktionieren und was sie alles bieten! Django bspw. bietet Dir bereits on the fly ein Admin-Interface. Dieses kann Deine Admin-GUI, die Du separat erstellen willst, evtl. ersetzen.

Netzwerkkommunikation auf Socket-Ebene ist auch so ein Thema. Ja nach Anforderung kann man da auch höhere Ebenen nutzen, wie etwa XMLRPC oder JSONRPC.

Bei GUIs würde ich Dir zu PyQt (bzw. PySide) raten. Andere empfehlen PyGtk oder gar das Binding für wxWidgets. Das bei Python mitgelieferte Tk ist bei komplexeren Applikationen nicht unbedingt zu empfehlen.

Mein Tipp wäre für Dich, dass Du Die mal Django genau anguckst und damit experimentierst - bevor Du irgend etwas anderes aus Deinem Projekt angehst. Zudem gibt es bereits viele Projekte, die auf Django basieren, u.a. auch Webshops. Evtl. evaluierst Du diese mal, um zu prüfen, ob diese für Dich ausreichen bzw. diese als Basis für Dein Projekt dienen können.

[Electron]

Hallo.

Django habe ich schon gehört, aber nich nicht getestet.
Ein fertiges Sytem könnte ich auf dem "Coreserver" schon einsetzen. Könnte den Output davon auf dem Frontserver parsen, und dort in mein eigenes PHP Template einsetzen, so dass der User es nicht sieht.


Ich hatte mir das halt so vorgestellt:

Auf dem Standard Webserver läuft das Frontend PHP Basierend.
Content-Daten mit hohem Trafficaufkommen liegen auch direkt auf diesem Webserver oder werden dort gecached.

Ansonsten werden die Anfragen über einen Socket an den Coreserver durchgereicht.
Der Core Server liefert die Daten zurück. Diese werden auf dem Webserver mittels PHP in das eigens programmierte Template eingesetzt und ausgegeben.

Teilprojekte, die ich nicht selbst programmiere, wie z.B. das Forum:
Das Forum wird auf phpbb basieren. Die Datenbank wird allerdings nicht direkt auf dem Webserver liegen.
Sie liegt auf dem von mr verwalteten Server, damit ich mit selbst programmierten Skripen lokal zugreifen kann.


Momentan nutze ich ein solches System übrigens auch schon. Momentan dient es allerdings dazu, den Speicherplatz eines 99 Cent Webspace durch den Homeserver zu erweitern, ohne dass der User was davon mitbekommt. Ich habe ein System programmiert, welches Anfragen an den Homeserver durchreicht, das was zurück kommt, parst und neu ausgibt. Es unterstützt sogar Caching.
Momentan ist es auf beiden Systemen php basierend.

Ich will von PHP abkommen und auf Phyton umsteigen. Nur auf dem Ausgabe-Webserver will ich bei PHP bleiben, weil es weiter verbreitet ist.
Auf meinem selbst betriebenen Server bin ich flexibler, ich möchte ihn aber nicht direkt im Internet ersichtlich haben. Direkt im Userkontakt will ich aus Sicherheitsgründen einen Webserver eines Hosters. Dann treffen die Scriptkiddis, DOS Attacken, Brute-Force Attacken, Spambots usw erst mal nicht den von mir verwalteten Server, sondern einen Server eines professionellen Hosters der von Systemsicherheit garantiert mehr Ahnung und Möglichkeiten hat als ich.
Außerdem sollen wichtige Daten und das Accounting nicht auf dem Webserver liegen oder zumindest permanent an anderer Stelle zusätzlich gespeichert werden.

Backend:
Statt Navicat zu kaufen, oder manuell Backups zu fertigen, will ich mir eine eigene DB Backend Applikation programmieren, die auch Synchronisierung und Live-Backup kann und alles permanent bei mir zuhause mitsichert. Sie soll auch direkte Eingriffe in die DB erlauben (Datensätze lesen/editieren usw) so wie Navicat.
An Navicat werde ich nicht rankommen, muss ich auch nicht. Eine kleine GUI Applikation, genau auf mein PRojekt zugeschnitten reicht auch. Ich brauche dafür ja keine so universell einsetzbare Lösung wie Navicat.

[Hyperion]

Ich will von PHP abkommen und auf Phyton umsteigen. Nur auf dem Ausgabe-Webserver will ich bei PHP bleiben, weil es weiter verbreitet ist.

Du benötigst doch einige Server(-programme) für Deinen Plan. Insofern würde ich da die Verbreitung von PHP nicht so in den Fokus setzen. Wer ein solches Projekt stemmen will, der kommt eben um einen Server nicht herum. Und auf dem kann ich ja nutzen, was ich will.

Ich weiß jetzt nicht, was Du Dir so vorstellst, aber Du baust Dir da imho viele Redundanzen rein. Zudem klingt PHP-Frontend so toll; in Wirklichkeit ist es doch umständlich dort, alles per Hand zu machen. Auch in PHP gibt es Frameworks, die Dir DB-Zugriffe kapseln usw. Wenn Du das aber nutzt, sehe ich keinen Bedarf mehr für Python

Ich denke Du solltest mal eine klare Architektur aufstellen, wie Du Dir was vorstellst. Also welche Komponenten gibt es, was tun die, welche Daten sollen die woran liefern usw. Ich sehe im Moment da keine Harmonie zwischen Python und PHP. Mir ist da noch nicht klar, was Python in Deinem Kontext überhaupt machen kann und soll.

[Electron]

Hi.

Sicher habe ich Redundanzen drin und unnötige Zwischenschritte.

Ein PHP Output erneut zu parsen, nochmal durch PHP durchzujagen und auszugeben ist eigentlich unnötig.
Für das "Verbergen" des eigenen Servers ist es mir das aber wert.

Natürlich, ich weiß es gibt Reverse Proxys. Aber damit bin ich schon wieder von der 0815 Webspace Schiene weg.

Mein Frontend System soll eben auf einem 0815 Webspace laufen, während ich meine individualität auf einem verborgenen Server im Hintergrund realisiere.

Das dient der Erhöhung der Sicherheit. Security through obscurity für den von mir verwalteten Server.
Damit die Bots den nicht so schnell finden, läuft alles auf ungewöhnlichen Ports, also sowas wie z.B. 18780.
Zusätzlich habe ich eine Hardwarefirewall dazwischen.

Ich muss halt alles so programmieren, dass man nur den 0815 Webserver beim Hoster sieht.
Die Daten müssen außerdem permanent abseits des Webservers gespeichert werden dass ich im Fall der Fälle keinen großen Datenverlust habe.

[Electron]

Auf meinem Server möchte ich halt auf Phyton umsteigen und in Phyton meine Scripte machen.
Die Ausgabe auf dem Frontend Server muss in PHP realisiert werden, weil Phyton auf 0815 Webservern selten vorhanden ist.
Ein Perl CGI für die Ausgabe ginge grade noch so, das ist noch einigermaßen oft verfügbar.

Am Liebsten würde ich zwischen beiden per Socket direkt übertragen. HTTP (So wie jetzt auch) ginge natürlich auch, und dann halt z.B. den Django Output parsen und neu ausgeben.

[snafu]

Es heißt Paitn und nicht Füton.
Füton hat sowas von 1960er-Zukunftssprache... ^^

[BlackJack]

@Electron: Also HTML in PHP zu parsen um das dann verändert wieder auszugeben ist IMHO ziemlicher Unsinn. Wenn Du Templating in PHP machst, dann solltest Du es nicht vorher schon in Django oder irgend einem anderen Webrahmenwerk tun.

Die Frage ist, ob Du in dem beschriebenen Szenario überhaupt eine Webanwendung in Python programmieren möchtest, oder nicht lieber einen Service, den man zum Beispiel mit JSON-RPC oder XML-RPC ansprechen kann. Darauf kann man dann sprachunabhängig zugreifen -- zum Beispiel auch von PHP aus. Und auch von welcher Sprache auch immer Du verwendest um eine "native" GUI auf den Service aufzusetzen.

Wenn man das Routing und das Templating von Django dann nicht mehr benötigt, kann man Django im Grunde bei dieser Aufgabe vergessen. ORM gibt es mit SQLAlchemy auch ausserhalb von Django ein ganz gutes.

[deets]

@Electron

Als jemand, der tagtaeglich unter den Folgen von nahezug exakt diesem Systemdesign leidet kann ich dir nur mit allem Nachdruck raten: Lass. Es. Sein.

Mein Szenario bestand aus Frontend/Backend/Datenbank. Im Gegensatz zu dir war "wenigstens" das Frontend ebenfalls in Python, wenn auch selbstgebasteltes Framework, welches Vergleichen mit heutigen nicht standhaelt.

Die Verbindung zwischen Front & Backend war XMLRPC (das ja auch schon hier vorgeschlagen wurde).

Ein paar Erfahrungen daraus:

- massive Verschwendung von Zeit & Traffic in der Frontend/Backend-Kommunikation. Teilweise war das System zu 60% mit XML-generieren & parsen beschaeftigt.
- duplizierung von Code. Was dich noch heftiger treffen wird. Da wir im Zeitalter von OO leben, kommen Daten ueblicherweise mit Verhalten daher. Da du aber ueber eine IPC *immer* nur Daten bekommst (ausser du verwendest sowas wie CORBA/Pyro und verlierst die Leistung durch den permanenten Kontextswitch & Netzwerkverkehr), wirst du notgedrungenerweise Code schreiben, der die Daten wieder in eine OO-Form bringt. Mit heftigen Reibungsverlusten & Fehlerpotential. Und das ist bei dir noch potentiert, weil du auf PHP UND Python setzt, statt nur eine Sprache zu haben.
- Komplexitaet in der Systemarchitektur die den Betrieb instabiler macht. Mehrerer Server, deren respektive Erreichbarkeit notwendig ist - und natuerlich entsprechend kritisch.
- Ausrollen neuer Versionen des Codes wird komplexer.
- die gesamte Entwicklung leidet, weil man - insbesondere durch den sinnlosen Sprachspagat - mehrere Systeme jonglieren muss, um Code zu schreiben.

Generell gilt: mehrere Sprachen & IPC holt man sich nur in's Boot, wenn man sich davon einen entscheidenden Gewinn verspricht. Nichts von dem, was du anfuehrst hat den in meinen Augen.

Alle Sicherheitsueberlegungen sind obsolet, wenn das Frontend vollen admininstrativen Zugriff auf das Backend hat - so war das bei uns. Klar, man kam nicht direkt an die DB. Aber warum sollte man das wollen, wenn man ueber XMLRPC alle Funktionen hat, um sich die Daten mundgerecht zurechtzulegen, bzw. zu manipulieren?

Wenn das Frontend diese Zugriffe nicht erlaubt, dann muessen die aber ja von woanders kommen - also direkt auf deinen "Geheimserver". Womit der dann wieder exponiert ist.

Und zu security by obscurity sage ich mal nix....

Lediglich dein Wunsch, parallel noch eine GUI-Anwendung zu entwickeln sollte von vorneherein in das Design eingehen. Mein Ansatz waere da, eine saubere Mittelschicht an Business-Logik einzuziehen, sozusagen eine Bibliothek. Sowohl Web als auch GUI bedienen sich der, um konsistent mit der DB zu interagieren.

In erster Naeherung waere schon ein ORM so eine Loesung, allerdings abstrahiert das nicht ausreichend.

Last but not least halte ich deine Fixierung auf billig-hoster fuer ueberzogen - was du da sparst, holst du ueber Traffic wieder rein.

Wir haben inzwischen uebrigens die alte Architektur ueber Bord geworfen. TurboGears2 als Webframework, Elixir/SA als ORM - und eine *meeeeenge* Aufraeumarbeiten, um die im Code noch teilweise vorhandene alte Architektur auszumerzen. Unter viel Schmerzen. Was sich reimt, aber nicht gut ist.

[Electron]

Ja, da hast du natürlich recht. Das System ist so furchbar ineffizient und kompliziert.

Die Daten, die jetzt auf dem Homeserver liegen, könnte man natürlich auf den Webspace verfrachten.
Aber das Accounting auf dem Webspace zu machen und dort die "Kundendaten" abzulegen, ist schon ziemlich riskant.

Da müsste man sich etwas überlegen.
Man müsste mindestens das Backup auf einem externen System machen, mit sehr kurzen Backup Zyklen.
Abrechnungsrelevante Daten müsste man, aus Sicht des Webservers Write only, sofort wenn diese entstehen, irgendwo hin schicken. Am Besten per eMail zu einem Mailaccount bei einem professionellen Hoster. Dann hat man zumindet die Abrechnungsdaten so, das sie bei einer Systemkompromittierung sicher sind.

Aber selbst wenn ich alles auf einem Dediserver laufen lasse (dediserver hat genug Speicherplatz, da brauche ich den Space auf dem Homeserver nicht mehr), will ich da eine gewisse Trennung realisieren und das "Verarbeitungsprogramm" vom "Interfaceprogramm/Frontend" trennen und diese dann miteinander kommunizieren lassen. Dem Frontend bräuchte ich dann weniger Rechte zu geben, z.B. keinen direkten DB Zugriff / Datenordnerzugriff. Und vor Allem keine Rechte, um Shellbefehle/Shellscripts auszuführen.
Im Kernprogramm brauche ich das, da muss ich wenn ein neuer User sich anmeldet, diverse Shellscripts starten.
Außerdem könnte man, wenn man beides trennt, auch mit einer Virtualisierung arbeiten. Den Webserver dann auf einer eigenen VM laufen lassen, und den internen Kram auf einer anderen VM, die nur über einen privaten IP Adressbereich vom Webserver aus erreichbar ist.

[Hyperion]

Dem Frontend bräuchte ich dann weniger Rechte zu geben, z.B. keinen direkten DB Zugriff / Datenordnerzugriff. Und vor Allem keine Rechte, um Shellbefehle/Shellscripts auszuführen.

Auch wenn deets da sicherlich in manchen Belangen Recht hat, wäre das evtl. sinnvoll aber zumindest machbar.

Im Kernprogramm brauche ich das, da muss ich wenn ein neuer User sich anmeldet, diverse Shellscripts starten.

Das klingt zum einen gruselig und zum anderen: Worüber meldet er sich denn an? Das Frontend bietet so etwas ja nicht nach Deiner Aussage

Vielleicht solltest Du noch mal - vor sämtlichen technischen Überlegungen - über die Use Cases Deiner Anwendung und der Entwicklung nachdenken. Was sind die Ziele? (Shop hört sich kommerziell an - wenn da Geld fließt braucht man am Server nicht sparen imho) Soll da was produktives rauskommen? Ist das nur aus Spaß an der Freude? Willst Du alles selber entwickeln oder reichen auch fertige Komponenten, die Du customized? Ist der Weg das Ziel?

Imho hängt davon durchaus ab, welchen Weg Du einschlägst.

[querdenker]

Vielleicht solltest du dein ganzes Design nochmal überdenken.

• Security by obscurity ist alles außer sicher.
• Das verteilen von Funktionen auf verschiedene Server kann man machen, wenn diese in verschiedenen Zonen einer Firewall-Umgebung stehen.
  Beachte - das sind dedizierte Verbindungen mit deutlich geringeren Latenzzeiten als eine (so vermute ich mal) ADSL-Verbindung.
  Des weiteren nimmt man eine Verteilung von Funktionen eigentlich nur vor, wenn es um Lastverteilung und/oder Ausfallsicherheit geht, sich mit Six-Sigma rumschlagen muß -
  oder halt dogmatische Ciscotology-Anhänger als Netzwerker/CSO-Schergen hat.
  Zwei oder drei virtuelle Server auf einem Rootserver bei einem Hoster, die dann untereinander kommunizieren - kann schnell sein, muss aber nicht.
• Die ganze <hier ein wenig php> mit <dort ein wenig python> und <dazu noch 'ne GUI, vielleicht in python>-Sache ist auch "grenzwertig".

Das du das Thema Sicherheit von Anfang an in dein Konzept aufnimmst ist gut - aber Sicherheit muss auch im Verhältnis zu Produktivität und Produktpflege gesehen werden.
Und das passt irgendwie garnicht zusammen. Du willst bildlich gesprochen an ein Auto Stützräder anbauen, weil das ja vielleicht während der Geradeausfahrt umfallen könnte.
Es könnte umfallen - dazu müssen aber vorher einige andere Sachen passieren, wie zum Beispiel die Ebene auf der das Auto fährt müsste sich in der Längsachse der Fahrtrichtung drehen. Dagegen helfen dann auch keine Stützräder mehr.

Mit anderen Worten - mach dir erstmal Gedanken über ein sauberes und effizientes Funktionsdesign und überlege dir anschließend wo sich eventuell Sicherheitslücken sind.
Totale Sicherheit gibt es nur, wenn du einen Rechner nicht anschaltest (und selbst dann kann noch was auf den Rechner fallen)

[deets]

@Electron

Du hast da ein paar komische Vorstellungen bezueglich Datenintegritaet und Sicherheit. Email zB ist kein Medium, mit dem man irgendwas in diesem Zusammenhang erreichen kann. Es gibt Mittel wie Datenbankreplikation, Event-Queues und aehnliches, um "Backups" zeitnah zu erstellen. Und natuerlich "normale" Backups, obendrauf.

Dein Sicherheitskonzept steht und faellt damit, was dein Frontend kann. Wenn es nicht in der Lage ist, bestimmte Daten oder Vorgaenge anzuzeigen und auszuloesen, hast du natuerlich was gewonnen mit deinem Design.

Doch in dem Moment, wo sich der Sachbearbeiter einloggen kann und irgendwelche Vorgaenge detailliert betrachten und veraendern, ist es hinfaellig. Denn wie schon erwaehnt- wozu braucht's Datenbankzugriff, wenn du eine saubere API anbietest, mit der man einfach bekommt, was man will? ZB einen Einkaufskorb zum 0-Tarif abzurechnen?

Ich glaube, dass dein Projekt ambitioniert genug ist, um alleine mit einem Webframework ala Django oder TurboGears schon ausreichend Arbeit zu generieren. Die Anbindung von phpBB koennte eventuell mittels Deliverance + einem Authentifizierungs-Plugin passieren. Letzteres machen wir - das phpBB-Forum authentifiziert ueber eine XMLRPC-Anbindung an unser Python-System. Das ist isoliert & recht gut wartbar (bzw. wartungsfrei, weil sich nix aendert). Eine Webseiten-Integration haben wir nicht, aber wie gesagt, mit Deliverance waere das Problemlos moeglich.

[Electron]

Es ist halt schwer, ein relativ sicheres System hinzubekommen, welches die Daten so "wegschreibt" dass sie nicht manipulierbar sind.
Alleine schon das Aufsetzen und der Betrieb eines hinreichend sicheren Webserver ist nicht ganz ohne.
Und dann kommen noch die Gefahren durch Sichereheitslöcher in der Webanwendung selbst dazu.

Eigentlich würde es darauf hinauslaufen, einen managed Server zu mieten. Nur dieser bietet genug Speicherplatz mit der Sicherheit eines professionell betriebenen Webspace. Damit ich mir da nicht durch eine fehlerhafte Webapplication Sicherheitslöcher reinreiße, müsste ich ein fertiges System nutzen und mich auf das Templatedesign beschränken.
Damit wird es mir aber nicht möglich sein, das so nachzubauen wie ich es eigentlich will.

Falls es wen interessiert: Ich möchte längerfristig die Seite "www.mikrocontroller.net" + "electronicwerkstatt.de" + "Frag-Vati.de" nachbauen (Von allen 3 ein Teil des Konzeptes übernehmen). Mit einem anderen Topic und etwas kommerzieller ausgerichtet. (Mehr Werbung, größerer Shop, Premium-Accounts, Punktesystem+Gewinnspiele)

[deets]

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.

[Electron]

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.

[DasIch]

Die Beste Maßnahe zur Erhöhung der Sicherheit dürfte wohl das sehr genaue Prüfen und Parsen aller Usereingaben sein.

Das ist eine Grundvorraussetzung.

[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.

[Leonidas]

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.

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.

Wo kommen die meißten Angriffe her? Wahrscheinlich über das Webinterface/Frontend.

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.