Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino

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

<< < (2/4) > >>

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.
}
}
}

}

}

--- Ende Code ---

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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete