Ankündigung

Einklappen
Keine Ankündigung bisher.

Jemand Lust an bncms mitzuarbeiten?

Einklappen

Neue Werbung 2019

Einklappen
Dieses Thema ist geschlossen.
X
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #91
    Zitat von BlackScorp Beitrag anzeigen
    Ich weiß nicht, ich glaube das gehört zum Lernprozess dazu. Ich finde jeder PHP Entwickler sollte ein Mal in seiner Karriere eine eigene DB Klasse geschrieben haben und ein eigenes Framework/CMS Entwickelt haben. Und eine Template Engine danach kann man anschauen was andere so machen und dann versteht man erst, wie wenig man eigentlich weiß.

    Mit solchen Projekten kann man den Dunning Kruger Effekt zeimlich gut dann sehen, was meiner Meinung nach sehr förderlich ist. Du must am Anfang riskieren, denken du kannst alles, ein Mal auf die "Schnauze Fallen" und danach resetten um besser zu werden.
    Ich spreche nicht vom PHP Programmieren an sich, sondern von Software Architektur.
    Ohne das jemals gesehen zu haben, kannst du keine brauchbare Software planen.

    Wenn man mit einem Framework zu kämpfen hat, tritt der Dunning Kruger Effekt gar nicht erst ein, da man direkt mit der Arbeit besserer Programmierer konfrontiert wird.
    Und wenn man es erst mal gemeistert hat, ist es keine Selbstüberschätzung mehr, sondern wirkliches Know-How.

    Habe mir zwar dein neues Video noch nicht angesehen, aber (so vermute ich; noch nie damit beschäftigt) visuelle Programmierung rückt ja gerade auch die Architektur in den Vordergrund, während der zugrundeliegende Code nebensächlich ist.

    Kommentar


    • #92
      Zitat von sboesch Beitrag anzeigen

      Ich spreche nicht vom PHP Programmieren an sich, sondern von Software Architektur.
      Ohne das jemals gesehen zu haben, kannst du keine brauchbare Software planen.

      Wenn man mit einem Framework zu kämpfen hat, tritt der Dunning Kruger Effekt gar nicht erst ein, da man direkt mit der Arbeit besserer Programmierer konfrontiert wird.
      Und wenn man es erst mal gemeistert hat, ist es keine Selbstüberschätzung mehr, sondern wirkliches Know-How.
      Stimme ich dir völlig zu, bei mir kam auch der AHA Effekt erst nach dem ich mich durch das Kohana Framework durchgewühlt habe, wodurch dann Symfony Interessant erschien und dannach Laravel überflogen habe. Du kannst aber ohne Grundkentnisse ein Framework nicht vernüftig lesen. Also den Inhalt des Sourcecodes. Du musst ja die Probleme kennen, die ein Framework lösen möchte um dann die Architektur dahinter zu verstehen. Will sagen, eigenes Rumfrickeln hilft dir die Probleme zu verstehen und dann versteht man auch wieso ein Framework die Ordnersturkturen und Klassen hat.

      Zitat von sboesch Beitrag anzeigen

      Habe mir zwar dein neues Video noch nicht angesehen, aber (so vermute ich; noch nie damit beschäftigt) visuelle Programmierung rückt ja gerade auch die Architektur in den Vordergrund, während der zugrundeliegende Code nebensächlich ist.
      Ne da gings eher darum, dass man mit VIsual Programming auch Software Entwickeln kann als Designer, die scheinen ja mit NodeSystem sich sehr gut zu Recht zu finden, siehe Blender/Photoshop/Unity usw
      apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp | Mein Youtube PHP Kanal: https://www.youtube.com/c/VitalijMik

      Kommentar


      • #93
        Ich bin da auf BlackScorps Seite. Eine der hevorragenden Symfony-Libs zu benutzen ist einfach und klar - man verwendet ein sauberes Stück Software. Aber zeig mir mal den, der danach noch versucht, so etwas selbst zu machen. Ich weiß nicht, wie oft ich mich schon durch Framework-Code debuggt habe und da hat mir meine "Eigenes Framework"-Zeit extrem geholfen. Einfach, weil man ein besseres Gefühl dafür hat, wo was warum gemacht wird.

        Ein Automechaniker lernt seinen Beruf ja auch nicht ausschließlich dadurch, dass er Auto fährt.

        Kommentar


        • #94
          Zitat von xm22 Beitrag anzeigen
          Ein Automechaniker lernt seinen Beruf ja auch nicht ausschließlich dadurch, dass er Auto fährt.
          Aber ein Automechaniker baut in der Regel kein Auto selber, sondern zerlegt in der Regel welche, die schon fertig gebaut wurden

          Kommentar


          • #95
            Zitat von hellbringer Beitrag anzeigen

            Aber ein Automechaniker baut in der Regel kein Auto selber, sondern zerlegt in der Regel welche, die schon fertig gebaut wurden
            na, da kennst du aber wohl keinen jeder von den hat ein "Bastel" Auto was nicht mehr fürs Tüv zugelassen wird. Gut die bauen das nicht ganz komplett aber fräsen sich Teile oder holen sich welche vom schrott händler.. ach egal, hier im Forum gibt es immer einige gegen und andere für, jeder hat seine Erfahrung gemacht, viele von uns hier mussten aber damals ein eigenes Framework bauen weil es gab ja damals nichts. Außer vielleicht PHPLib (nicht wörtlich nehmen.. )

            und ich glaube dass diese Erfahrung wichitg war. Ich blicke gerne zurück auf mein Thread von 2009 wo ich ganz stolz meine Database Klasse zeige und nikosch die einfach so zerstört
            apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp | Mein Youtube PHP Kanal: https://www.youtube.com/c/VitalijMik

            Kommentar


            • #96
              Es ging bei bncms immer nur darum einen universellen Administrationsbereich erschaffen und Datenbanken in einer Art zu visualisieren, dass Sie direkt von Geschäftsleitungen und Marketingabteilungen bearbeitet werden können. Konfiguration des CRUD über einen Adminbereich, Visualisierung der Relationen. Das Stand im Vordergrund dieses Konzept ist neu, und es ging darum mit pragmatischen Mitteln einen Prototypen zu erstellen, der eingesetzt werden kann. Wäre es mit herkömmlichen Frameworks verwirklicht worden hätte man so tief in den Core Code eingreifen müssen und ihr sagt selbst dass ihr das alle selbst nicht schnallt. Sondern nur Bausteine zusammensetzt.

              Deswegen weil es auf diese Art viel aufwändiger gewesen wäre und weil zweitens auch die Performance im Vordergrund stand und drittens es nur für CRM und firmeninterne Softwarelösungen gedacht war habe ich es mit PHP und simplem Code Ansatz verwirklicht. Selbstverständlich bot das dann eine Angriffsfläche, die natürlich schamlos von einigen ausgenutzt wurde um sich zu profilieren. Jetzt geht es darum die Software auf den Stand der aktuellen Technik zu heben. Ich bin allerdings immer noch nicht davon überzeugt, dass dies mit einem PHP-Framework sinnvoll ist, da es eigentlich selbst ein Framework ist. Es war auch immer das Ziel den Code so simpel wie möglich zu behalten, damit die Leute die Überblick behalten, und nicht solche Bausätze zu verwenden bei denen eigentlich niemand richtig durchblickt was geschieht und die irgendwie 100e Megabyte gross sind und ohne aufwändiges Caching gar nicht erst laufen. So wie es jetzt ist haben wir 2 MB Code... extrem performant... einfach zu verstehen.

              Gerade auch zum Thema Sicherheit: Ist der Code der die Sicherheit betrifft simpel und kurz gehalten kann man es überblicken und wirklich kontrollieren. Wie soll das gehen bei einem Skript wie beispielsweise Magento und siehe da so ist die Situation, jeder Shop der nicht auf der aktuellen Version von Magento ist hat zich Sicherheitslücken, das sind beinahe alle. Die wenigsten geben Geld aus für die Versionsupgrades, da extrem aufwändig, teuer und komplex. Ergo sind alle Magento Shops Scheunentore, probiert jetzt mal den Development Branch zu knacken, bezweifle dass ihr noch was findet und es ist auch ziemlich leise geworden jetzt diesbetreffend.
              bncms - Allround-Adminarea und CRUD-Library ------------------------------------------- jobbrett.net - Freelancer Jobboard mit niedrigen Gebühren nur 3%

              Kommentar


              • #97
                Zitat von bncms Beitrag anzeigen
                und ihr sagt selbst dass ihr das alle selbst nicht schnallt. Sondern nur Bausteine zusammensetzt.
                Autsch.

                Kommentar


                • #98
                  Zitat von bncms Beitrag anzeigen
                  Ergo sind alle Magento Shops Scheunentore [...]
                  Ganz im Gegensatz zu deinem System, nicht wahr?

                  Zitat von bncms Beitrag anzeigen
                  [...] probiert jetzt mal den Development Branch zu knacken, bezweifle dass ihr noch was findet [...]
                  https://github.com/damianhunziker/bn...s/ajax.php#L69
                  Genau deswegen ist Spaghetti Code nicht nur hässlich sondern auch unsicher.

                  Zitat von bncms Beitrag anzeigen
                  [...] und es ist auch ziemlich leise geworden jetzt diesbetreffend.​​​​
                  Bestimmt weil sich die Codequalität deutlich gebessert hat.
                  "Software is like Sex, it's best if it's free." - Linus Torvalds

                  Kommentar


                  • #99
                    Zitat von JaMa Beitrag anzeigen
                    https://github.com/damianhunziker/bn...s/ajax.php#L69
                    Genau deswegen ist Spaghetti Code nicht nur hässlich sondern auch unsicher.
                    Wow, so einen vermurksten Chaoscode hab ich noch nie gesehen. Und ich hab schon viel gesehn. Da wäre wegwerfen und neu schreiben wirklich sinnvoller und zeiteffizienter.

                    Kommentar


                    • @Jame
                      Stimmt dort muss ich noch escapen. Ist commitet. Sonst noch was gefunden?

                      Betreffend Magento, ja nicht nur dass Magento ohne Caching nicht im geringensten läuft also im Grunde eine Performance von einer Schnecke im Vergleich zu einem Ferrari von bncms hat. Ist der Code derart unübersichtlich geworden durch die Grösse, dass es durchaus unsicherer ist. Im Grunde sind 90% aller Magento Shops voller Sicherheitslücken weil sie nicht geupgraded werden. Es gibt eine Seite mit der kann man alle Sicherheitslücken eines Shops auflisten lassen.

                      Es gibt auch Vorteile wenn man nativen PHP Code verwendet, die Lernkurve ist flacher ist und die Funktionen sind weniger verschachtelt = weniger Overhead. Bei bncms habe ich nur Funktionen gemacht wenn sich Code wiederholt hat um genau den Spaghetti Effekt zu verhindern.
                      bncms - Allround-Adminarea und CRUD-Library ------------------------------------------- jobbrett.net - Freelancer Jobboard mit niedrigen Gebühren nur 3%

                      Kommentar


                      • Zitat von bncms Beitrag anzeigen
                        @JaMa
                        Stimmt dort muss ich noch escapen. Ist commitet. Sonst noch was gefunden?
                        Weißt du denn überhaupt warum du an der Stelle escapen musst?
                        Die Stelle habe ich nach 2 Minuten drüberschauens gefunden, also es wird sicherlich noch einiges zu finden sein. Aber es ist einfach nicht möglich den Code zu reviewen.


                        Zitat von bncms Beitrag anzeigen
                        Betreffend Magento, ja nicht nur dass Magento ohne Caching nicht im geringensten läuft also im Grunde eine Performance von einer Schnecke im Vergleich zu einem Ferrari von bncms hat. Ist der Code derart unübersichtlich geworden durch die Grösse, dass es durchaus unsicherer ist. Im Grunde sind 90% aller Magento Shops voller Sicherheitslücken weil sie nicht geupgraded werden. Es gibt eine Seite mit der kann man alle Sicherheitslücken eines Shops auflisten lassen.

                        Es gibt auch Vorteile wenn man nativen PHP Code verwendet, die Lernkurve ist flacher ist und die Funktionen sind weniger verschachtelt = weniger Overhead.
                        Und warum sollte man Magento (generell Webanwendungen) ohne Caching einsetzen?

                        Wo ist denn der Code bitte unübersichtlich? Kannst du mir da mal einen exemplarischen Vergleich zeigen, an dem deine Implementierung übersichtlicher ist als die von Magento?

                        Wenn deine Kunden oder Nutzer von bncms ihr System nicht updaten würden, dann hätten Sie ebenfalls noch die bereits behobenen Sicherheitlücken drin. Merkste?
                        Außerdem nimmt Magento an Bug Bounty Programmen (e.g. Hackerone) teil, bei denen pro Sicherheitslücke dem Finder Geld ausgeschüttet wird.

                        Ich hätte da noch eine Idee:
                        Da du ja behauptest, dass dein System so viel sicherer ist als alles andere, schlage ich dir vor dein eigenes Programm bei Hackerone zu starten, das 25$ pro Sicherheitslücke ausschüttet. Wie siehts aus?

                        "Software is like Sex, it's best if it's free." - Linus Torvalds

                        Kommentar


                        • Ja die Variable kommt aus einer Post Variable, die ein serialisiertes Array ist. Ich muss mir noch einen Weg überlegen wie ich damit am besten umgehen kann, weil die Post Variable ist nach dem decodieren nicht mehr als solche ersichtlich. Im Grunde wie ich mit Arrays umgehe, die aus Benutzereingaben stammen. Wenn die Arrays dann abgearbeiteten werden sind die Variablen eben auch nicht mehr als Post Variablen ersichtlich. Es ist eventuell am besten wenn ich sie in so etwas speichere wie $POST['array'] und in der foreach-Schleife dann $POST['key'], $POST['value']. Sonst erkennt man sie eben bei der Verwendung in der Query nicht wieder oder eben endlich ein Datenbankmodell, nur ich so wie ich das bis jetzt gesehen habe (Zend und ExtBase), können die oft nicht gut mit komplexen Queries und relationierten Daten umgehen, und das ist sehr wichtig für bncms.

                          Hackerone zu starten, das 25$ pro Sicherheitslücke ausschüttet
                          Soweit sind wir glaub noch nicht Das Problem ist mehr, dass die Sicherheitsupgrades von bestehenden Shops zu teuer sind und die Kunden entscheiden, dass es dem Nutzen nicht entspricht, auch weil eigentlich kein Schaden entsteht. Das einzige sind halt die Kundendaten, das ist zwar aus datenschützerischer Sicht problematisch, aber trotzdem machen das die Betreiber recht selten. Auch weil täglich neue Upgrades dazukommen und die verwendeten Erweiterungen immer überarbeitet werden müssen. Die Kosten für Magento Entwickler sind nicht gering.

                          Betreffend Cachine, es ist extrem verschwenderisch und nicht nachhaltig wenn ein ungecachter Request 20-30 Sekunden dauert, ausserdem für den Endbenutzer sollte er mal einen erhalten einfach total nervig.

                          Ich betrachte es als unsinnig diese Frameworks und Scripts derart aufzublähen das für jeden Request 200-500 MB in den Speicher geladen werden müssen aber jedem seine Meinung.

                          Zitat von JaMa Beitrag anzeigen
                          Wo ist denn der Code bitte unübersichtlich? Kannst du mir da mal einen exemplarischen Vergleich zeigen, an dem deine Implementierung übersichtlicher ist als die von Magento?

                          Wenn deine Kunden oder Nutzer von bncms ihr System nicht updaten würden, dann hätten Sie ebenfalls noch die bereits behobenen Sicherheitlücken drin
                          Der Problem ist dass ich bei mir über die Jahre viele Stile gemischt habe und die Namensgebnung nicht konsistent ist, das ist schlecht. Aber ich habe bei mir beispielsweise in der editor-functions.inc.php relativ zu Beginn alle sicherheitsrelevanten Funktionen aneinandergereiht. So ist aller Code, der für die Sicherheit zuständig ist, an eine Stelle konzentriert und nicht über 100e MB verteilt in irgendwelchen unendlich verschachtelten Methoden.

                          Selbstverständlich haben sie das aber wenn ein Skript 2MB gross ist kann man das einfach fixen.
                          bncms - Allround-Adminarea und CRUD-Library ------------------------------------------- jobbrett.net - Freelancer Jobboard mit niedrigen Gebühren nur 3%

                          Kommentar


                          • Zitat von bncms Beitrag anzeigen
                            Der Problem ist dass ich bei mir über die Jahre viele Stile gemischt habe und die Namensgebnung nicht konsistent ist, das ist schlecht. Aber ich habe bei mir beispielsweise in der editor-functions.inc.php relativ zu Beginn alle Sicherheitsrelevanten Funktionen zusammengereiht. So ist aller Code der für die Sicherheit wichtig ist an eine Stelle konzentriert und nicht über 100e MB verteilt in irgendwelchen unendlich verschachtelten Methoden.
                            Das ganze Konzept ist einfach von Grund auf falsch. Sicherheit entsteht nicht durch irgendwelche Funktionen, sondern durch die Programmierung selbst. Funktionen sind kein Wundermittel gegen Sicherheitslücken und keine Funktion der Welt kann einen Programmierer davon abhalten unsicheren Code zu schreiben.

                            Von daher ergibt der Ausdruck "alle Sicherheitsrelevanten Funktionen zusammengereiht" überhaupt keinen Sinn. Ob eine Funktion sicherheitsrelevant ist oder nicht entsteht aus dem Kontext, in dem sie verwendet wird. Funktion 1 kann im Kontext A sicherheitsrelevant sein und Funktion 2 im Kontext B. Aber 1 nicht in B und 2 nicht in A. Und jetzt vervielfache das mal auf tausende Funktion und verschiedenste Anwendungsbereiche. Alle möglichen Fälle und Kombinationen mit einer Funktionssammlung abzudecken ist einfach nicht möglich. Im Gegenteil, je größer so eine Sammlung wird, umso undurchschaubarer wird es, wie diese zu verwenden ist und das führt erst recht zu Sicherheitslücken, indem man sich blind auf irgendwelche Funktionen verlässt ohne zu wissen was man da überhaupt tut.

                            Dann gibt es noch Funktionen, die irgendwie "alles" abdecken wollen. Also SQL-Injections, XSS-Attacken, usw. usf. So eine eierlegende Wollmilchsau ist aber praktisch nicht möglich. Das ist ähnlich dem Bau eines Perpetuum mobile. In der Theorie hört sich das wunderbar an, nur hält sich die Realität an physikalische Gesetze, die gegen eine solche Theorie sprechen. So verhält es sich auch mit solchen Wundersicherheitsfunktionen. Sie versprechen viel, aber brechen in der Realität zusammen, weil es technisch einfach unmöglich ist.

                            Kommentar


                            • Ich habe das KISS-Prinzip verwendet und mir ist bewusst, dass Prepared Statements angebracht wären, nur ein grosser Teil des Codes wurde geschrieben als sich prepared Statements noch nicht etabliert hatten. Zudem werden an manchen Stellen die Feldnamen und Tabellennamen paramentrisiert und die müssten mann dann auch escaped werden es würde also an diesen Stellen auf das selbe hinauslaufen. Nichtsdestrotrotz würde es natürlich an allen anderen Stellen alles sicherer machen. Das Problem war einfach, dass PDO Queries viel zeitraubender zu schreiben / debuggen sind und nicht so übersichtlich sind. Trotzdem wir hatten das Thema jetzt schon zichmal und ich finde es schon etwas dreist, dass immer weiter darauf rumgeritten wird.

                              Klar wird schlussendlich an vielen Stellen Code verwendet der sicherheitsrelevant ist, das ist aber bei jedem Script so. Aber die Funktionen, die escapen, die für die Verhinderung von CSRF usw zuständig sind, sind eben alle an einer Stelle zentriert. Eingesetzt werden sie dann über das Script hinweg, das ist unvermeidbar und ist in jedem Script dasselbe. Mit Kontexten hat das eigentlich nichts zu tun, dass man dann die Funktionen im richtigen Kontext einsetzen muss versteht sich von selbst.

                              Trotzdem die ganze Diskussion betreffend Clean Code usw wird nur dazu geführt um von den innovativen Features von bncms abzulenken. Es war nie das Ziel irgendwie Programmierer mit hochmodernem Code zu beieindrucken (das überlass ich anderen die ein Müh Funktionalität in 200 MB Code verschachteln und sich dann von Nerds feiern lassen) sondern es ging darum einen Prototyp der einsatzfähig ist zu erstellen, dies pragmatisch, simpel und effektiv.
                              bncms - Allround-Adminarea und CRUD-Library ------------------------------------------- jobbrett.net - Freelancer Jobboard mit niedrigen Gebühren nur 3%

                              Kommentar


                              • Zitat von bncms Beitrag anzeigen
                                Aber die Funktionen, die escapen, die für die Verhinderung von CSRF usw zuständig sind, sind eben alle an einer Stelle zentriert.
                                Und das ist eben das Fehlkonzept. Die "zentrale Stelle" kann nicht wissen, in welchem Kontext sie verwendet wird und was gefährlich ist und was nicht. CSRF zu verhindern ist weitaus mehr als irgendwelche Zeichen zu escapen. Man muss CSRF verstanden haben um CSRF zu vermeiden. Und das kann einem keine Funktion abnehmen, sondern dafür braucht es Hirn.

                                Eine Funktionssammlung, die suggeriert, sie verhindere CSRF, ist eine ganz große Gefahr für unerfahrene Programmierer. Und erfahrene Programmierer treffen sowieso die richtigen Gegenmaßnahmen, ganz ohne irgendwelche Funktionssammlungen von Dritten, die hier nur ein zusätzliches Sicherheitsrisiko darstellen.

                                Einen Großteil der notwendigen Escape-Funktionen liefert PHP übrigens bereits mit und sind auch gut dokumentiert. Es gibt hier kein Bedarf eigene Funktionen zu schreiben, außer für andere Spezialfälle, die PHP nicht abdeckt.

                                Kommentar

                                Lädt...
                                X