wenn ich die suche direkt in der suchbox verwende, kommt:
404
Die von Ihnen angeforderte Seite wurde nicht gefunden.Bitte überprüfen Sie die korrekte schreibweise der URL, oder nutzen Sie die Suchfunktion.
inklusive einer NEUEN suchzeile darunter.
gebe ich in diese neue suchzeile genau das gleiche wie vorher eingebe, kommen die ergebnisse.
die ERWEITERTE suche funktioniert sofort.
v2.07CE
Ja ja, so sind 'se. Was da alles in so einen Shop rein müsste... Aber kosten sollte es wenig bis garnichts
ja, natürlich ist das ein feature, welches ich gerne begrüßen würde. insofern ist meine anregung eigennutz.
auf der anderen seite bin ich mir zu 100% sicher, dass eine derartige shop-option eurer geschäft sehr stark vorantreiben würde, allzumal ihr euch auf seo spezialisiert habt und dieses feature DIREKT damit zusammenhängt.
die frage ist nur, wie man programmierung, support und verkauf zukünftig koordiniert/organisiert/weiterleitet/... um der entstehenden anfragenflut herr zu werden und aus dieser entsprechende umsätze generiert. an den finanziellen mitteln wird es nicht mehr liegen.
das was ihr hier quasi mit der community-edition habt, ist der traum eines jeden produkt-herstellers/entwicklers: der konsument teilt euch direkt seine bedürfnisse mit, so dass diese in die entwicklung einfließen können. somit seit ihr in der lage ein universelles system zu entwickeln, welches den meisten hauptanforderungen (im rahmen der spezialisierung) mehr als genügt.
sind spezielle anpassungen nötig, werden diese von euch sicher eh gegen entgelt vorgenommen. nur ist ein weitgehend universelles produkt, gleichgar im softwarebereich, ungleich profitabler als entgeltliche einzeladaptionen.
Wenn du jede Artikel-Variante einzeln im Shop hinterlegst, mußt du natürlich auch für jede Artikel-Variante die Meta description und den Meta Title entsprechend variieren. Sonst ist natürlich doppelter / mehrfacher Content.
ja. das ist klar und auch nur das geringste übel. nichts destotrotz, muss eben auch die wesentlich umfangreichere artikelbeschreibung STARK variieren. ich würde sogar soweit gehen und behaupten, dass title und description in diesem fall BEDEUTEND weniger ins gewicht fallen als der eigentliche content.
ich selbst verwende für titel und beschreibung einfach den (aussagekräftigen) produktname, welcher eh immer einzigartig ist.
mein geschäftsfeld liegt nicht im php- bzw. programmierbereich, d.h. ich bin laie.
ich habe einen programmier gefragt und er meinte, dass man derartiges mit ajax lösen könnte.
als laie stelle ich mir das mit if-then-abfragen vor.
am beispiel eines t-shirt-shops, welcher verschiedene prints anbietet:
produkt = motiv 1
artikeloptionen bzw. attribut "shirtart":
- t-shirt
- girl-shirt
- pullover
weiteres attribute "größe":
- t-shirts gibts in der größe S-L
- girl-shirts von S-XL
- pullover von XS-XXL
weiteres attribut "farbe":
- t-shirts gibts in gelb, grün und rot
- girl-shirts in pink und hellblau
- pullover in schwarz und grün
d.h., dass sich die attributauswahl dynamisch verändern muss, je nachdem, welches vorherige, man könnte auch sagen "eltern-attribut", vom kunden gewählt wurde.
am beispiel heißt das dann:
eine kunde wählt motiv 1 als girlshirt,
ihm bieten sich jetzt NUR die größen S-XL und die farben pink und schwarz als auswahl. alle anderen optionen erscheinen dann nicht in der auswahl.
man könnte das, je nach produkt noch bedeutend weiter ausbauen. am beispiel könnte z.b. bei motiv 1 -> girlshirt -> größe M -> NUR die farbe pink verfügbar sein, bei S, L, und XL pink und hellblau.
man könnte auch schreiben/sagen, dass die attribute in stufen, wie in einer hierarchie angeordnet sind.
höchste stufe in der hierarchie ist am beispiel das attribut "shirtart", welches die nachfolgenden auswahlmöglichkeiten eingrenzt oder erweitert, dann kommt "größe" und am ende, bedingt durch die vorherigen stufen erscheint eine farbauswahl.
diese sache betrifft SEHR viele produktarten.
in heftigem ausmaß sieht man das z.b. beim online-konfigurieren von autos vor dem kauf.
ich hoffe, meine ausführungen tragen zu einem besseren verständnis bei.
Googletechnisch ist es besser jedes Produkt einzeln aufzunehmen. So hast Du automatisch mehr Seiten im Index usw..
ich habe mir von einem profi sagen lassen, dass es seo-technisch nicht gut, bzw. sehr kontraproduktiv ist, wenn ein produkt mehrfach angelegt ist.
das problem habe ich auch gerade, bzw. arbeite an einer lösung.
am obigen beispiel der motorrad-teile erläutert:
legt er ein produkt 5x an, da es 5 unterschiedliche varianten gibt, sollte auf keinen fall die gleiche artikelbeschreibung (mit nur kleinen abweichungen, je nach variante) für alle 5 varianten verwendet werden, da das ganze sonst von google als duplicate content gewertet wird und man mächtig ranking verliert bzw. mehr oder weniger fast komplett aus dem index fliegt. d.h. die aktion mit dem 5-maligen anlegen VERHINDERT gar umsätze, bzw. wirkt sich auch noch negativst auf das ranking der kompletten domain aus, was wiederum umsätze verhindert.
d.h. er hat den 5-fachen administrationsaufwand, um aus marginalen produktunterschieden komplett andere artikelbeschreibungen zu erstellen, was für google zwar eigentlich ok wäre, den kunden jedoch wiederum verwirren dürfte.
oder man lässt die artikelbeschreibung fast komplett weg - dann fehlts wieder an inhalt und für das wichtigste, den kunden, ist das nicht empfehlenswert.
ich denke mal, dass der shop bereits bei wenigen artikeln ausreichend indexierte seiten enthält. da kann man auch mit bedeutend weniger seiten höhere rankings erzielen.
genau aus diesem grund, wären INTELLIGENTE artikeloptionen, welche aufeinander aufbauen, SEO-technisch extremst sinnvoll. da ist es primär nicht mal unbedingt nötig, dass auch die artikelbilder umswitchen - die kann man ja in ausreichender anzahl einfügen. wäre natürlich spitze, wenn das auch gänge 
Jetzt hab ich's gesehen.
Nun muss ich die Deutsche Post nur noch um Erlaubnis fragen ob ich auf deren Preis noch Steuern aufschlagen darf... Wo gibts denn sowas.
Seit wann schlagen wir auf eine Leistung die uns inkl. MwSt. übergeben wird noch Steuern drauf?
Das hat schon seine Bewandnis das da keine Steuern mehr berechnet werden. Ich habe noch nie in einem Shop meiner bissher, na bestimmt 600 Kunden, Steuern auf eine Versandart aufgeschlagen. Darf ich ja garnicht! Die Leistung wird von einem anderen Unternehmen ausgeführt welches schon Steuern erhebt. Da Steuern aufzuschlagen um die wieder "reinzuholen" ist doch gar nicht erlaubt.
da unterläuft dir ein denkfehler.
versandkosten heißt nicht, dass diese nur leistungen dritter enthalten (post, ups, etc.) sondern beinhalten, zumindest hierzulande, auch das handling, verpackung, etc.
bei einer sauberen und transparenten kalkulation könnte das z.b. so aussehen: artikel X (preis 100€ netto) wird per dhl versendet.
verpackung kostet 0,5€ (alles netto).
porto kostet 6,70€ (brutto wie netto, da umsatzsteuerfrei, was aber auch egal ist)
handling (verpacken, zur post schaffen u.ä.): 3€
summe: 110,20 € netto
+ 19% USt: 20,49 €
-------------------------------
endpreis (brutto): 131,14 €
man kann das handling + verpackung auch in die produktkosten einrechnen, was mehr oder weniger die meisten machen. ist ja jedem selbst überlassen.
der UMSATZSTEUERPFLICHTIGE umsatz beträgt 110,20€ und davon sind die 19% USt fällig.
ich glaube nicht, dass der gesetzgeber auf die USt der post verzichtet hätte, wenn er nicht wüßte, dass der versendende unternehmer diese durchaus abführen muss
egal. die umsatzsteuer MUSS auf jeden fall auch auf die versandkosten aufgeschlagen werden. alles andere kann keiner betriebsprüfung standhalten (es sei denn man ist kleinunternehmer).
alle angaben natürlich ohne gewähr
na ja. so viel fehlt da nicht.
ich habe nur noch folgende zeilen in die lang/english/english.php eingefügt, damit es auf der ersten seite nicht mehr so abschreckend für englischsprachige aussieht :
define('TEXT_BUTTON_BUY_NOW', 'buy now');
define('TEXT_TO_WISHLIST', 'to wishlist');
define('IMAGE_BUTTON_SEND', 'Send');
define('BOX_EMAIL_VALUE', 'your eMail-address');
define('IMAGE_BUTTON_PRINT', 'Print');Hat hier jemand eine Ahnung, wo die Texte für die Buttons in englisch (keine Grafik, sondern Text) hinterlegt bzw. änderbar sind?
Viele Buttons haben teilweise noch Beschriftungen wie "TEXT_BUTTON_BUY_NOW", "TEXT_TO_WISHLIST" und "IMAGE_BUTTON_PRINT" und manche haben wiederum eine korrekte Beschriftung.
Vielen Dank.
Die v2.1 Plus wird sich von der v2 - Reihe abkapseln. Darin ist dann auch ein Master-Slave System, ein Familien-System und erweiterte Attribute, etc....
was darf ich unter den erweiterten attributen verstehen?
sind das aufeinander aufbauende attribute (nach einem wenn-dann-prinzip)?
und genau so habe ich das auch verstanden und genau deshalb bin ich auch so scharf darauf, dass die wolke einwandfrei funktioniert.
es lohnt sich in die tags ordentlich hirnschmalz hineinzustecken.
das ist prima!
ich freue mich schon auf das update 
auch wenn die IDs stimmen gibts probleme:
ich habe die tag-zuordnung direkt in die datenbank eingetragen. die zuordung produkt-id/language-id/tag-id ist auch vorhanden.
die tags erscheinen auch - nur produzieren sie links mit 404-fehlern, d.h. ich habe dann in der tag-cloud sehr viele tote links, was seo-technisch sehr kontraproduktiv sein dürfte.
in eurem demoshop (plus-version) kommt zwar kein 404, dafür jedoch "0 treffer" was ja eigentlich auch nicht sein kann.
die links haben das format tag/jeweiligertagname
da viele tags mehrfach vergeben sind, gibts in der wolke auch keine größendifferenzierung mehr. sieht nicht gut aus, da alles riesengroß. läßt sich da irgendwo ein schwellwert verstellen?
...wer es dir glauben mag! Auch kein Internet TV?
nein, das wäre irgendwie des gleiche
die entscheidung des "verzichts" bzw. der lebensbereicherung fiel während des wahlkampfes 2002 ("viel reden und nichts sagen" in kombination mit knappen zeitressourcen und der absurdität für derlei auch noch gebühren zu zahlen.
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.
dito
genau. deshalb ist es gar nicht mal so sinnlos, erst den server herunterzufahren und weiteres über die remote-konsole zu veranlassen. ein backup mit bordmitteln könnte auch etwas sehr ungewolltes auslösen.
wer weiß, was bereits ein simples "cd" oder "ls" bewirkt
Darum ging es bei meiner Argumentation überhaupt nicht. Ich habe bloß andere Beispiele gebracht um deine Aussagen in Bezug auf PHP zu wiederlegen.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 kenne mich mit php-programmierung nicht aus. jedoch weiß ich eines: php ist ausreichend mächtig und darüber hinaus die breiteste angriffsfläche eines kleinen standart-servers (die masse) von irgendwelchen bruteforce-ssh- und mail-attacken einmal abgesehen, mit welcher man auch eine php-shell erzeugen könnte (ohne safe_mode) und darüber hinaus auch noch datenbankanbindung besteht.
php selbst beinhaltet auf jeden fall fehler und das wird immer so bleiben (so wie bei fast jeder software). die aufgedeckten kann man den bugfix-listen entnehmen. wer jedoch glaubt, dass nach einem bugfix oder gar major release keine fehler mehr enthalten sind, der irrt definitiv.
in dem zusammenhang auch ganz interessant: http://webdeveloper.franzis.de/php-5x/php-6-i…er-pierre-joye/
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.
WENN php nicht sicherheitskritisch wäre, gäbe es keine hardened php und damit auch kein suhosin.
suhosin macht nichts anderes, als funktionen, welche alternativ unter disable_functions standen, zu deaktivieren.
in dem kontext auch interessant: http://www.hardened-php.net/suhosin/why.html
aber bei aktiviertem safe_mode würde disable_functions nicht greifen.
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?
ja, 8.04.
register_globals off (ja, ich weiss, ab 5.3 nicht mehr interessant)
magic_quotes off (-"-)
expose_php off (ja, kontrovers, aber es schadet auf keinen fall)
allow_url_fopen off (da ich nicht einschätzen kann, ob das script "sauber" programmiert ist)
im wesentlichen halte ich mich an die offiziellen empfehlungen, auf welche auch noch mal in der php.ini hingewiesen wird:
;;;;;;;;;;;
; WARNING ;
;;;;;;;;;;;
; This is the default settings file for new PHP installations.
; By default, PHP installs itself with a configuration suitable for
; development purposes, and *NOT* for production purposes.
; For several security-oriented considerations that should be taken
; before going online with your site, please consult php.ini-recommended
; and http://php.net/manual/en/security.php.
früher hatte ich zusätzlich mod_security in betrieb. ob das noch nötig ist, entzieht sich meiner kenntnis.
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
ja. prinzipiell fast egal, da die standart-applikationen a la winSCP, cyberduck bzw. ssh2 (sftp), welche meist verwendet werden da schon das entsprechende protokoll verwenden und ein ftp-server eh nicht läuft, sondern schön säuberlich der sshd (2) mit deaktiviertem root-login und sonst nix. aber wie schon bemerkt: bei schwachen passwörtern bringen starke verschlüsselungen auch nicht viel - deshalb ist eine schlüsseldatei mit passwort optimal.
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.
ja, auf jeden fall 
jetzt geht es kaum noch um seinen fall, sondern um typisch männliche verhaltensweisen - quasi als soziologie-studie ;);)
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 tragbarDa haben sich deine Ergüsse und Problemlösungsansätze aber in Grenzen gehalten!
mein 1. posting war folgendes (nochmal zum rekapitulieren):
ich, an deiner stelle, würde wie folgt vorgehen:server abschalten.
backup ziehen.
jemanden hinzuziehen, der sich mit serversicherheit auskennt.
jeden tag werden mehr server gehackt, als man sich vorstellen kann.
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.
darüber hinaus sind folgende anwendungen/szenarieren im prinzip auch nicht mehr tragbar - gleich gar nicht, wenn man mit kundendaten hantiert:
- fehlender apache-ssl
- ftp
- schwache passwörter
das war doch ganz konkret. auch auf einen "laien" zugeschnitten. oder?
wie läuft es denn im normalfall?
phpmyadmin installiert
ein webadmin-interface installiert
ein völligst overdressed cms (php) mit plugins von drittanbietern
ein webshop (php) mit vielen hacks
irgendein php-script für irgendeine abstruse funktion (gästebuch, counter, logger, mailform ...)
updates (meist sicherheitsrelevante bugfixes) werden oft nicht eingespielt. damit liegt der fehler zwar beim user - jedoch nur aus dem grund, weil ein fehler im script erkannt und beseitigt wurde.
wenn da nix geht, dann weiß ich auch nicht mehr. meist laufen nicht einmal die (erwünschten) kernfunktionen zu 100% fehlerfrei, da will ich gar nicht ahnen, was noch so alles gehen könnte ...
ich möchte da mitnichten zu krankhafter paranoia anregen, jedoch sollte man sich bestimmter risiken auch bewusst sein.
man kann mit warez-servern, bot-nets und spam-servern ordentlich geld verdienen (und einiges anderes). das reicht als motivation.
open-source ist schön. wenn man den code jedoch nicht versteht oder in seiner gänze mitnichten überblicken kann, lassen sich fehler (oder schlimmeres) kaum bzw. schlicht und einfach nicht erkennen - und wenn, dann auch nur bei unfehlbarkeit des prüfers bzw. reichlich manpower.
nichtsdestotrotz: alles bestens
vielleicht finden wir ja bald einen verleger :D:D
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.
csi? kenne ich nicht. ich vermute mal, dass es sich dabei um eine fernsehsendung handelt, welche ich in "ermangelung" eines fernseher nie gesehen habe.
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.
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.
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
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.
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
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.
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.
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.
...threadstarter? PHP unterstützt gar keine Threads. Der Vergleich hinkt, eher User oder Clients.
mit threadstarter meinte ich den menschen, welcher das ursprungsposting in diesem "diskussionfaden" umgangsschriftlich auch "thread" genannt, schrieb.
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.
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.
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.
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.
eines deiner ersten beiträge in diesem thread:
3. Was bitte hat FTP damit zu tun? Wie überträgst du denn Files zum Server? --per $_POST...haha - insider
scheint gar darauf hinzudeuten, dass du bis dato gar keine ftp-alternativen kanntest.
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.
das sehe ich auch so. jedoch wäre vor dem restore ein backup sinnvoll. das kann er dann einer sachkundigen person übergeben und/oder selbst noch dazulernen, in dem er das backup z.b. wie oben beschrieben untersucht.
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.
ja. es gibt einige möglichkeiten.
sein eigener lokaler rechner kann befallen sein, so dass zugangsdaten übermittelt wurden. sein lan (oder wlan) kann ausgespäht worden sein.
sein server kann gehackt sein - über welches einfallstor auch immer.
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.
mag ja sein, dass dir die eristische dialektik nach schopenhauer sehr nahe steht und du auch ein guter php-programmierer bist.
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
OMG - paulchens Bullsh.. kommentiere ich gleich noch *kopfschüttel*
In Foren sind nun mal oft Laien unterwegs auf der Suche nach Hilfe und bekommen dann solchen bullsh... präsentiert und nehmen es wahrscheinlich noch für "bare Münze". Dabei gilt, wenn man keine Ahnung hat...
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.
klar, user und programmierer stellen das höchste risiko dar, denn letztendlich haben diese nicht nur das script geschrieben/entworfen bzw. genutzt, sondern auch ALLES was damit zusammenhängt - nebst php, dem os, den peripheren firmwares und den anderen 1000 dingen, welche da noch dran hängen.
damit möchte ich den programmierern diesen shopsystems überhaupt nicht unterstellen, dass ihnen sachkenntnis fehlt - allzumal ich mich nicht in der lage befinde dieses auch wirklich einschätzen zu können. ich finde, dass seo-commerce wirklich eine tolle leistung darstellt. es können jedoch fehler passieren und das ist völlig normal.
letzten endes kann die ursache dieses themas auch eine ganz andere sein
zuallererst würde ich um einen gepflegten umgangston bitten
mit "server" meinte ich seinen http-server, welcher auch immer da läuft, vermutlich der apache.
noch besser wäre in der tat ein server-halt und dann per remote-konsole, falls vorhanden, auf den rechner zugreifen. es könnte durchaus sein, dass der server komplett kompromittiert wurde. dann ist recherche am laufenden system fix für die katz.
das backup zieht man aus forensischen gründen (fehleranalyse offline). ansonsten läuft man gefahr, dass das gleiche wieder passiert.
es ist in dem fall irrelevant, ob php genau so kritisch ist wie andere sprachen, da auf seinem server definitiv php läuft.
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.
ob programmierer, anwender oder sonstwer der grund für dieses risiko sind, interessiert den threadstarter in diesem moment vielleicht eher weniger.
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. wenn nicht, loggt sich auch der admin unverschlüsselt ein.
ftp ist ein unsicheres und unverschlüsseltes protokoll, d.h. zugriffskennungen werden unverschlüsselt übertragen. die momentan beste "alternative" wäre ssh bzw. sftp (am besten noch mit auth-key).
ja. ich ging davon aus, dass er einen root-server unterhält.
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.
aus diesem grund halte ich deine tipps für streng fahrlässig.
ich möchte mich hier nicht profilieren, sondern einzig dem threadstarter helfen.
ist (hoffentlich) kein root-server vorhanden, gilt oben geschriebenes natürlich nicht. dann bleibt nur backup und neuaufsetzen des shops mit neuen zugangsdaten.
ich, an deiner stelle, würde wie folgt vorgehen:
server abschalten.
backup ziehen.
jemanden hinzuziehen, der sich mit serversicherheit auskennt.
jeden tag werden mehr server gehackt, als man sich vorstellen kann.
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.
darüber hinaus sind folgende anwendungen/szenarieren im prinzip auch nicht mehr tragbar - gleich gar nicht, wenn man mit kundendaten hantiert:
- fehlender apache-ssl
- ftp
- schwache passwörter
dann dürfte der fehler ja schnell auszumachen sein, oder?
was ist denn an der plus-version in dieser beziehung so anders?
in 2.0.7 hat sich nix geändert. Davon war ja in der Beschreibung auch nicht die Rede. In Eurem Demo-Shop kann ich auch keine Cloud entdecken
So. Habe das Ganze nochmal abgecheckt:
Wenn ich einen Artikel frisch anlege, und die Tags für die Cloud einfüge, so erscheinen diese NIRGENDWO in der Datenbank. Eigentlich müssten sie in der products_description stehen, wo sie jedoch mit NULL glänzen.
Der Rest wieder wie oben beschrieben: manueller Eintrag in DB -> englisch geht, deutsch nicht (was eh erstmal im Einzelfall irrelevant ist, da die Tag-Cloud im deutschen Interface nie erscheint)
unter xt-Commerce nennt sich das entsprechende Modul "Options- und Freitextmodul für Veyton 4.0", welches ich aus 3 Gründen für extrem sinnvoll halte:
- rationeller: das Produkt muss nicht x-mal angelegt werden, beim editieren genauso (ich mache das jetzt für jedes Produkt satte 4 mal und habe nun statt 60 Artikeln 240)
- Vermeidung von duplicate content, was seo-technisch sehr wichtig sein dürfte
- zu guter Letzt wird das Ganze im Frontend bedeutend übersichtlicher für den Kunden, um welchen es ja letztendlich geht
Das ist die aktuellste Version 2.06.
Die Tag-Cloud funktioniert leider nicht mal bei manuellem Eintrag in die DB - nur in englischer Sprache, da tut sie's.
Wenn ich einen Artikel in deutsch editiere, erscheinen auch nicht die Tag-Clouds im Edit-Fenster, welche bereits in die Datenbank eingetragen wurden.
Jegliche Ein- und Ausgaben, die Tag-Cloud in deutscher Sprache betreffend, versickern im Nirwana. In englisch gehts.
