perl: curl sendet basic anstatt ntlm

D

dsx12

Ich will mit Perl eine Datei von einem Server hohlen, auf welchem ich mich mit NTLM authentifizieren muss.
Mit tcpdump habe ich aber herausgefunden, dass Curl/Perl immer einen HTTP-Basic-Authentication-Header sendet.
Weiss jemand was das Problem seinen könnte.
Code:
#!/usr/bin/perl

open(TMPF, ">", "tempfile");
print "User: ";
chomp($user = <STDIN>);
if (system("stty -echo") == 0){
                print "Password: ";
                chomp($pw = <STDIN>);
}else{
                print "stty -echo failed";
                exit 1;
}
system("stty echo");

use WWW::Curl::Easy;
my $curl = WWW::Curl::Easy->new;
$curl->setopt(CURLOPT_URL,'http://my_scure_ntlm_server.de/securedoument.txt');
$curl->setopt(CURLOPT_FOLLOWLOCATION,1);
$curl->setopt(CURLOPT_UNRESTRICTED_AUTH,1);
$curl->setopt(CURLOPT_HTTPAUTH,CURLAUTH_NTLM);
$curl->setopt(CURLOPT_USERPWD,$user . ':' . $pw);
$curl->setopt(CURLOPT_FILE,TMPF);
my $retcode = $curl->perform;
close(TMPF);
 
Hi,

bei mir tut dein Skript was es soll, jedenfalls in so weit als dass der richtige Header gesendet wird. Vielleicht ein Bug in deiner spezifischen Version?

MfG,
bytepool
 
Ich habe im verbose Mode noch folgenden Fehler entdeckt.
Code:
$curl->setopt(CURLOPT_VERBOSE,1);
Code:
gss_init_sec_context() failed: : Credentials cache file '/tmp/krb5cc_1000' not found< WWW-Authenticate: Negotiate
Wie kann ich sehen, welche Version von libcurl perl verwendet? (Welche Version hast du?)
Code:
curl --version
curl 7.21.0 (i486-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6
Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
 
Hej,

Code:
$ curl --version
curl 7.21.3 (x86_64-pc-linux-gnu) libcurl/7.21.3 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

Den Fehler krieg ich in der Tat nicht, aber das ist eine Kerberos Datei und sollte eigentlich nichts mit NTLM zu tun haben. Ich hab Kerberos auf dem Lappi in Betrieb, ich wuerde vermuten dass ich deswegen den Fehler nicht kriege.

Aber eventuell hast du dieses Problem hier:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/675974

7.21.0 scheint in der Tat einen NTLM bug zu haben. Ich wuerd sagen versuch einfach Mal eine aeltere oder neuere Version.

MfG,
bytepool
 
Was aber sehr kommisch ist, dass ich auf dem gleichen Rechner ein PHP-Script habe das genau die glieche Funktion ausführt und dieses geht.
Wie kann ich überprüfen welche libcurl version PHP und Perl verwenden?
PHP habe ich mal so geschaut.
Code:
ldd curl.so
Wie greift eigentlich Perl auf die libcurl zu? Wo kann ich bei Perl den zusammenhang sehen?
 
Hej,

ich denke dass deine letzten Fragen ein wenig distributionsabhaengig sind.

Unter Ubuntu werden die curl bindings vom Paket libwww-curl-perl gestellt. Was im Vergleich zu den PHP bindings allerdings auffaellt, ist dass perl vom Paket libcurl3-gnutls abhaengt, waehrend PHP libcurl3 benutzt, also die OpenSSL Version.
Wie gesagt, die Details sind wohl distributionsspezifisch.


EDIT:
Hehe, ich sehe gerade dass die Anzeige von "curl --version" ein wenig unsinnig ist, das ist natuerlich ein eigenstaendiges Programm.

Aber ich wuerde vermuten dass auch bei dir das Modul unter /usr/lib/perl5/WWW/Curl.pm liegt. Dort sieht man dass die gleichnamige C library mit XSLoad geladen wird, die in meinem Fall unter /usr/lib/perl5/auto/WWW/Curl/Curl.so liegt. Lasse ich da ein ldd drauf los, sehe ich dass dort /usr/lib/libcurl-gnutls.so.4 verwendet wird, was wiederum ein symlink auf libcurl-gnutls.so.4.2.0 ist.

Hui, das ist unter Ubuntu aber ein Chaos mit dem packaging der Curl lib, Paket libcurl3 installiert libcurl3.so _und_ libcurl4.so und conflicts mit dem virtuellen Paket libcurl4... Ein gutes Beispiel dafuer wie man's nicht machen sollte. ;)

Anyway, der Paketmanager deiner Wahl sollte dir beim herausfinden der Version behilflich sein. ;)

