Return-Path: Delivered-To: apmail-httpd-users-de-archive@www.apache.org Received: (qmail 59239 invoked from network); 9 Mar 2005 08:21:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 9 Mar 2005 08:21:22 -0000 Received: (qmail 32423 invoked by uid 500); 9 Mar 2005 08:21:20 -0000 Delivered-To: apmail-httpd-users-de-archive@httpd.apache.org Received: (qmail 32398 invoked by uid 500); 9 Mar 2005 08:21:20 -0000 Mailing-List: contact users-de-help@httpd.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: users-de@httpd.apache.org Delivered-To: mailing list users-de@httpd.apache.org Received: (qmail 32383 invoked by uid 99); 9 Mar 2005 08:21:20 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from relay2.fiz-karlsruhe.de (HELO relay2.fiz-karlsruhe.de) (141.66.18.148) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 09 Mar 2005 00:21:17 -0800 Received: from a27swork.fiz-karlsruhe.de (141.66.16.39) by relay2.fiz-karlsruhe.de with ESMTP; 09 Mar 2005 09:22:07 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-Ironport-AV: i="3.90,149,1107730800"; d="scan'208"; a="597864:sNHT16291048" Received: from pc.fiz-karlsruhe.de (pc.fiz-karlsruhe.de [141.66.16.9]) by A27swork.fiz-karlsruhe.de (8.12.11/8.12.11) with ESMTP id j298LCoT007962 for ; Wed, 9 Mar 2005 09:21:12 +0100 (MET) Received: by pc.fiz-karlsruhe.de with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Mar 2005 09:16:50 +0100 Message-ID: <41EA24EC431CD411AA8200008385014F0740D47E@pc.fiz-karlsruhe.de> From: "Lenz, Steffen" To: "'users-de@httpd.apache.org'" Subject: AW: AW: AW: LDAP-Auth. auf mehreren Apache-Servern ->Single Sign- On Date: Wed, 9 Mar 2005 09:16:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N hi, zun=E4chst mal vielen Dank! Aber irgendwie hat mir die Diskussion um = die Cookies nicht wirklich weitergeholfen. Sollte meine gew=FCnschte Funktion mit Cookies l=F6sbar sein, dann nehm = ich doch aber an, wenn ihr von PHP-Funktionen redet, da=DF ich ohne = Programmierung nicht weiterkomme. Ist das richtig? Ich habe zun=E4chst gehofft, da=DF ich mit dem selben "AuthName" das = mehrmalige Prompten der Passwortabfrage verhindern kann. Scheinbar geht das aber = nur innerhalb eines Hosts: "Therefore, you can prevent a user from being prompted more than once = for a password by letting multiple restricted areas share the same realm. Of course, for security reasons, the client will always need to ask again = for the password whenever the hostname of the server changes." Kann irgendjemand bez=FCglich der Cookies eine gesicherte Aussage = treffen und mir vielleicht auch mit Beispielen weiterhelfen oder einen anderen L=F6sungsvorschlag unterbreiten? Im Vorraus besten Dank, Gru=DF Steffen Lenz > -----Urspr=FCngliche Nachricht----- > Von: Erik Abele [mailto:erik@codefaktor.de] > Gesendet am: Montag, 7. M=E4rz 2005 14:05 > An: users-de@httpd.apache.org > Betreff: Re: AW: AW: LDAP-Auth. auf mehreren Apache-Servern ->Single > Sign-On >=20 > On 07.03.2005, at 13:52, Dieter Soost wrote: >=20 > > Hallo, > > > >>> Cookies werden nur vom Netz zum PC "gesendet", nicht=20 > zur=FCck. Zur=FCck > >>> zum Netz > >>> (Server) kommen sie durch "Abfrage". > >>> > >>> D.h., der Server "fragt" den PC, ob er einen bestimmten=20 > Cookie hat. > >> > >> Na das w=E4re ab =E4usserst unpraktisch bzgl. Sicherheit - da=20 > k=F6nnte ein > > > > Genau deshalb wird ja immer vor diesen "harmlosen" Keksen = gewarnt... >=20 > Nein, das hat andere (aber =E4hnliche) Gr=FCnde. >=20 > >> Webmaster ja einfach alle Cookies seiner Nutzer auslesen (bzw. > >> 'Abfragen' wie Du es nennst) und die dazu verwenden um sich auf = den > >> entspr. Seiten zu authentifizieren... hmmm... da solltest Du mal > > > > Ne ne, so einfach ist das nun auch wieder nicht. Man kann=20 > die Dinger=20 > > n=E4mlich > > auch verschl=FCsseln, was jeder macht, schon dehalb, damit=20 > der User nicht > > sieht, was da drin steht... >=20 > Haha, ist doch mir egal was da drinsteht, wenn die 'verschl=FCsselte' = > Cookie-Version vom Server akzeptiert wird und genau das macht was sie = > soll. Ich denke das ist Augenwischerei mit der Verschl=FCsselung... >=20 > > Btw: Hast Du noch nie einen "sextrackercom" Cookie auf der Platte=20 > > gehabt ? > > Dazu musst Du nicht mal die Seiten besuchen, die der Name=20 > suggeriert... >=20 > Naja, es kann ja ein bel. Cookie vom einem Server 'gesetzt'=20 > werden aber=20 > eben nicht ausgelesen/abgefragt - du bekommst da momentan ganz=20 > eindeutig was durcheinander. >=20 > >> gr=FCndlich dr=FCber nachdenken. > > > > Ich habe dr=FCber nachgedacht ;-) >=20 > Scheint mir nicht so, sorry :( >=20 > > Deswegen werden von meinem System grunds=E4tzlich Cookies=20 > abgelehnt. Ok,=20 > > das > > schr=E4nkt meine Surf-M=F6glichkeiten nat=FCrlich ein, aber "Trau=20 > - Schau-=20 > > Wem" > > :-) > > > >>> Schau mal ins PHP-Manual: "GetCookie", ist einer der Befehle. > >> > >> Lt. = http://www.php.net/manual-lookup.php?pattern=3DGetCookie&lang=3Dde=20 > >> gibt > >> es keinen 'Befehl' mit diesem Namen; > > > > Sorry, dann heist wohl so meine selbstdefinierte Funktion=20 > im include=20 > > so. > > M=FCsste ich mal nachschauen, wie genau die Funktion heisst,=20 > ist schon=20 > > Jahre > > her (Wenn includes fertig sind und funktionieren, sehe ich da nie=20 > > wieder > > rein). > > > > Aber ok, wird langsam OT das Thema... :-) >=20 > Ok, das ist tats=E4chlich OT aber wie sieht es denn dann mit den=20 > verwendeten HTTP-Headern aus? Was macht denn Deine selbstdefinierte=20 > Funktion in dieser Richtung? Gibt es bei Dir etwa einen=20 > Get-Cookie-Header mit dem der Server den Client zur=20 > =DCbermittlung eines=20 > Cookies veranlasst? Und wann macht das der Client dann? Bei der=20 > n=E4chsten Verbindung? Oder ist bei Deiner Theorie in diesem=20 > Fall gar der=20 > Server der Client? >=20 > Naja, no comment... >=20 > Cheers, > Erik >=20 -------------------------------------------------------------------------- Apache HTTP Server Mailing List "users-de" unsubscribe-Anfragen an users-de-unsubscribe@httpd.apache.org sonstige Anfragen an users-de-help@httpd.apache.org --------------------------------------------------------------------------