Dein Klartext Passwort wird nie an netcup Server übermittelt.
remember, remember – fängst an erst im september!!! ![]()
Dein Klartext Passwort wird nie an netcup Server übermittelt.
remember, remember – fängst an erst im september!!! ![]()
Normalerweise wird es gesendet... anders wirds auch ziemlich kompliziert.
es ist eigentlich das gegenteil von kompliziert, wenn man sich auf die üblichen JS-komponenten verlassen will.
aber in der regel bringt es nicht wirklich vorteile, browserseitig vom client hashen zu lassen.
wichtig ist, den kram über TLS abzuwickeln.
außerdem zeigen übliche webseiten die passwortkomplexität ja nicht beim login, sondern beim »sign up« (in realtime dann via JS im client).
beim login-fail anzuzeigen, daß man für jenen benutzer 3 stellen nur mit nummern eingeben müsste, wäre sicher mehr als deppert.
ich selbst möchte ja hier auf entcup keine politischen diskussionen – das führt früher oder später *immer* zu schlechter luft.
du wirst hierzu von mir keine antwort hier im netcup-forum bekommen,
weil – regel eins: no politics.
und dazu brauche ich ja ein Webhostingpaket oder?
was ist der 46.38.243.234 für ein gerät?
mxtoolbox.com -> auswahl »teste email server«
mail-tester.com
checktls.com/TestReceiver
falls du linux benutzt, könnte ich dir einen befehl geben, um deine MX-zertifikate zu prüfen.
ansonsten sind beim webhosting mails immer verschlüsselt, weil netcup die mails auf vom webhosting getrennten maschinen hostet,
um die sich der nutzer nicht extra kümmern muss (ausser halt evtl. den MX-eintrag im DNS löschen [siehe #4]).
aber MET habe ich noch nie gelesen oder gehört. Ist das ein Übersetzungs-/Tippfehler oder verwendet man das wirklich irgendwo so?
Das heisst eigentlich METT und gilt als die Kölner Mittagspausenzone.
MET steht als Abkürzung für:
sehr schön.
Datei im Shopware-Root Ordner .env.local die APP_URL auf den Dokumentenroot anpassen.
jetzt wäre es noch ziemlich hilfreich, wenn du hier ein konkretes beispiel lieferst. siehe #26 (eben wie aus der offiziellen dokumentation).
die logs sind ab /logs und »subwärts« in /logs/X.com/ etc. ([dateimanager] -> WCP -> Dateien)
läuft bei dir https und steht dann in der .env die APP_URL mit https://X.com/ ?
nur um sicher zu gehen: in den PHP-settings auch log_errors auf on (3 unter open_basedir-setting)?
docroot ist /X.com/httpdocs/shopware6/public
zu #15: eben.
shopware sollte ja auch logs erzeugen. kannst du da mal was davon hier reinstellen?
ok. damit steht open_basedir jetzt korrekt auf webspaceroot.
hast du die bisherigen SW6-threads hier im forum schon durch?
es heisst ja stellenweise, daß der support einmal ran muss.
phpinfo Datei lässt sich abe rnoch problemlos öffnen
logisch. aber was steht denn jetzt unter core/open basedir?
Bei den PHP-Einstellungen habe ich auch mal versucht die open_basedir Einstellung anzupassen. Sprich auf die andere Einstellung mit WEBSPACEROOT auszuwählen, 10 Minuten gewartet aber trotzdem ohne Erfolg.
mach das bitte nochmal und teste dann via phpinfo() (link ist weiter oben auf der PHP-settings-seite / Die phpinfo() Seite ansehen)
die änderung kann m.E. evtl. auch länger als 10 minuten dauern.
ich habe selbst *kein* SW6 hier laufen.
evtl. liest jemand mit installiertem SW6 mit und kann sagen, ob die env.local ebenfalls an den webspaceroot-pfad angepasst werden muss (was ich sehr vermute).
edit: die app_url der env.local soll wohl einfach die URL sein.
im falle von dokumentenstammdir auf …/public also einfach http(s)://deine.domain.tld
ich bin vor geraumer zeit beim durchsuchen der issues (was man halt so macht in seiner freizeit) draufgestossen.
das was in den discussions angesprochen wurde (löschen sämtlicher bezüge zum rustdesk-original) reicht mir dann schon als grund,
um sowas auf die blacklist zu setzen.
und auch schon wieder runter.
(sowas sollte man wirklich immer screenshotten)
ja, ist korrekt -> https://www.spamcop.net/w3m?action=che…ip=40.107.21.58
(halbwissen ohne datum ist noch nicht mal viertelwissen und darauf sollte man sich auch nicht verlassen)
dieses startete dem Vernehmen nach als Soft-Fork von RustDesk
es gibt auch diesbzgl. genügend infos in issues/discussions auf rustdesks github.
bei uns ist die nutzung von hoptodesk jedenfalls nicht erlaubt.
falls man in betracht zieht, DNS »woanders« hosten zu lassen, könnte man zu einen provider mit entsprechender »alias« oder »cname flattening« – funktionalität wechseln.