[gelöst] jcaptcha in klassischer Domino- Web- Anwendung: Wie anfangen...

[Tode]

Ich betreue den Domino- Part einer Website, die jetzt per Captchas geschützt werden soll. Dabei wird jcaptcha für den Rest der Website verwendet, und ich würde das gerne auch im "Domino"- Part einbinden.

Ich habe hier ein Beispiel gefunden, wie man das mit einem Servlet macht. Servlets sind ja grundsätzlich auch im Domino- Umfeld möglich, bedeuten aber einen erhöhten Aufwand bei der Entwicklung. Wie würdet Ihr so eine Anforderung umsetzen?

Erst mal würden mich grundsätzliche Möglichkeiten interessieren. Wenn ich mich dann für einen Weg entschieden habe, werde ich sicherlich nochmal mit konkreten Fragen zu konkreten Problemen zurückkommen...

Thanx

[flaite]

Hmm
a) ist die Servlet Engine von Domino sehr, sehr alt, wobei dein verlinktes Beispiel vermutlich darauf laufen tät.
b) kennst Du dich mit der Servlet-Engine administrativ und coder-mässig nicht so aus.

So schwierig ist das aber auch nicht, dass ans Laufen zu bekommen. Du schaffst das bestimmt mit der entsprechenden Anleitung.

Warum geht das nicht mit Notes Agenten?
Auf Planetlotus gibts ein neues Projekt, das JCaptcha verwendet. Möglicherweise kannst Du da ein paar Inspirationen holen. Möglicherweise musst Du bei Agenten Apache-jakarta Http-Client verwenden, aber das is nicht so schwierig.
http://www.openntf.org/blogs/openntf.nsf/d6plinks/NHEF-8ZJC2F

Ich persönlich würd erstmal mit dem Beispielcode in Netbeans und da mitgelieferten Glassfish ausprobieren und das dann später in Domino reinarbeiten. Wär natürlich für dich auch wieder eine Lernkurve, wobei die aktuelle Netbeans/Glassfish Kombination in Sachen Einfachkeit und Gehirn-zu-laufender Anwendung Latenz (TM) in allem-JEE-Zeugs echt der Hammer ist.

Servlets sind im Prinzip sehr einfach. Erklär einfach alle beschreibbaren Variablen äh Properties lokal in der doGet-Methode, sonst ist es nicht Thread-Safe und Du weisst vielleicht nicht, was das heißt. Du weisst vermutlich auch nicht, wie Du das abwärtskompatibel zu der Domino-Servlet Version programmieren kannst.   

Gruß Axel

[Tode]

Ja, der Agent wäre auch mein Ansatz gewesen... Muss ich halt schauen, wie ich das zum Laufen kriege. Das openntf- Projekt hatte ich gefunden, das bezieht sich aber auf Googles ReCaptcha, was ein anderer Ansatz ist... Das ist zwar relativ einfach einzubauen (damit habe ich angefangen und bin schon recht weit, bis auf ein Paar Berechtigungsprobleme beim Abfragen der Google- Site im Backend läuft das), aber das Captcha sieht halt anders aus als das bei jCaptcha, weshalb ich gerne darauf gehen würde. Und Auf xPages kann ich leider auch nicht gehen, der Aufwand das alles umzuschreiben wäre zu gross...

Danke erstmal fürs Feedback... Dann schaue ich mal, was ich alles in nen Agent einbinden muss, damit ich da ne Antwort vom Agent kriege (erst mal ein Captcha- Bild, dann das Ergebnis.... wahrscheinlich brauche ich zwei Agents, oder muss das per Parameter steuern...)

[flaite]

Hab das zwecks persönlicher Weiterbildung auf Tomcat ans Laufen bekommen.
Mit diesem nostalgischen Servlet/JSP Code.
https://www.owasp.org/index.php/JCaptcha_servlet_example

Wie man einen Domino Agent davon überzeugen kann das BufferedImage in die Webseite zu schreiben ist mir ein wenig schleierhaft. Der Servlet-Weg ist vielleicht einfacher. Aber dann musst Du die Authentifizierung evtl. über Servlet machen, weil das captcha muss ja vielleicht auf der login-Seite stehen?

