|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
Von Anonymer Feigling am Monday 02. February, 11:48 MET (#1)
|
|
|
|
|
Verbannt doch gleiche alle Buchstaben und Zahlen auf dieser Welt und führt ein Microsoft-Alphabet ein, dann gibt es bestimmt kein URL-Spoofing mehr
|
|
|
|
|
|
|
|
|
|
|
|
|
Das Produkt @Domain zu nennen war suchmaschinentechnnisch wirklich ein Griff ins Klo, es sieht so aus, als ob z.B. Google das "@" einfach wegwirft. Ebenso die ger verwendete Auflösung des "eigentlichen" Namens per Javascript...
P.S. Es ist tatsächlich ein Er und heißt auch nicht Klaus Bärbel
|
|
|
|
|
|
|
|
|
|
|
|
|
Was ist mit Links zu FTP-Servern in der Form ftp://username:passwort@hostname.domain? Das ist in einigen Versionen von MSIE die einzige Möglichkeit, authentifiziertes FTP zu betreiben.
Man mag nach dem Sinn einer solchen Sache fragen (ist es überhaupt in den URI RFCs standardisiert?), aber in manchen Fällen ist es die optimale Lösung eines Problems.
Nur weil ein DAU aus dem eigenen Kundenkreis öfters zwei grössere Dateien aus einem Daten-Pool runterladen muss, kann man ihm ja keinen FTP-Client aufzwingen (den könnte er ohnehin nicht bedienen). Dann war eine nette URL im obigen Format direkt vom Intranet zum FTP-Server eigentlich immer sehr praktisch.
Oder wird sowas dann von Microsoft als "Funktionalität für Hacker und andere Illegale" abgetan und als "für den ernsthaften Computer-Benutzer nicht nötig" tituliert? Juhuu.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
War das nicht auch ein "Produkt" von oben genannten Firmen? 1 Domain und 100 "Subdomains" vom Typ peter@familie.tld für 3,99 Euro?
Dann kann jedes Familienmitglied seine eigene Subdomain haben. Wurde auf Heise damals ziemlich zerissen, da das ja für User:password@domain.tld gedacht war.
Wenn Dir jemand peter.maier@domain.tld sagt. Ist das nun die eMailadresse oder die Subdomain?
Noch 4 mal schlafen, dann ist fast wieder Wochenende...
--
eat my .sig!
|
|
|
|
|
|
|
|
|
|
|
|
|
Keine Bange! Microsoft will Benutzernamen und Passworte nur in HTTP-Urls für ungültig erklären. In FTP-URLs wird es weiterhin funktionieren.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ehm, ich find das auch in http urls ziemlich nützlich!
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 06. February, 14:09 MET (#16)
|
|
|
|
|
ftp://me:xx@ftp.xxxx.xx
geht nach dem Patch auch nicht mehr :-(((
|
|
|
|
|
|
|
|
|
|
|
|
|
dieser Titel ist sehr treffend! nur glücklicherweise wird M$ in zwei Jahren schon 20 % Marktanteil an GNU/Linux verloren haben. Meine realistische Progrnose.
sorry ich will niemanden ärgern... wie würde dein Hirn aussehen nach Jahrzehnte langem Drogenmissbrauch?
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 02. February, 12:57 MET (#6)
|
|
|
|
|
user:password@host.tld is afaik RFC-konform...
An Standards haben die sich zwar noch nie gehalten, aber die können sowas doch ned einfach rauswerfen, nur weil sie nicht in der Lage sind, nen Patch zu schreiben...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Jemand der Outlook + OutlookExpress veröffentlicht kann alles!
--
eat my .sig!
|
|
|
|
|
|
|
|
|
|
|
|
|
Aus RFC 1738, chapter 3.3:
An HTTP URL takes the form:
http://<host>:<port>/<path>?<searchpart>
http://user:passwort@host/ war demnach zwar praktisch, aber nicht RFC-konform.
--
Addicted by code poetry...
|
|
|
|
|
|
|
|
|
|
|
|
|
Na ja, 2396 hat hier 1738 ersetzt, und trifft keine Aussagen mehr ueber HTTP im speziellen. Man kann jetzt natuerlich in die Http 1.1 schauen, wo zwar der @ nicht erwaehnt wird, aber im gegensatz zu 1738 auch nicht mehr gesagt wird es waehre verboten.
Ergo, @ ist zulaessig.
Gruss
H.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In Kapitel 3.1 steht:
> Some or all of the parts ":@", ":", ":", and "/" may be excluded.
Das "excluded" heisst für mich, dass, je nach Schema der URL (http, ftp, gopher, etc.) gewisse Teile nicht Bestandteil einer RFC-konformen URL sind. Dies ist im Einklang mit Kapitel 3.4, wo und nicht vorkommen.
Man könnte diesen Schritt also als Schritt zu einem "standard-konformen" Verhalten sehen...
|
|
|
|
|
|
|
|
|
|
|
|
|
äh, sorry, offenbar tut der Slashcode im Modus "guter alter Text" netterweise alles, was nach HTML-Tags aussieht (wie <user>), kommentarlos löschen...
Also hier nochmal:
In Kapitel 3.1 steht:
> Some or all of the parts "<user>:<password>@", ":<password>", ":<port>", and "/<url-path>" may be excluded.
Das "excluded" heisst für mich, dass, je nach Schema der URL (http, ftp, gopher, etc.) gewisse Teile nicht Bestandteil einer RFC-konformen URL sind. Dies ist im Einklang mit Kapitel 3.4, wo <user> und <password> nicht vorkommen.
Man könnte diesen Schritt also als Schritt zu einem "standard-konformen" Verhalten sehen...
|
|
|
|
|
|
|
|
|
|
|
|
|
Kinners ihr diskutiert auf basis einer Veralteten, nicht mehr gueltigen RFC - 2396 ist die aktuelle.
Gruss
H.
|
|
|
|
|
