Domino 9 und frühere Versionen > ND6: Entwicklung

Kann man Webformular per Agent ausfüllen?

<< < (3/3)

Mark³:
dieses Beispiel gibt mir das gute Gefühl, dass es heutzutage egal ist, in welcher Sprache man programmiert.
Der Javacode ist dem Skript-Code von mir recht ähnlich, auch in .NET ist es fast identisch zu machen.
 O0

flaite:
Ich hab heute morgen mit curl rumgehampelt. Ein php Skript vom Hersteller hat das benutzt.
http://curl.haxx.se/ (interessant. Eine Art http Kommandozeilen-Tool).
Mit diesem curl Befehl sendet man einen http-Post (!!) Request gegen einen Server auf SSL, mißachtet, dass man die CA nicht hat (-k) und authentifiziert sich gleichzeitig gegen den Server und im authentifizierenden Proxy in der Firma:

--- Code: ---
D:\toolsMS\curl-7.15.1>curl -U meinProxyUser:meinProxyKennwort -x derProxy:derPortVomProxy -m 120 -u derUserBeimServer:dasPasswortBeimServer -d "httpPostFeld1=Inahlt&httpPostFeld2=inhalt&httpPostFeld3=inhalt&httpPostFeld4=Inhalt" -k urlDerHttpPostAction
 
--- Ende Code ---
Bei mir hat sich genau die umgekehrte Effekt eingestellt. Warum gibt es für die gleiche Sache wie proxy-authentification so viele verschiedene Prozesse.

Z.B. muss man bei httpClient scheinbar

--- Code: ---client.getParams().setAuthenticationPreemptive(true); // WICHTIG!!!!

--- Ende Code ---
setzen.

Jetzt kommt das hier:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted certificate found

flaite:
Nur für die Komplettierung.
Wir hatten hier ja einige Threads, wo man mit Java (oder anderen Plattformen) Webseiten auslesen sollte.
Die SSL Geschichte on top war jetzt ein bischen nervig.
Es geht darum, dass der Client dem Server vertraut. Es geht nicht um Client Authentifizierung.
Eine einfache Sache, mag man denken.
In Java und in Browsern ist das so implementiert, dass Servern die einen public key haben, der mit einer CA signiert ist, die sich in einem gewissen Repository befindet, grundsätzlich vertraut wird.
Ansonsten setzt es eine 
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted certificate found.
Standardmässig ist dieses Repository in Java dies in einer Datei cacerts.
Genauer:
jre\lib\security\cacerts

Das Format ist irgendwie binary.
Man kann sich den Inhalt aber Klartext ausgeben, wenn man diese Zeile im code setzt, bevor versucht wird irgendwelche SSL-Verbindungen zu öffnen:

--- Code: ---
System.setProperty("javax.net.debug", "ssl");

--- Ende Code ---
Es gibt dann noch diverse Tools im jsdk, mit dem man da neue CA-certs reinbringt. Leider sind das Kommandozeilentools, die ein bischen nervig sind. Über google findet man kleine, nicht so toll geschriebene Java Programme, die aber super funktionieren und bei der Bedienung dieser Kommando-Zeilen Tools helfen.
Z.B:
http://diakonia.org.za/webCDcreator/4pluginRSA/installCA.html

Viele CA-certs sind schon von Hause aus im cacerts-Repository. Das in Deutschland recht verbreitete TrustCenter leider nicht. Die Infos für CA in Browser bringen sind noch ganz ok. Die Infos für Leute, die die CA in Java cacerts (oder auf anderen Prog-Plattformen) bringen wollen, hingegen imnsho katastrophal.
So ungewöhnlich dürfte dieses Ansinnen nicht sein.
So eine Informationspolitik hat natürlich Folgen.
Z.B. schaltet der php-Beispielcode einer Deutschen Großbank SSL-Server-Authentifizierung der Einfachheit halber ganz aus  >:( . Es ist an dieser Stelle vielleicht auch nicht so wichtig. Besonders toll finde ich das aber nicht. In einer besseren Welt sollten Banken grundsätzlich an der Einhaltung an Sicherheitsprozessen interessiert sein.

Ein tolles Buch für Java Security ist: Pankaj Kumar, J2EE Security.

flaite:

--- Zitat von: mt69clp am 31.01.06 - 16:03:22 ---Der Javacode ist dem Skript-Code von mir recht ähnlich, auch in .NET ist es fast identisch zu machen.

--- Ende Zitat ---
Ist mir jetzt bei Garry Devendorfs code auch aufgefallen.
http://blog.advisor.com/blog/garydev.nsf/d6plinks/GDEF-6LMV4M
Dieses

--- Code: ---DominoWS.PreAuthenticate = True  ' force credentials in first call 

--- Ende Code ---
kam mir doch sehr bekannt vor.

Diese Libraries sind einfach sehr feingranulare und dünne wrapper um das http Protokoll. Durch Lesen der HTTP-spec wird man die Library besser verstehen. Und so umfangreich ist die nicht. Und man kann sich mit http-sniffern, interceptoren etc. Life anschauen, was wirklich zwischen Client und Server ausgetauscht wird.
Manchmal sind solche Libraries eng am technischen Objekt einfacher.
Z.B. haben wir uns geeinigt, dass ich Spring wrapper um die apache.commons.HttpClient benutze. Die haben das in spring integriert. Der code wird weniger und die Konfiguration wird konsistenter mit dem Rest-Projekt.
Nur fällt es mir in diesem Fall schwerer die Library on top zu verstehen als die low level (jakarta.commons.HttpClient). Obwohl Spring für mich heilig ist.
Es gibt eben keine Absolutheiten und es hängt sehr oft vom Einzelfall ab.

Axel

Navigation

[0] Themen-Index

[*] Vorherige Sete