Questions & Answers

[aVogt]

Hallo,

ich habe folgendes Problem mit Exalead:CloudView

Nach einer Suche werden die Suchergebnisse eingeschränkt (das Merkmal ist eine Kategorie).
Danach soll eine neue Suche ausgeführt werden. Über folgenden Link habe ich gehofft, alle Einschränkungen zurückzusetzen:
http://[URL]?redirectUrl=index.jsperrorUrl=index.jsp%3Ferror&q=

Das funktioniert aber nicht. Bei einer neuen Suche wird immer die vorherige Einschränkung der Suchergebnisse wieder angezeigt.

Also:
1. Suche: Suche nach xyz
2. Verfeinerung: Verfeinerung der Suchergebnisse z.B. nach Abteilung abc
3. Suchformular aufrufen
4. Suche nach fgh
5. Suchergebnis ist bereits nach der Abteilung abc eingeschränkt.

Wie kann ich die Einschränkungen bei einer neuen Suche zurücksetzen?

Grüße
Andreas

[aVogt]

> Erscheint die leere Seite auch, wenn die Suche mit dem alten Modul (1.x) und exalead enterprise:one durchgeführt wird?

Das müsste ich testen bzw. mir erst mal was aufbauen. Bei exalead enterprise:one verwenden wir keine Autorisierung (Internet halt).

> Vielleicht hilft ein <meta http-equiv="expires" content="0"> um ein automatisches Neuladen der Seite zu forcieren.

Hat nichts gebracht.

> Ist das Problem Browser-unabhängig?

Das kann ich nicht sagen, da bei uns intern nur der IE8 erlaubt ist.

> Man könnte testweise per JSP-Code prüfen, ob bereits ein Benutzer angemeldet ist (Session-Attribut "FIRSTpersonalisation.user") und in diesem Fall das Authorize-Tag nicht in die Seite schreiben.

Das hat auch nicht geholfen. Ich bin allerdings über fsp:isNotAuthorized gegangen.

So wie ich jetzt aus meinen Tests sagen würde, kommt es zu dem Verhalten, wenn vor der Suche einmal fsp:authorize force="false" ausgeführt wurde (normal muß das ja auch geschehen, da die Suche auch rechteabhängige Ergebnisse liefert).
Es nutzt nichts, wenn auf einer Seite das fsp:authorize force="false" steht und auf der Suchergebnisseite nicht. Nur wenn nie fsp:authorize force="false" aufgerufen wird, funktioniert die Suche wie gewünscht.

Grüße

Andreas

[marro]

Ok, jetzt haben wir das Problem ja doch noch ganz gut eingrenzen können. Ich tippe mal darauf, dass ihr NTLM-Authentifizierung einsetzt. Zum Thema NTLM, Formulare und POST-Requests gibt es in der DynamicPersonalization-Dokumentation ein entsprechendes Kapitel (2.5.1. NtlmPreAuthenticationFilter). Darin wird beschrieben, wie man einen Filter konfiguriert, der vor jedem POST-Requst aufgerufen werden muss. Dieser Filter tut im Grunde nichts anderes als den Request entgegenzunehmen und den Browser dazu zu bewegen, ihn ein zweites Mal abzusetzen. Der Grund dafür ist, dass nach erfolgter NTLM-Authentifizierung der Internet Explorer bei jedem POST-Request die Formularfelder zunächst leer mitschickt. Erst wenn der Request ein zweites Mal abgeschickt wird, werden die Formularfelder korrekt gefüllt.

Viele Grüße

Donato

[aVogt]

Richtig. Wir setzen NTLM ein.