Gibt noch eine 2 Serverlösung, d.h. Du kommunizierst per jakarta HttpClient mit einem externen Tomcat, auf dem der Captcha Teil als .war deployed ist. Diese verteilte Lösung macht das natürlich bestimmt nicht schneller, aber vermutlich auch nicht prohibitiv langsam. Ausserdem hast Du einen weiteren point of failure, sprich was machst Du wenn der Domino läuft aber der Tomcat die Grätsche gemacht hat? Aber wenn sowieso schon ein Teil der Anwendung auf Tomcat, JBoss, Websphere, etc. gehostet wird, sollte die auch relativ ausfallsicher sein.
Die JSPs liessen sich problemlos in Servlets umwandeln.

Das Beispiel ist so aufgebaut:
1. login.jsp für login Seite. Die bekommt das captcha vom GET des Servlets.
2. bei Submit auf login.jsp wird das an das POST von dem Servlet gesendet. Das überprüft dann, ob die Eingabe richtig war. Und leitet dann auf results.jsp weiter, die nur ansagt, ob man richtig oder falsch mit der Eingabe gelegen hat.

Wie gesagt:
login.jsp liesse sich problemlos als Servlet schreiben.
results.jsp kann man auch im doPost von dem Servlet abfrühstücken.

In jedem Fall bräuchtest Du 2 Servlets. Eins für login.jsp und das andere für das Servlet und results.jsp.

 

[flaite]

Man kann das aber vermutlich leicht umbiegen.
Statement dazu spätestens Sonntag diese Woche.

[Tode]

Danke Dir mal für Deine Bemühungen... Die verlinkte Website hatte ich auch schon gefunden... Was ich mich gefragt hatte war, ob man nicht den Code des Servlets (erst mal des doGet) fast 1:1 in einen Agenten kopieren könnte... Auch das ausgeben des Bildes per printWriter müsste aus dem Agenten funktionieren... Und entweder ruft man den Agenten dann mit nem URL- Parameter auf (einmal OpenAgent&get, einmal openAgent&post), oder man macht nen zweiten Agenten zur Validierung.

Kannst Du evtl. dazu noch ein Statement abgeben, ob das möglich sein könnte?

VIELEN DANK für Deine Mühen...

[flaite]

Weiss nicht, ob das geht.
Bin dafür mittlerweile zuwenig Notes Programmierer.
Du kannst das ja mal ausprobieren.
Hab eben das hier gefunden. Sehr instruktiv und nicht unbedingt gute Nachrichten.
http://www.codestore.net/store.nsf/unid/BLOG-20080617

Es gibt aber einen anderen Weg.
Optimal für Domino wärs doch wohl, wenn man captchas mit der Lösungsantwort in Notes-Dokumenten hätte.
Diese Nutzung des JCaptcha codes wird aber von den Erbauern der Bibliothek ein bischen erschwert.
Ich vermute inzwischen sehr stark, dass die Lösung der Frage mit der ID des captchas in einer FastHashMap gespeichert wird. Da gibts aber keine public Methode um von aussen an diese FastHashMap ranzukommen. Es ist lediglich eine public Methode vorgesehen, um die Lösung des Users mit der richtigen Lösung zu vergleichen (dieses validate, s. Servlet).
Leider find ich nirgendwo den source-code als jar. Könnte das vom cvs von sourceforge auschecken. Hab aber erstmal das jar mit den Classes in JD-Gui geschmissen (AN ALLE: GUTER JAVA DECOMPILER, try google). Das sollte für meine Zwecke erstmal reichen. Zugriffs-Modifier in Java wie in diesem Falle protected sind kein Sicherheits-Feature der Sprache, d.h. man kann die aus dem code mit Hilfe der Reflection API auf public umschubsen. Weiss nicht, ob ich heute noch dazu komme, aber spätestens morgen.
Idee wäre ein periodisch laufender Agent, der eine bestimmte Menge an captchas mit Bild und Lösung des captcha Rätsels in Notes Dokumente tut. Die liessen sich dann problemlos in einem Agenten verwenden. Als id kannst du ja die DocumentUnid-id dieser Captcha Dokumente nehmen.

[flaite]

so fertig.
Wenn Du magst, kannst Du dir das in ein Eclipse Projekt tun und das mal ausprobieren.
Morgen schreib ich dann, warum das eindeutig ein Hack, aber trotzdem aus meiner Sicht für diesen Fall absolut i.O. ist.

Welche Notes-Version benutzt ihr eigentlich? Für Notes7 müssten da ein paar Schmankerl geringfügig geändert werden.

Mein Vorschlag:

Code

package test;

import java.awt.image.BufferedImage;
import java.io.BufferedOutputStream;
import java.io.ByteArrayOutputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.lang.reflect.Field;
import java.util.Locale;

