Beiträge von paulchen

    theoretisch müsste noch folgender eintrag in die .htaccess:

    Code
    RewriteCond %{HTTP:X-Forwarded-Server} !^ssl-account\.com$ [NC]

    funktioniert aber nicht.
    ich hatte es auch probiert mit dem ausnehmen des rewrite bei ssl-verbindung. ging auch nicht.

    hier kann man auch nachlesen, dass ein ssl-proxy eh nicht das wahre ist, da die verbindung vom proxy zum host nicht mehr gesichert ist: http://www.ssl.de/ssl.html

    mal davon abgesehen, erscheinen dann auch beim client immer rote ausrufezeichen im ssl-symbol unten rechts, da irgendwelche bildchen etc. unverschlüsselt übertragen werden, was zwar fast egal wäre, aber je nach einstellung kann dann eine warnmeldung kommen, was für einen umsatzorientierten shop nicht förderlich ist.

    man kann auch bei all-inkl ein zertifikat kaufen.

    nichts destotrotz wäre es technisch trotzdem interessant zu wissen, warum das mit DIESEM proxy nicht geht.

    hier gibts auch noch was zu lesen:
    http://all-inkl.com/wichtig/anleit…ivieren_67.html

    beim aktuellen xt-commerce aka veyton ist das intus. nennt sich dort "Master/Slave Artikelsystem (ersetzt Attributsysteme)" und ist, was ich bis dato gelesen habe nicht optimal implementiert.

    es ist in der beschreibung jedoch überhaupt nicht ersichtlich, ob dieses master/slave-prinzip dynamisch ist.

    bei mir trifft das gleiche zu. nur ist mein proxy https://ssl-account.com (all-inkl).

    was hast du in der .htaccess stehen?


    neuinstallation kannst du dir schenken. ssl wird nur in der includes/configure.php aktiviert, was bei dir ja der fall ist.

    ansonsten bedarf es theoretisch noch eines eintrages in der htaccess, wobei imho bereits für ssl.webpack.de etwas vorhanden war. ist das bei dir auskommentiert?

    habe gerade probiert, bei dir einen account anzulegen. das war erfolglos. ssl-verbindung geht, login etc. geht nicht.

    in der standard-htaccess ist bereits ein eintrag für ssl.webpack drin:

    Code
    RewriteCond %{HTTP:X-Forwarded-Server} 		!^ssl\.webpack\.de$ [NC]

    wenn das bei dir, trotz eintrag, nicht geht, ist der eintrag standardmäßig falsch gesetzt.

    ich habe das bei mir mal auf

    Code
    RewriteCond %{HTTP:X-Forwarded-Server} 		!^ssl-account\.com$ [NC]


    gesetzt.

    geht auch nicht. das ist mist.

    ich habe das in einem anderen thread schon mal angesprochen: warum ist der ssl-switch in der admin/includes/configure.php in tüttelchen ('true') und in der includes/configure.php nicht??

    das problem bei diesen ssl-proxys ist auch, dass die verbindung nicht komplett verschlüsselt ist. zumindest habe ich dann unten rechts ein rotes ausrufezeichen auf dem verschlüsselungssymbol.

    auf eigenem server mit eigenem zertifikat hatte ich diese probleme nicht.

    am passwort kann es nicht liegen, da dieses automatisch eingetragen wird.

    passwort-reset geht auch nicht, da er meine mail-addy + username nicht mehr kennt (=account nicht mehr vorhanden - da früher mal da = gelöscht)

    mit "bezahlbar" kann ich nichts anfangen. das ist sehr relativ.

    hetzner ist gut und schnell. ein v-server ist da eigentlich schon overdressed. managed server kostet natürlich erheblich mehr. warum kein schneller webspace? damit hast du auch ein managing. http://www.webhostlist.de/webhosting/top…ing-privat.html


    hauptsache keine vertragsbindung, durch welche man heute leider die anbieter dazu animiert schlechte bzw. nicht vertragsgerechte leistung zu erbringen,
    auch wenn's durch irgendwelche lächerlichen lock-rabatte forciert wird.

    habe mir gerade einen privat-plus-tarif bei all-inkl.com zum testen geholt. fühlt sich bis jetzt ganz gut an. das einzige was mir da fehlt ist ein shell-account, aber den gibts im business-tarif auch nicht.

    um auf deine art den cache zu leeren, muss man erstmal in den adminbereich kommen ;)

    der htaccess-fehler lag am FORMAT. utf-8 mag der server nicht, bei ansi war er zufrieden.


    jetzt versuche ich mich am ssl-login. ein dicker krampf. am root-server ist das alles bedeutend einfacher.

    bei all-inkl.com kann man einen ssl-proxy nutzen. dieser wird mit https://ssl-account.com/domain.tld angesprochen.

    man könnte meinen, dass folgende zeile in der .htaccess genügt:

    Zitat


    RewriteCond %{HTTP:X-Forwarded-Server} !^ssl-account\.com$ [NC]

    tuts aber nicht - bleibt dann einfach mit einer weißen seite stehen.
    das passierte übigens auch früher bei jedem login. ich muss dann erst nochmal refreshen, damit ich von der weißen seite auf inhalt komme. nur tut's jetzt auch kein refresh mehr, da ein login über ssl-account.com nicht zustande kommt.

    vielleicht kann mal einer der all-inkl.com-user hier seine .htaccess posten.


    auf jeden fall gab es jetzt auch schon mehrere erfolglose logins. womit wahrscheinlich die max. login-anzahl von 3 griff. habe ich in der datenbank schon hochgesetzt und die time auf 0. geht nicht. *nerv*

    passwort-reset direkt auf der seite tuts auch nicht.
    passwort vergessen -> procedere durchführen -> link in mail anklicken -> es erscheint eine nichtssagende seite (e-mail nicht registriert - ist sie aber doch, sonst käme keine mail vom shop bei mir an) -> dann 2. mail mit passwort welches nicht funktioniert, mit dem hinweis "Die eingegebene E-Mail-Adresse ist nicht registriert. Bitte versuchen Sie es noch einmal. "

    prima

    problem gelöst.
    die entsprechenden einträge in der admin/includes/configure.php fehlten :D

    die .htaccess tuts leider noch nicht. aktiviert bringt sie eine 500 und der cache macht mich fertig (ja ist deaktiv/runtergesetzt/im browser deaktiviert) :D

    zustand:

    • webspace bei all-inkl.com
    • frische installation (2.08 + 2.09 fixpack)
    • ssl temporär auf false
    • pfade korrekt gesetzt (sollte man meinen)

    pfade in configure.php

    Code
    // * DIR_FS_* = Filesystem directories (local/physical)// * DIR_WS_* = Webserver directories (virtual/URL)define('HTTP_SERVER', 'http://domain.de.dd25602.kasserver.com'); //temporär, domain ist noch nicht umgeschaltetdefine('HTTPS_SERVER', 'https://ssl-account.com/domain.de'); define('ENABLE_SSL', false); define('DIR_WS_CATALOG', '/'); define('DIR_FS_DOCUMENT_ROOT', '/www/htdocs/w00d4211/');define('DIR_FS_CATALOG', '/www/htdocs/w00d4211/');define('COMMERCE_SEO_INSTALLED', 'true');define('DIR_WS_IMAGES', 'images/');define('DIR_WS_CATALOG_MOVIES', DIR_WS_IMAGES .'products_movies/');define('DIR_WS_ORIGINAL_IMAGES', DIR_WS_IMAGES .'product_images/original_images/');define('DIR_WS_THUMBNAIL_IMAGES', DIR_WS_IMAGES .'product_images/thumbnail_images/');define('DIR_WS_INFO_IMAGES', DIR_WS_IMAGES .'product_images/info_images/');define('DIR_WS_POPUP_IMAGES', DIR_WS_IMAGES .'product_images/popup_images/');define('DIR_WS_ICONS', DIR_WS_IMAGES . 'icons/');define('DIR_WS_INCLUDES',DIR_FS_DOCUMENT_ROOT. 'includes/');define('DIR_WS_FUNCTIONS', DIR_WS_INCLUDES . 'functions/');define('DIR_WS_CLASSES', DIR_WS_INCLUDES . 'classes/');define('DIR_WS_MODULES', DIR_WS_INCLUDES . 'modules/');define('DIR_WS_LANGUAGES', DIR_FS_CATALOG . 'lang/');define('DIR_WS_DOWNLOAD_PUBLIC', DIR_WS_CATALOG . 'pub/');define('DIR_FS_DOWNLOAD', DIR_FS_CATALOG . 'download/');define('DIR_FS_DOWNLOAD_PUBLIC', DIR_FS_CATALOG . 'pub/');define('DIR_FS_INC', DIR_FS_CATALOG . 'inc/');


    das login funktioniert. beim klick in die adminbox erscheint:

    Code
    Fatal error: require() [function.require]: Failed opening required '/www/htdocs/w00d4211/includes/classes/logger.php' (include_path='.:/usr/share/php:..') in /www/htdocs/w00d4211/admin/includes/application_top.php on line 133

    unter includes/classes gibts keine logger.php. die ist in admin/includes/classes.
    aus irgendeinem grund, wird das admin abgeschnitten.

    in der admin/includes/application_top.php in zeile 133 steht:

    Code
    // initialize the logger classrequire(DIR_WS_CLASSES . 'logger.php');

    die .htaccess ist original:

    warum springt die url wieder auf das stammverzeichnis?

    wie kann ich das beheben?