MfG,
bytepool
 
Zuletzt bearbeitet:
Danke schon mal für die Hilfe.
Ich verwende Debian. Die curl bindings habe ich ebenfalls über das Paket libwww-curl-perl installiert.
Bei mir zeigen beide curl.so, also das von PHP und das von Perl, auf /usr/lib/libcurl-gnutls.so.4.2.0.
Somit scheint der Fehler nicht bei der libcurl zu sein. Oder bin ich da falsch?
Sonst noch ein Tipp an was es liegen könnte?
Von wem wird eigentlich die Datei /usr/lib/perl5/auto/WWW/Curl/Curl.so erstellt? Vom libcurl-Projekt oder vom entsprechenden Perl-Modul?
 
Hej,

Bei mir zeigen beide curl.so, also das von PHP und das von Perl, auf /usr/lib/libcurl-gnutls.so.4.2.0.
Somit scheint der Fehler nicht bei der libcurl zu sein. Oder bin ich da falsch?
Die Vermutung liegt nahe, ja. Allerdings kenn ich mit mit libraries auch nur bedingt aus, es kommt mir schon ein wenig komisch vor dass die Version der lib 4.2.0 zu sein scheint, das Paket allerdings die Versionen 7.21.0 und 7.21.3 traegt. Auf der Webseite vom Curl Projekt werden die letzteren Versionsnummern benutzt.
Im Allgemeinen ist es ja so dass die Mikro Version, also die dritte Zahl, angibt ob sich an der Implementierung was geaendert hat, ohne dass sich das Interface geaendert hat, z.B. bugfixes. Von daher wuerde ich schon davon ausgehen dass die Versionen 7.21.0 und 7.21.3 anders sind, auch wenn aus irgendeinem Grund der Dateiname auf dem Debian System nicht angepasst wird. Da muesste man sich wahrscheinlich mal tiefer einlesen, wuerde mich eigentlich schon interessieren...


Wie man mit "dpkg -S /usr/lib/perl5/auto/WWW/Curl/Curl.so" sehen kann kommt die Datei vom libwww-curl-perl Paket.

Aber wahrscheinlich macht es mehr Sinn das eigentliche Problem nochmal unter die Lupe zu nehmen, statt die Pakete auseinander zu nehmen. Im Augenblick weisst du ja noch nicht mal genau wo es schief laeuft:

  • Z.B. mal versuchen zu einem anderen Server zu verbinden.
  • Nochmal gucken ob du die Ausgabe von tcpdump richtig interpretiert hast, und dich nicht ausversehen verlesen hast, z.B. mit wireshark.
  • Eine andere libcurl-gnutls Version versuchen, oder eine andere Version von libwww-curl-perl.
Damit du wenigstens eine Idee bekommst an welcher Stelle es falsch laeuft.

Da dein Code bei mir funktioniert wuerde ich jedenfalls davon ausgehen dass er korrekt ist. Ich hab allerdings auch keinen Server mit NTLM zur Verfuegung, ich hab's einfach getestet in dem ich zu einem beliebigen Server eine Verbindung aufgebaut hab. Aber das sollte ja egal sein, denn der Header wird so oder so gesendet, und wenn ich NTLM in Basic aendere aendert sich auch die Anfrage entsprechend.

Ansonsten hab ich auch keine Ideen mehr, nee.

MfG,
bytepool
 
bugs in WWW::Curl

Der Fehler liegt am Perlmodul WWW::Curl welches bei Debian im Paket libwww-curl-perl in der Version 4.12 vorliegt. Diese Version hat Fehler beim Übernehmen der LIBCURLKonstanten (z.B. CURLAUTH_NTLM) auf die Perlseite.
Hier ist das Changelog des Moduls. Dort könnt Ihr sehen, dass in den letzten Versionen immer wieder das "constant handling" verbessert wurde.
http://cpansearch.perl.org/src/SZBALINT/WWW-Curl-4.15/Changes
 

Ähnliche Themen

Squid nur zum maskieren der eigenen IP, nicht für Webserver auf port 80

Zurück
Oben