import javax.imageio.ImageIO;

import com.octo.captcha.image.gimpy.Gimpy;
import com.octo.captcha.service.captchastore.FastHashMapCaptchaStore;
import com.octo.captcha.service.image.DefaultManageableImageCaptchaService;

public class NewTest {
	
	private static String BASE_VERZEICHNIS_FUER_BILDER = "/Users/axeljanssen/";
	
	public static void main(String args[]) {
		String id = "1";
		DefaultManageableImageCaptchaService instance = new DefaultManageableImageCaptchaService();
		ByteArrayOutputStream imgOutputStream = new ByteArrayOutputStream();
		BufferedImage im = instance.getImageChallengeForID(id, Locale.GERMAN);
		BufferedOutputStream fous = null;
		try {
			Class clazz = instance.getClass().getSuperclass().getSuperclass()
					.getSuperclass();
			System.out.println(instance.getClass().getSuperclass()
					.getSuperclass().getSuperclass().getName()); // SEHR HACK!!!
			// for (Field field : clazz.getDeclaredFields()) {
			// System.out.println("field:" + field.getName() + ":" +
			// field.getClass().getName());
			// }
			Field firstDoor = clazz.getDeclaredField("store");
			firstDoor.setAccessible(true); // hä hä
			FastHashMapCaptchaStore firstDoorOpen = (FastHashMapCaptchaStore) firstDoor
					.get(instance);
			Gimpy gimpy = (Gimpy) firstDoorOpen.getCaptcha(id);
			Class <Gimpy>clazz2 = (Class<Gimpy>) gimpy.getClass();
			Field secondDoor = clazz2.getDeclaredField("response");
			secondDoor.setAccessible(true);
			String rattenTanzenInDerSpeisekammer = (String) secondDoor
					.get(gimpy);

			System.out.println("DER CAPTCHA TEXT IST:" + rattenTanzenInDerSpeisekammer);

			// System.out.println("rattenTanzenInDerSpeisekammer=" +
			// rattenTanzenInDerSpeisekammer);
		} catch (Exception e1) {
			e1.printStackTrace();
			System.out.println("ECHTER ALARM");
		}
		try {
			ImageIO.write(im, "png", imgOutputStream);
			byte[] captchaBytes = imgOutputStream.toByteArray();
			fous = new BufferedOutputStream(new FileOutputStream(
					BASE_VERZEICHNIS_FUER_BILDER + id + ".png"));
			System.out.println("Bild wurde gespeichert in:" + BASE_VERZEICHNIS_FUER_BILDER + id + ".png");
			fous.write(captchaBytes);
			fous.flush();
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		} finally {
			if (fous != null) {
				try {
					fous.close();
				} catch (IOException e) {
					// Exception verschlucken i.O. in tcftc Konstrukt.
				}
			}
		}

	}

}

[flaite]

Eigentlich besteht JCaptcha aus mehreren Projekten. Mindestens 2. 

Projekt a) Projekt, dass die Bilder mit Lösung erzeugt und in einer Art Cache mit einem eindeutigen Schlüssel vorhält
Projekt b) Projekt, dass Bilder und challenge an User liefern sowie Rückantwort des Users mit Daten in Cache überprüfen in eine Struktur bringt und Integrationen mit verschiedenen Java Frameworks bildet.

Projekt b) hängt natürlich von Projekt a) ab. Der Nutzer der Bibliothek soll nach dem Willen der Entwickler nur mit Projekt b) über Projekt a) sprechen.

Nur ist Projekt b) nur unter Bauchschmerzen in Notes nutzbar.

Man kann aber sogar von aussen - wie ichs oben getan hab - Projekt a von der engen Kopplung zu Projekt b lösen.
Schliesslich ist es openSource. Ein bischen sauberer wäre vermutlich, wenn Du den source code auschecken würdest, um ihn zu patchen, d.h. ein wenig verändern. Kannst dann die jar JCaptcha-1.0.PATCHED.jar nennen und den Source code irgendwo sichern, u.a. auch in irgendwelchen GIT, CVS oder Subversion repositories.

Problematisch macht solche patch-Lösungen, wenn an der Komponente tatsächlich noch entwickelt wird. Wenns also etwa in eurem Unternehmen in 3 Monaten eine neue Version von JCaptcha deployed wird. Das müsstest Du nämlich dann vermutlich wieder neu patchen oder neuen Reflection code (mein Zeug oben) erstellen. Das genau aber kann für JCaptcha praktisch ausgeschlossen werden. Das Paket erfüllt seine Arbeit und im CVS sieht man, dass dort seit 2 Jahren kein neuer Code mehr eingecheckt wurde.

