nicht angemeldet
Link mit Übergabe von User/Passwort
Hallo!
Ich bräuchte die Syntax für einen einfachen Link, in dem ein feststehender Useraccount mit Passwort eingebunden werden soll.
In diesem Fall ist das Passwort überflüssig, da sich die Site in einer CUG eines Intranets befindet und diese bereits PW-geschützt ist... Alle Benutzer müssen allerdings direkten Zugang zu dem o.g. Link haben.
Wer kann mir helfen?
Gruß
thorstenman
-
Moin!
Ich bräuchte die Syntax für einen einfachen Link, in dem ein feststehender Useraccount mit Passwort eingebunden werden soll.
http://user:pass@domain.de ;-)
Wer kann mir helfen?
HTH
Einbecker-
Moin auch,
dreimal darfst du raten, warum das nicht geparst wird... (hint: RFC 1738 ;-)
HTHT &
Viele Gruesse,
n.d.p.
-
Moin
dreimal darfst du raten, warum das nicht geparst wird... (hint: RFC 1738 ;-)
Aber telnet://user:password@host.de> ist erlaubt, oder?
Viele Grüße
Swen
-
-
Moin auch,
dito
dreimal darfst du raten, warum das nicht geparst wird... (hint: RFC 1738 ;-)
Der Hint war ja fast zu einfach:
"No user name or password is allowed" im Abschnitt 3.3 "HTTP". Hmm... sehr merkwuerdig.. wie sieht den ein URL aus, die der Browser anfordert, wenn man beispielsweise im Apache eine .htaccess anlegt? Ist das dann nicht RFC-konform?Und: Warum ist im Abschnitt 3.1 ein "Common Scheme" definiert, dass so aussieht:
//<user>:<password>@<host>:<port>/<url-path>
Wieso braucht http soetwas nicht? Auch hypertext sollte IMHO passwortgeschuetzt werden... (natuerlich, man kann einen RFC-konformen FTP:-link bauen, aber wieso?)Aber: Respekt an Euch, ein RFC-Konformes Forum zu bauen ;-)
Und: Kann mir mal einer Erklaeren, warum bei mir nach installation der Windows-Truetypes in KDE Courier
- mit doppeltem Zeilenabstand und
- mit Fragezeichen und Anfuehrungszeichen vertauscht auftritt?
(ja, ich weiss: OT ;-) - aber es sieht schon komisch aus...)
HTHT &
Jo, danke!
Viele Gruesse,
Auch an dich,
Einbecker
-
Hallo Einbecker,
"No user name or password is allowed" im Abschnitt 3.3 "HTTP". Hmm... sehr merkwuerdig.. wie sieht den ein URL aus, die der Browser anfordert, wenn man beispielsweise im Apache eine .htaccess anlegt? Ist das dann nicht RFC-konform?
imho wird da die Authentifizierung einzeln rübergeschickt, aber auf
keinen Fall in der genannten Form. Dafür gibt es versch. Gründe,
z.Bsp. Referrer, Browserhistory etc., wo dann der Benutzername und
das Passwort sichtbar wären.Und: Warum ist im Abschnitt 3.1 ein "Common Scheme" definiert, dass so aussieht:
//<user>:<password>@<host>:<port>/<url-path>Ja, in Abschnitt 3.1 wird die Syntax für die versch. Protokolle fest-
gelegt, welche in 3. genannt wurden. In den nachfolgenden Abschnitten
wird es genauer für _einzelne_ Protokolle spezifiziert, in 3.3 z.Bsp.
für http.
BTW, 'prospero' (Prospero Directory Service) habe ich eben zum ersten
Mal gehört, kann man sich so etwas irgendwo live anschauen?Wieso braucht http soetwas nicht? Auch hypertext sollte IMHO passwortgeschuetzt werden... (natuerlich, man kann einen RFC-konformen FTP:-link bauen, aber wieso?)
Natürlich besitzt http Möglichkeiten zum Passwortschutz, aber Links
mit eingebauten Passwörtern darf es bei http nicht geben, zwei mög-
liche Gründe habe ich oben genannt.Aber: Respekt an Euch, ein RFC-Konformes Forum zu bauen ;-)
Ich habe mich darüber auch sehr gefreut, weil ich zu diesem Thema
vor einigen Monaten eine lebhafte Diskussion mit Strato geführt habe.
Es ging um die Einführung dieser unseeligen @-Domains, bei denen ja
praktisch der Benutzer mit in den URL eingebaut wird:
http://bloedsinn@strato.de/ (hoffentlich nicht anklickbar)
Strato stützt sich in der Argumentation auf ein neueres RFC, wo eben
wieder allgemein für alle Protokolle das Syntaxschema festgelegt ist,
leider wurde aber darin nicht noch einmal speziell die http-Syntax
festgelegt :(
Die Nummer habe ich jetzt nicht zur Hand, aber die Sache ist damals
auch ziemlich ausführlich im Heise-Newsticker gewesen ;)
Bei der Strato-Konkurrenz bietet man mittlerweile dieses Feature ge-
zwungenermassen auch an, allerdings fehlen dort, im Gegensatz zu den
"Erfindern" bei Strato, nicht deutliche Hinweise, dass diese Art von
URL´s nicht gültig sind und die Umsetzung (JavaScript!) nicht immer
funktioniert: http://faq.puretec.de/tools_features/atdomains/3.html
Aber bei PureTec gibt es ja auch richtige Subdomains, so dass man auf
solche Krücken eigentlich nicht angewiesen ist.
Richtige Subdomains wiederum kann Strato nicht so ohne weiteres ein-
richten, da sie keinen eigenen Nameserver für ihre de-Domain haben ;)Viele Grüße aus Dresden,
Stefan Einspender-
Moin Stefan!
"No user name or password is allowed" im Abschnitt 3.3 "HTTP". Hmm... sehr merkwuerdig.. wie sieht den ein URL aus, die der Browser anfordert, wenn man beispielsweise im Apache eine .htaccess anlegt? Ist das dann nicht RFC-konform?
imho wird da die Authentifizierung einzeln rübergeschickt, aber auf
keinen Fall in der genannten Form. Dafür gibt es versch. Gründe,
z.Bsp. Referrer, Browserhistory etc., wo dann der Benutzername und
das Passwort sichtbar wären...hmm... Ist das bei den anderen Protokollen nicht so? Gut, einen Referrer gibt es nicht, aber in der Browserhistory finden sich auch die FTP-Seiten drin. Und dann kann man das Passwort auch auslesen. Meine Frage ist natuerlich, ob man nicht trotzdem ein <a href="http://user:pass@domain:port"> in seine Seiten einbauen kann und ob es funktioniert.
Gerade fuer den hier geschilderten Fall faende ich es sinnvoll, dass es funktioniert. Gut, es ist nicht RFC-konform, aber das ist IMHO in diesem Fall verschmerzbar. Leider kann ich es nicht selbst ausprobieren, da ich im Moment nirgendwo Passwortschutz a la .htaccess habe und es jetzt auf die schnelle nicht einrichten will. Also: Frage an dich/euch: Funzt es auch so?
Und: Warum ist im Abschnitt 3.1 ein "Common Scheme" definiert, dass so aussieht:
//<user>:<password>@<host>:<port>/<url-path>Ja, in Abschnitt 3.1 wird die Syntax für die versch. Protokolle fest-
gelegt, welche in 3. genannt wurden. In den nachfolgenden Abschnitten
wird es genauer für _einzelne_ Protokolle spezifiziert, in 3.3 z.Bsp.
für http.Ist mir schon klar, dass es ein allgemeiner Syntax ist. Ich verstehe das aber andersherum: Der allgemeine Syntax sollte so ausschauen: //<host>:<port>/<url-path>. Für spezielle Protokolle, die mehr unterstuetzen, sollte es dann (IMHO) ergaenzt werden. Also nicht "hinschreiben und dann streichen" sondern "weglassen und nur erwaehnen, wenn es Sinn macht". Das haette auch Strato gezeigt, wo der Hase langlaeuft.
BTW, 'prospero' (Prospero Directory Service) habe ich eben zum ersten
Mal gehört, kann man sich so etwas irgendwo live anschauen?.. hat mich auch gewundert. Aber ueber "file:" wunderte ich mich auch ein wenig. Ich kenne es zwar (Konqueror zeigt es in lokalen Verzeichnissen immer an), aber wird damit auch irgendetwas uebers Internet uebertragen?
Wieso braucht http soetwas nicht? Auch hypertext sollte IMHO passwortgeschuetzt werden... (natuerlich, man kann einen RFC-konformen FTP:-link bauen, aber wieso?)
Natürlich besitzt http Möglichkeiten zum Passwortschutz, aber Links
mit eingebauten Passwörtern darf es bei http nicht geben, zwei mög-
liche Gründe habe ich oben genannt.Und ich meine, dass es die schon geben darf ;-) Und zum Refferrer ist zu sagen, dass der Ersteller der Seiten darauf achten sollte, worauf er linkt, und gegebenenfalls eine "De-Refferer"-Seite (wie GMX) einbaut. Also: Was hast Du noch an Argumenten? :-P
Viele Gruesse,
Einbecker
-
Moin,
"No user name or password is allowed" im Abschnitt 3.3 "HTTP". Hmm... sehr merkwuerdig.. wie sieht den ein URL aus, die der Browser anfordert, wenn man beispielsweise im Apache eine .htaccess anlegt? Ist das dann nicht RFC-konform?
also, hier mal kurz der Authentifizierungsmechanismus von HTTP (also Dialog zwischen Browser und Server):
Beispiel: http://www.o3media.de/test/* Browser: Hallo, ich bin der ***-Browser, ich moechte auf den Host 'www.o3media.de' zugreifen und gerne den URL '/test/' haben.
[
GET /test/ HTTP/x.y
Host: www.o3media.de
Useragent: ***-Browser ;-)
]* Server: Tach, ich bin der Apache 1.3.** und bevor du /test/ haben kannst, musst du erstmal zeigen, dass zu fuer den Bereich "Testarea" berechtigt bist
[
Status: 401 Authorization required
WWW-Authenticate: Basic realm="Testarea";
Server: Apache 1.3....
]* Browser: Hallo, ich bin der ***-Browser, ich moechte auf den Host 'www.o3media.de' zugreifen und gerne den URL '/test/' haben. Ich kann mich soundso (hier test:test, d.Red.) ausweisen
[
GET /test/ HTTP/x.y
Host: www.o3media.de
Authorization: Basic dGVzdDp0ZXN0
Useragent: ***-Browser
]* Server: Hi, ich bin der Apache soundso, aha, User/PW stimmen - hier hast du /test/
(nachzulesen in RFC 2617), die Digest-Variante ist noch etwas komplizierter ;)
also schoen: gebe ich xy:za@www.host.de an, dann bekomme ich das Hypertextdokument - was ist mit den Bilder und weiteren Links (aller derselbe Username/Passwort??)
Neenee, das passt vorne und hinten nicht.Uebrigens haelt sich mein Proxy an die RFCs und gibt bei user:passwort-(HTTP)-URLs auf.
Wieso braucht http soetwas nicht? Auch hypertext sollte IMHO passwortgeschuetzt werden... (natuerlich, man kann einen RFC-konformen FTP:-link bauen, aber wieso?)
nicht, dass er passwortgeschuetzt waere bei so einem Link...
Ist mir schon klar, dass es ein allgemeiner Syntax ist. Ich verstehe das aber andersherum: Der allgemeine Syntax sollte so ausschauen: //<host>:<port>/<url-path>. Für spezielle Protokolle, die mehr unterstuetzen, sollte es dann (IMHO) ergaenzt werden. Also nicht "hinschreiben und dann streichen" sondern "weglassen und nur erwaehnen, wenn es Sinn macht".
nein. Es geht dort um URLs allgemein. Mit dem ersten Wissen kann ich also sagen, wie ein generische URL-Schema aussieht. Mit den Spezifikationen der einzelnen Schemes wird das generische Schema genommen und eingeschraenkt. Glaub mir, das soll so ;)
Das haette auch Strato gezeigt, wo der Hase langlaeuft.
Strato beruft sich auf RFC 2396, obwohl ich nicht verstehe, was daran nicht eindeutig ist:
| This document updates and merges "Uniform Resource Locators"
| [RFC1738] and "Relative Uniform Resource Locators" [RFC1808] in order
| to define a single, generic syntax for all URI. It excludes those
| portions of RFC 1738 that defined the specific syntax of individual
| URL schemes; [...]'It excludes' klingt fuer mich *sehr* eindeutig.
Natürlich besitzt http Möglichkeiten zum Passwortschutz, aber Links
mit eingebauten Passwörtern darf es bei http nicht geben, zwei mög-
liche Gründe habe ich oben genannt.
Und ich meine, dass es die schon geben darf ;-)schreib halt n RFC dafuer ;)
Viele Gruesse,
n.d.p.
-
-
-
-
-
Hi!
Schau mal unter
http://www.teamone.de/selfaktuell/forum/?m=126876&t=24373könnte auch für Deine Frage interessant sein. Und auch die Antworten in deisem Therad passen zu der Problematik oben.