In meiner WebXml steht beim Filtermapping für "NtlmPreAuthenticationFilter" ein "*". Das scheint aber nicht beachet zu werden. ich habe nun mal "*.search" (also das Suchvervlet angegeben und siehe da, es wird mir "The request sent by the client was syntactically incorrect (no errorUrl specified!)." bei der Suche gemeldet. Was auch immer das wieder bedeuted.

In dem Suchformular gibt es ein (hidden) Feld errorUrl. Ich will da nicht ausschließen, dass es da einen Fehler beim Absenden gibt. Über ein JavaScript werden die Suchanfragen auf unterschiedliche Seiten verteilt, jenachdem nach was gesucht wird. Deswegen auch mehr als die zur Suche notwendigen Felder.

So sieht das Formular aus:

[Editiert]

=> Anhang formular.txt (Hab es in den Anhang geschoben, da der Kommentar "verunstaltet" aussah)

Ich habe nun auch einen Fehler gefunden, der geloggt wird => fehler.log. Es wird gemeint:

Invalid query, the query string must be not null and have a length greater than 0

Wenn ich die Suche über den Browser aufrufe, wird was anderes gemeldet ... na ja

Ich werd mich nächste Woche wieder damit beschäftigen. heut ist erst mal Schluß.

Schönen ersten Advent.

Grüße

Andreas

[marro]

Die Fehlermeldung sieht eher danach aus als würde das Filtermapping "*" doch greifen und "*.search" nicht. Denn nun beklagt sich das Servlet ja darüber, dass es keine errorUrl erhalten hat, was dafür spricht, dass der Filter nicht greift und der POST-Request leer ist. Wenn der Filter nun allerdings vorher doch funktionierte, habe ich leider keine weitere Idee, was die leere Seite verursachen könnte.

Das SearchServlet sollte beim Ausführen einer Suche eigentlich folgendes ins Log schreiben "Search performed for '<Suchbegriff>'". Wenn man nun wie gehabt eine Suche durchführt, eine leere Seite angezeigt wird und man nun vor einer Aktualisierung der Seite durch F5 ins Log schaut, sollte man erkennen können, ob die Suche bereits stattgefunden hat und der Fehler somit beim Redirect von SearchServelt zu Ergebnisseite auftritt, oder ob die Suche nicht durchgeführt wurde und somit der Fehler bereits irgendwo zwischen Formular und SearchServlet liegt.

Danke, Dir auch einen schönen ersten Advent.

Viele Grüße

Donato

[aVogt]

Hallo Donato,

>Wenn der Filter nun allerdings vorher doch funktionierte, habe ich leider keine weitere Idee, was die leere Seite verursachen könnte

Zumindest hat die Suche mir immer was angezeigt.
Ich habe den Filter wieder auf "*" gesetzt. Nun wird jede Menge protokolliert. Bis zur Zeile 230 wird geschrieben, bevor die leere Seite angezeigt wird. Nach dem F5 die Zeilen 231-234.

In Zeile 54 wird auch was von GET geschrieben ...

>Das SearchServlet sollte beim Ausführen einer Suche eigentlich folgendes ins Log schreiben "Search performed for '<Suchbegriff>'".

Das macht er auch (Zeile 222).

Was mich noch stutzig macht sind folgene Zeilen (aus dem TC-access-log):

172.20.52.142 - - [03/Dec/2012:11:09:25 +0100] "POST /de/do.search HTTP/1.1" 401 -
172.20.52.142 - - [03/Dec/2012:11:09:25 +0100] "POST /de/do.search HTTP/1.1" 302 -
172.20.52.142 - - [03/Dec/2012:11:09:26 +0100] "GET /de/suche/search.jsp HTTP/1.1" 401 -
172.20.52.142 - - [03/Dec/2012:11:09:26 +0100] "GET /de/suche/search.jsp HTTP/1.1" 200 -
172.20.52.142 - - [03/Dec/2012:11:09:33 +0100] "GET /de/suche/search.jsp HTTP/1.1" 200 38521

Nach Absenden der Suchanfrage wird nichts geschrieben. Erst nach dem F5. Alle 5 Zeilen gehören zusammen. Erst das "POST" an das SuchServlet und dann "GET" (?) an die Ergebnisseite (redirectUrl).

Ist das denn korrekt?

Da Du keine Idee mehr hast, werde ich mich an den helpdesk wenden.
Danke für Deine Mühen und Tipps.

Grüße
Andreas

[marro]

Hallo Andreas,

so wie es im Log aussieht, greift der Filter sowohl beim Aufruf des SearchServlets als auch beim Aufruf der Ergebnisseite. Letzteres möchte man aber eigentlich gar nicht, und in diesem Fall scheint da auch das Problem zu liegen. Versuch doch bitte noch mal das Filtermapping anzupassen. Allerdings trag beim Mapping nicht den Aufruf des Servlets auf, sondern den Namen des Servlets, so wie er in der web.xml bei der Definition des Servlets angegeben ist. Beispiel:

[....]

<filter-mapping>

     <filter-name>NtlmPreAuthenticationFilter</filter-name>

     <servlet-name>SearchServlet</servlet-name>

</filter-mapping>

<servlet>

     <servlet-name>SearchServlet</servlet-name>

     <servlet-class>de.espirit.ps.exalead.servlets.SearchServlet</servlet-class>

[....]

Viele Grüße

Donato

[aVogt]

Hallo Donato,

DAS IST ES (zumindest nach meinen ersten Tests).

Damit hat es funktioniert (und mit dem "post" natürlich).

VIELEN DANK

Grüße

Andreas