[Tode]

So viel Mühe! Danke! Jetzt werde ich mich morgen mal hinsetzen und das umsetzen.
Ich hoffe, Du bist nächstes Jahr auf dem EntwicklerCamp (oder dem AdminCamp), dann zahle ich Dir (mindestens) ein Bier!

Gruss

[flaite]

Naja, so viel Mühe wars auch nicht.
3 Stunden vielleicht.
Falls Du das ausprobierst und Fragen hast, melde das einfach. Gibt keine dummen Fragen, insbesondere weil das kein "normales" Java mehr ist. Auch keine Raketen-Wissenschaft, einfach ein bischen Anwendung von Java-Reflection. Ab Samstag fall ich allerdings für 9 Tage hier aus, weil ich dann auf der devoxx in Antwerpen bin und der Termin Kalender da extrem dicht gedrängt ist.

Im besten Fall eröffnet das eine für einige vielleicht neue Perspektive wie man Java Open Source Bibliotheken benutzen kann.

Auf der UKLUG Konferenz hab ich darüber nachgedacht es beim Entwickler-Camp als Speaker zu versuchen. Problem ist halt nur, dass ich kein Domino Entwickler mehr bin. Hab an sowas gedacht wie "Automatisiertes Testen auf unterschiedlichen Ebenen für XPages und Domino Anwendungen", aber ich kann nicht mal XPages  
Vielleicht starte ich Ende Dezember noch mal durch.
Das hier könnte vielleicht auch als Basis für einen Vorschlag für einen Vortrag dienen:
"Was nicht passt, wird passend gemacht: Ein paar Chuck Norris Methoden, um Java Open Source Bibliotheken in Domino konfortabel zu nutzen"
Da bräuchte ich allerdings noch 2 oder 3 gute Beispiele.
Kann sein, dass ich Ende Dezember die Energie finde, um mir f. Vorschlag 1 das entsprechende Domino spezifische Know How zu verschaffen, um zu versuchen mit Rudy ins Geschäft zu kommen.

[Tode]

Trotzdem: Danke... Ich habe mal kurz drübergeschaut und bin im Domino auf ein kleines Problem gestossen: Wenn ich den Code von Dir 1:1 in eine Java- Library und einen Agenten übernehme, dann kriege ich einen Sicherheits- Fehler (java.lang.reflect.ReflectPermission suppressAccessChecks). Den kann ich (zum testen) per Eintrag in die java.policy wegkriegen, aber interessant ist es dennoch, weil da eigentlich drin steht:

Code

// Standard extensions get all permissions by default

grant codeBase "file:${java.home}/lib/ext/*" {
	permission java.security.AllPermission;
};

und die libs liegen unter /lib/ext.
Ausserdem steht drin:

Code

/ Notes java code gets all permissions

grant codeBase "file:${notes.binary}/*" {
	permission java.security.AllPermission;
};

Also wo da die Berechtigung fehlt sehe ich nicht wirklich... Aber zumindest läufts mal...

[Tode]

Danke, danke, danke!!! Ich kriege mit einem modifizierten Agenten und mit Hilfe einer Base64- Encodierung das Bild direkt in den Browser geprinted. Jetzt muss ich mir nur noch überlegen, wo ich die Response zum Image zwischenlagere (wie Du schon erwähnt hast, haben wir ja keine Session, und ich setze auch keine xPages ein, um mir das in entsprechenden Session- Variablen zu cachen, aber auch das Problem löse ich noch. Wahrscheinlich liefere ich das Ergebnis gleich "verschlüsselt" an den Browser zurück, und lasse das entweder per Ajax- Request oder direkt im Browser "entschlüsseln" und mit der Usereingabe vergleichen. Dann kann zwar jemand, der den Quelltext liest, das ganz schnell "reverse engeneeren", aber es geht ja nur darum, Bots von der Seite fernzuhalten, nicht um ein Sicherheits- Feature. Dafür sollte es eigentlich reichen.

[flaite]

Hört sich viel besser an, als die Lösung, die mir vorschwebte.

a) Bilder vorgenerieren, d.h. erstmal einen Vorrat von 1000 Bilder. Bilder in Unterverzeichnis von html, Pfad zu diesem Bild und richtige Antwort in Domino Dokumenten. Diese neu erzeugten Dokumente haben Status "ready state". Bei neu eintreffenden Usern, wird immer das oberste Dokument ausgeliefert. Ansicht sortiert nach letztem Speichern. User wird auch die Universal-ID des Dokuments geliefert und im Browser in ein hidden Feld geschrieben. 
b) Wenn Bild ausgeliefert wird, ändert sich Status-Feld in Domino Dokument in "Waiting for Challenge". Nach ca. 5 Minuten wird das ungültig.
c) Wenn challenge für Bild korrekt oder falsch beantwortet, bzw. timeout, dann erhält Dokument wieder Status "ready state"

