Beiträge von exception

    Respekt KingKong! Du hast echt ein Auge fürs Detail.
    Allerdings wird’s dich nicht wundern wie simple bzw. symptomatisch dieser Fehler mal wieder ist.


    templates\cseo-css-v2\module\create_account.html
    Line 6: <h2>{#heading_create_account#}</h2> --> i.O.


    templates\cseo-css-v2\module\create_account_guest.html
    Line 5: <h2>{#heading_create_account#}</h2>


    austauschen gegen:
    Line 5: <h2>{#heading_create_guestaccount#}</h2>

    Ok, also du wertest den falschen Parameter aus. Besser dafür geeignet ist der "REQUEST_URI" Wert, welcher bei der Startseite den Wert "/" besitzt.
    Es gibt aber noch eine Ausnahme, wenn du z.B.: www.domain.de/index.php?A=1 schickst,
    dann ist REQUEST_URI natürlich: /index.php?test=1 -> also überprüft man in diesem Fall den "SCRIPT_NAME" Wert.


    Code
    1. {if $smarty.server.REQUEST_URI === '/' || strpos($smarty.server.SCRIPT_NAME, 'index.php') !== false}
    2. {$BOXES_oben}
    3. {/if}


    Warum SCRIPT_NAME und nicht PHP_SELF?
    PHP_SELF gilt als unsicher und sollte vermieden werden. Einfach mal googlen.

    Hey Ulli,
    also ist doch ganz einfach und eigentlich schon vorhanden, so wie du es brauchst.


    <li style="width:30.7%" class="gallery_item"> == "grid"
    <li style="width:98%" class="last_li only_one"> == "list"


    Das bedeutet du kannst über die Klasse "only_one" spezifizieren und genau das gibt es bereits.
    /templates/cseo-css-v2/css/stylesheet.css


    ab Zeile: 350 (davor allgemein)
    ul.product_listing_gallery li.only_one {height:auto;}
    ul.product_listing_gallery li.only_one h2 {text-align:left;}
    ul.product_listing_gallery li.only_one .product_listing_gallery_misc {width:38%; padding-left: 10px;margin-top: 5px;} usw....


    hier kannst du dich austoben :)

    Haben das Problem gefunden (nur mit PHP5.3):
    Suche in Datei admin/module_export.php:


    Falsch! Der Fehler passiert auch in kleineren Versionen als 5.3. Der Unterschied ist nur, dass die PHP substr-function dort keine Warning wirft, sondern den als $key übergebenen String zurückgibt, was wiederum zur Folge hat, dass der "false" Fall niemals eintrifft, außer wenn $key leer wäre.
    Die Funktionalität ist aber trotzdem nicht erfüllt.

    Ok, wenn du ein wenig Ahnung vom Proggen hast, kennst du sicherlich das XAMPP Paket in diesem ist auch ADODB schon enthalten.
    Also schreibt dir einfach ein kleines Script, welches 1k SELECT, INSERT, UPDATE Befehle ausführt, mess die Zeit und du wirst sehen,
    dass mysqli am schnellsten und ADODB am langsamsten arbeiten.
    Dies ist auch vollkommen klar, denn das ewige inkludieren und interpretieren kosten einfach Zeit die kompiliere C-Bibliotheken von PHP nicht benötigen.


    Ich möchte damit gar nicht ausdrücken das ADODB schlecht ist, aber es "nachträglich" in ein System zu integrieren, wenn es performantere Alternativen gibt, halte ich zumindest für fragwürdig bzw. unnötig.

    Ich würde mal sagen, in PHP5.3.5 haben die PHP Kollegen einiges nicht mehr unterstützt. Das PayPal Modul ist das vom Hamburger Forum. Wenn da veraltete Befehle drin sind, müssen wir das prüfen. Bisher hat das PalPal Modul immer funktionier, zumal wir es selbst im Einsatz haben.


    Ganz sicher liegt es nicht expliziert an der PHP 5.3.5 Version, denn zum Vorgänger wurde nur ein Bug mit extremen Gleitkommazahlen behoben!
    http://www.php.net/ChangeLog-5.php#5.3.5

    Die einzig richtige Entscheidung!
    Ich habe echt nicht verstanden, was dieses "graue PHP Relikt" in diesem PHP Version 5.2+ Shopsystem noch verloren (bzw. Einzug gefunden) hat.
    ADODB = UNNÖTIGER BALLAST = PERFORMACE BREMSE


    Begründung:
    • ADODB bringt nur Nutzen, wenn Systemportabilität gefragt ist und dann ist PDO die performantere Alternative
    • ADODB gehört schon lange nicht mehr zum PEAR Paket und wird nicht mehr von der PHP Group empfohlen
    • PDO vermag selbiges leisten und ist dabei als PHP Extension um ein vielfaches schneller
    • mysql bzw. die neuere mysqli Schnittschelle bleiben die Schnellsten, wenn’s um PHP + MySQL geht


    Welchen Gewinn bringt dir ADODB?
    Ich persönlich halte es wie Google, Performance ist alles!

    ...welche ich in "ermangelung" eines fernseher nie gesehen habe.


    ...wer es dir glauben mag! Auch kein Internet TV?



    wenn ein server gehackt wurde, ist das eine kriminelle handlung - für manche shopbetreiber ist das vielleicht eine "normale" situation. es geht dabei jedoch nicht um umsatzausfälle, zeitverlust und derlei, sondern um kundendaten und darüber hinaus um eigene strafbare handlungen.
    hättest du mein 1. posting gelesen, hättest du verstanden, was er mit dem backup machen kann.


    Stimme ich dir zu, Provider informieren ggf. Polizei und Staatsanwaltschaft informieren.



    nach einem standart-hack werden die logs unter umständen gesäubert, zumindest sind diese mit vorsicht zu genießen.
    man kann jedoch das gezogene backup mit dem letzten vergleichen. zu dieser schlussfolgerung kann man selbst als laie kommen.


    Und wieder nur ein Teil genommen, sehr schön! Natürlich werden die Logs gecleant...aber auch egal, denn nun trifft oben geschriebener Fall zu und dann sollte er gar nichts mehr am System machen, Profis an fertig.



    fein ;) der shop ist in php geschrieben. d.h. php ist definitiv auf seinem server installiert, der rest sind nur vermutungen.
    und ja, ich glaube dir, dass du die besten perl-scripts weit und breit schreibst. hat aber nichts mit dem thema zu tun.


    Darum ging es bei meiner Argumentation überhaupt nicht. Ich habe bloß andere Beispiele gebracht um deine Aussagen in Bezug auf PHP zu wiederlegen.



    php ist sehr sicherheitskritisch - ergo ist mindestens eine sehr restriktive php-konfig unabdingbar, da mit sicherheit in jedem php-script sicherheitsrelevante fehler enthalten sind. die frage ist nur, WANN diese ausgenutzt werden.


    Denn diese Aussage (Panikmache) ist schlicht und einfach FALSCH! PHP ist NICHT sicherheitskritisch und NICHT jedes Programm enthält FEHLER! Dies sind einfach nur pauschale Behauptungen deinerseits.



    ich muss gestehen, dass bei mir noch php 5.2.4 läuft und das wird vorerst auch so bleiben. da sind diese einstellungen durchaus noch relevant. interessierte können sich unter http://www.php.net/manual/de/ini.list.php die direktiven und deren funktion anschauen. disable_functions wäre auch noch sehr interessant.


    Hmm...gekonnt der Falle mit disable_functions und eval ausgewichen. Also wusstest schon das eval nicht disabled werden kann. Respekt! Eval ist eben keine Funktion.
    disable_functions "" - viel mehr achte ich darauf, dass die PHP Erweiterung Suhosin installiert und up to date ist.



    du als php- und server-crack kannst uns bestimmt erklären, wie eine korrekt auf diesen shop dedizierte php.ini auszusehen hat. ich bin gespannt und lerne immer gerne dazu.


    Gehe ich richtig der Annahme, dass du Ubuntu 8.04 LTS benutzt? Das würde die Version 5.2.4 erklären.
    Aber welche PHP - Standardeinstellungen stören dich denn nun, dass sich ein Laie damit UNBEDINGT befassen muss?


    Ich, für meinen Teil achte neben der Standardkonfiguration darauf:
    - allow_call_time_pass_reference off
    - arg_separator.output &amp; - W3C konforme URLs zu erhalten
    - display_errors off - auf einem Produktivsystem haben Fehleranzeigen nichts verloren
    - html_errors off
    - log_errors on - um Fehlermeldungen natürlich mitzubekommen
    - magic_quotes_gpc off - schalte ich immer ab, verlasse mich nur auf meine Einstellungen und ist ab 5.3 eh auf off
    - memory_limit "128M" - wenn es nicht schon einstellt ist und der Server ausreichend Ressourcen besitzt
    - register_long_arrays off


    Aber all diese Einstellungen sind als Beispiel bei Strato & 1und1 mit OpenSuse Server schon so eingestellt. Allerdings nutzen diese PHP Versionen > 5.2.4.




    du schreibst von version 6?? die kommt irgendwann, aber momentan sind wir bei 5.3.3. was mitnichten heißt, dass diese auch auf einem gut gewarteten server laufen muss.


    Du hast mich missverstanden. Ich sprach von Version 6, weil PHP Version 5.3 (Zwischenschritt) schon viele der größeren Änderungen mitbringt und da dieser Shop sich PHP 5.3 auf die Fahnen geschrieben hat, schaue ich dementsprechend auch voraus (Stichpunkt: PHP 5.3 DEPRECATED).



    mit threadstarter meinte ich den menschen, welcher das ursprungsposting in diesem "diskussionfaden" umgangsschriftlich auch "thread" genannt, schrieb.


    Stimmt, wie blöde von mir. Das hab ich einfach falsch verstanden.



    natürlich. ein zertifikat ist notwendig. wenn auch für die shopeinrichtung ein selbst unterschriebenes (und sogar abgelaufenes) temporär reichen würde. da jedoch für den shop so und so ein offiziell unterschriebenes nötig ist, gesetzt dem fall man bietet verschlüsselung für den kunden an, ist vorhergehende überlegung hinfällig.


    Sehe ich genauso!



    man merkt, wie wenig du die materie verinnerlich hast, denn sonst wüsstest du, dass sftp (nachfolger von scp) sehr wohl komplett verschlüsselt ist.
    du verwechselst sftp mit secure ftp, bei welchem nur der steuerkanal verschlüsselt wird, was aber immerhin schon mal besser als gar nix ist.


    Stimmt habe ich genauso verwechselt, aber Wiki ist da auch geil:
    Zu Anfang: SSH File Transfer Protocol (SFTP) ist eine Weiterentwicklung von SCP
    2 Zeilen darunter: ist SFTP eine Neuentwicklung der IETF



    scheint gar darauf hinzudeuten, dass du bis dato gar keine ftp-alternativen kanntest.


    Natürlich kenne ich andere Varianten, wie den Upload über http, wget usw...aber wie du an meiner Verwechselung schon bemerkt hast, zählte ich SFTP fälschlicher Weise voll zum Kreis FTP. Da ich den SSH-Server (Port 22) bisher eben nur mit Putty angesprochen habe, wohl noch ein Überbleibsel meiner Windows-Server Zeit.
    Normalerweise übertrage ich immer FTPS da es eben Plattform übergreifend ist.



    seine beschreibung sah für mich so aus, als würde sein virenscanner bei seitenaufrufen seines shops alarm auslösen, was ein typisches indiz für eine kompromittierung ist.


    Sicherlich hat sich der Threadstarter :) einfach schlecht ausgedrückt und es war Zufall das das Virenprogramm zur selben Zeit Alarm schlug.
    Das bei seinem Shop etwas fehlte bzw. verschwunden war, ist vielleicht eher der Tatsache geschuldet, dass er Shop-Dateien und Einstellungen selbstständig veränderte. Wahrscheinlich greifen wir beide schon einen Schritt zuweit oder wie man so schön sagt: "Wenn Du Hufe hörst, denke an Pferde, nicht an Zebras!"



    Ironie ist es doch, dass wir beide über die bessere Vorgehensweisen oder über Möglichkeiten der Kompromittierung diskutieren und "similar" sein Problem einfach ausführlicher beschreiben könnte, um somit sämtliche Missverständnisse zu beseitigen.




    das ändert wiederum nichts daran, dass mein themenbezogener erkenntnisgewinn durch deine schriftlichen ergüsse immer noch gleich null ist. das sollte doch angesichts der hochgesteckten erwartungen nach doch eigentlich bedeutend anders ausfallen.


    klar, können wir jetzt völligst offtopic darüber philosophieren, ob jetzt php sicherheitskritisch ist oder perl, asp, c noch kritischer - dafür wäre ich btw. der falsche partner.


    Wechle themenbezogenden Erkenntnisse sind denn von dir eingeflossen??? Das Erkennen eines Windows Virus oder eher:


    - PHP ist sehr sicherheitskritisch
    - eine restriktive config ist notwendig
    - darüber hinaus sind folgende anwendungen/szenarieren im prinzip auch nicht mehr tragbar


    Da haben sich deine Ergüsse und Problemlösungsansätze aber in Grenzen gehalten!




    letzten endes kann die ursache dieses themas auch eine ganz andere sein :)


    Kann ich so nur doppelt unterstreichen und mit SFTP noch was gelernt :)

    Ja, also bei den Artikelmerkmalen gibt's noch ein kleines Problem.
    Du musst dazu im JTL WaWi connector noch zwei Files auf UTF-8 anpassen; die hier im Paket vergessen wurden.


    -----------------------
    ZEILE: 23 Variation.php
    Fehlende UTF-8 Anpassung.


    $Eigenschaft->cName = realEscape($_POST['Name']);
    to
    $Eigenschaft->cName = iconv("ISO-8859-1","UTF-8",realEscape($_POST['Name']));
    --------------------------------------------------------------------------------


    ZEILE: 26 VariationWert.php
    Fehlende UTF-8 Anpassung.


    $EigenschaftWert->cName = realEscape($_POST['Name']);
    to
    $EigenschaftWert->cName = iconv("ISO-8859-1","UTF-8",realEscape($_POST['Name']));



    Danach sollte auch die Übertragung der Artikelmerkmale funktionieren. :)

    Unglaublich...aus forensischen Gründen (Fehleranalyse offline)!
    Zuviel CSI geschaut?
    Was soll denn ein Laie mit diesem Backup anstellen? Für ihn bringt dies NIX! Und wenn überhaupt, dann nur die conf und die log Dateien.



    ... ob php genau so kritisch ist wie andere sprachen, da auf seinem server definitiv php läuft.


    Was für ein Quatsch...da auf diesem Server sicherlich auch CGI, Perl, SSI oder ASP läuft! Es geht um deine Verallgemeinerungen die haltlos sind.
    Nur nen Tipp: mit Perl kann man viel mehr anstellen :)



    mit restriktive php-config meine ich wenigstens ein eingehendes befassen mit der php.ini
    stichworte wären hier z.b. allow_url_fopen, allow_url_include, disable_functions, open_basedir, register_globals, safe_mode etc.


    An dieser Aussage merkt man ganz deutlich, dass dein Wissen einfach aus einer Zeit vor PHP 5.1 stammt. Mal davon abgesehen das ein Laie, der ein Server mietet schon einen Standard vorkonfigurierten Server bekommt und solch Einstellungen nicht mehr vornehmen muss. Des weiteren sind register_globals und safe_mode Dinge der Vergangenheit die mit Ver6 vollständig verschwunden sind und allow_url_fopen + allow_url_include sind Einstellungen welche ich nicht missen möchte.
    Welche Funktionen würdest du denn disablen, eval? lol


    ...threadstarter? PHP unterstützt gar keine Threads. Der Vergleich hinkt, eher User oder Clients.



    ssl THEMENBEZOGEN, was sonst? d.h. aktiviertes apache-ssl-modul. in diesem fall hat der apache sehr wohl etwas mit ssl zu tun. ebenso muss bei der shopeinrichtigung ssl berücksichtigt werden.


    Ok dann zum Thema: mod_ssl ist standardmäßig im Apache 2 aktiviert, viel wichtiger ist dabei ein gültiges Zertifikat.
    wenn nicht, loggt sich auch der admin unverschlüsselt ein.


    Auch in Bezug auf FTP sind deine Informationen nur zum teil richtig und man merkt wie wenig du die Materie verinnerlicht hast, denn sonst wüsstest du, dass SFTP nicht die momentan beste alternative ist! Denn SFTP verschlüsselt nämlich nur einen Teil des FTP-Protokolls, den Steuerkanal...sonst wäre in diesem Zusammenhang Secure FTP (Basis SCP) oder FTPS (Basis TSL/SSL) zu nehmen.



    nach deiner methode (wiederherstellen eines backups), würdest du genau den fehlerhaften zustand wie VOR dem hack herstellen, welcher zu den entsprechenden ereignissen führte - ohne zu wissen WO der betreffende fehler liegt.


    streng fahrlässig

    ???


    Wenn man davon ausgeht, dass dieser Server bei einem vertrauenswürdigen Provider steht, wäre Restore - Passwörter wechseln - Provider informieren unter gewissen Voraussetzungen eine schnelle Möglichkeit den Urzustand wieder herzustellen.
    Außerdem auf Prob. von similar bezogen stellt sich die Frage, ob der private PC oder der Server befallen ist, denn dies sind Windows-Meldungen. Vorstellbar wäre durchaus, dass vom privaten Rechner aus die Passwörter ausgespäht wurden und der Server nicht einem Hack, sondern der Tatsache der Bekanntgabe der Passwörter zum Opfer gefallen ist.

    Die htaccess Datei vor der Installation entfernt, weil sonst der Install nicht funktioniert hätte?
    1. Also wenn du zu solchen Mitteln greifen musst um den Shop zu installieren, dann mach dir schon mal Gedanken zum Hostingpaket (Servereinstellungen). Die sind dann nix.
    2. Natürlich benötigen die SEO-URL's eine funktionierende htaccess Datei.
    3. "ausklammern"? Du meinst "#" also kommentieren und auskommentieren oder?


    Was passiert denn, wenn du die originale htaccess Datei vom Shop benutzt?

    Hast du denn die SEO URL Installation und Aktivierung exakt so durchgeführt?


    2. SEO URLs
    Bevor Sie Produkte anlegen, empfehlt es sich die SEO URLs zu aktvieren, damit diese gleich beim
    abspeichern eines Produktes erzeugt werden können.
    Wechseln Sie in den Adminbereich. Suchen Sie zu „Module → cSEO Module → commerce:SEO URL v1“.
    Aktvieren Sie dieses Modul durch „Installieren → Start“ und stellen Sie alle benötgten
    Parameter ein. Der Shop benutzt nun die Suchmaschinen freundlichen URL's.


    Tipp: Vergessen Sie nicht den untersten Punkt: „Sollen die SEO-URL's im Shop aktviert werden?“
    auf „Ja“ zu setzen.


    Haste auch das auf "Ja" setzen gemacht?

    Hi,
    also verstehe ich das Richtig, dass du die Installation abgeschlossen hast und dich bereits im Adminbereich umgesehen hast?
    Hast du denn auch unter Module - cSEO Module - die commerceSEO URL Modul aktiviert?