Vermutlich käm man da locker mit 1000 captchas aus. Bei Bedarf kann man immer nachgenenerieren. Eigentlich spricht nix dagegen die Bilder "wiederzuverwenden".

Deine Lösung hat weniger Zusatz-Ansichten, Dokumente für das captcha Thema. Deshalb ist sie vermutlich besser.

[flaite]

Zu der Sicherheit: Gibts da nicht ein Häckchen beim Agenten (in dem popup artigen Fenster, wo Du den Namen des Agenten hinschreibst). Es gibt da eine radio box und 2 oder 3 sicherheitsstufe. Run with Administrator rights oder so ähnlich. Bin diesbezüglich allerdings ein wenig verunsichert.

[Tode]

Ne, das hat nix mit Agentensicherheit zu tun, sondern ist wohl tatsächlich ne Java- Sicherheits- Geschichte, dass das überschreiben von Klassenproperties im Standard nicht erlaubt ist... Aber sobald das alles sauber läuft schaue ich nochmal, was ich an der Sicherheit tun kann...

[Tode]

So, es ist vollbracht... Das ganze läuft. Und weil es ja nicht mein alleiniger Verdienst war, lade ich hier mal ein ZIP mit der Lösung hoch, falls jemand mal ein einfaches Captcha für Lotus Notes auf Basis von jCaptcha braucht (ohne xPages)...

ACHTUNG: Dieses Beispiel erfordert, java- Berechtigungen auf dem Server ziemlich hoch zu setzen, also bitte nicht unbedingt auf Produktivservern einsetzen, obwohl mir jetzt nicht wirklich ein Sicherheitsloch einfällt, dass man damit aufreisst, denn wer unrestricted Agents auf dem Server laufen lassen kann, der kann sowieso schon alles...
Man kann es aber auch im Client per Browser- Vorschau laufen lassen, dann gilt die Anleitung für die entsprechenden Verzeichnisse im Client.

Install- Anleitung:
- Datenbank signieren und auf Server bringen
- die drei jars in Lotus\domino\jvm\lib\ext kopieren
- (Dieser Schritt nimmt das grosse Schlachtermesser, das geht sicher auch mit Skalpell, habs aber noch nicht rausgefunden wie und auch noch nicht, warum das überhaupt nötig ist) Unter Lotus\Domino\jvm\lib\security\java.policy die folgenden Zeilen oben ergänzen:
grant {
   permission java.security.AllPermission;
};
- Amgr und http durchstarten
- url aufrufen: http://servername/jCaptcha.nsf/CaptchaTest?OpenForm

Anmerkung: Dieses Beispiel macht keine Prüfung auf die Response auf dem Server (wie es eigentlich nötig wäre für echte Sicherheit), sondern direkt im Browser. Das heisst: Mit entsprechendem Know-How ist es recht einfach, die richtige Antwort herauszufinden, ohne sich das Bild auch nur anzuschauen.
Da es hier aber nicht um Security an sich geht sondern nur darum Bots abzuhalten, halte ich das Verfahren für ausreichend sicher.

Wer mir hier zuerst posted, wie man (ohne irgendwelche Libraries zu verwenden) an die richtige Response drankommt, dem zahle ich auf dem nächsten EntwicklerCamp ein Bier. Aber nicht schummeln: nicht den Java Quellcode benutzen, sondern nur das, was auch ein "Hacker" von der Seite zu sehen bekommt...

Man hätte im übrigen die jars auch in den Agenten einlagern können, aber wegen eines bösen Memleaks, der hier auch schon diskutiert wurde, ist das nicht empfehlenswert...

Ach ja: Ich bin absolut kein Java- Spezialist, aber in meiner endgültigen Version habe ich natürlich auch ein anständigeres ErrorHandling drin.
Sicherlich gibt es vieles, was man hätte besser machen können, aber ich brauchte halt ne schnelle Lösung zu gegebenen Rahmenparametern, und die habe ich jetzt...