Ticket #432 (new defect)

Opened 9 years ago

Last modified 6 years ago

RemoteGreenstoneServer and GLIApplet tasks

Reported by: ak19 Owned by: ak19
Priority: moderate Milestone: 2.87 Release
Component: GLI Severity: major
Keywords: RemoteGreenstoneServer, GLIapplet Cc:


1. BUG: When the GLIapplet is used to build and preview a collection, and if the browser is then pointed elsewhere before the user returns to open the GLI applet and rebuilds the collection, then on clicking Preview the browser crashes.

Possible solution: Consider turning authentication task into an Action as well, by adding a ping command on the gliserver.pl end that is sent the username and password and which it can verify.

2. Applet: If either the gliserver.pl or authentication weren't provided, then pressing the Launch GLI button should once again ask for whichever piece of data was missing before GLI itself is launched.

3. When working with the GLI client against a remote GS server, files with French filenames are zipped in such a way that the original encoding is ruined. This means that the files the remote greenstone server receives have the wrong filenames and things go wrong from there (interlinking, file display names, missing images in htmls).

The solution maybe to check whether 7-zip can handle such filenames and if so, to consider moving to a Java-based solution that uses a 7-zip API.

Change History

Changed 8 years ago by kjdon

  • milestone changed from Next Release (2 or 3) to Release 2.82

Changed 8 years ago by ak19

Problem 3 above is solved. There were two issues identified on Linux, one of which was also there on Windows:

1. The issue they had in common was that the filename to was sent by GLI which was encoded in URL-encoded using Java and which presumed the filename's charset itself was in UTF8. However, the filename need not have been in UTF8 there was no matching url-decoding where the charset encoding could be specified. Fortunately, using Base64 encoding for those client-server interactions which were sensitive to filenames worked, in that encoding in Java and decoding in Perl operated together correctly and neither side was required to know the original charset encoding of the filename in order to do the Base64 encoding/decoding.

2. The issue identified on Linux was that the LANG env variable determined how zipping and unzipping was done using Java's zip tools. If the client and server had different values for LANG environment variables (or if this was not set on one side, while it was on the other) then zipping and unzipping produced different results and the original filenames would not be recovered. The solution was to let the client pass the LANG env var it used and for the server to set its LANG env to the same value for (un)zipping. This is OK since the server is not persistent (env vars get reset for each command the server executes) and since setting gliserver.pl's env vars does not make these leak into the rest of the server machine's context (to affect other programs run on the server). This solved the zipping of filenames containing special chars problems.

Changed 7 years ago by kjdon

  • milestone changed from Greenstone 2 wishlist to 2.84 Release

Are any of these still valid??

Changed 7 years ago by kjdon

Anu, please check that these are all fixed

Changed 7 years ago by ak19

Bug description number 1 seems to no longer exist (19 and 20 Oct 2010). I have tested by creating, building and previewing a collection using the GLI applet, pointing the URL elsewhere and then

1) pressing the back button repeatedly to return to the applet page and relaunching the GLI applet, rebuilding a collection and previewing it, and

2) typing the GLI applet's URL into the page after visiting elsewhere, and then rebuilding and previewing a collection.

Both worked fine and neither crashed the browser. Bug 1 seems to have been fixed as a side effect to any other changes made in the code.

Changed 7 years ago by ak19

About the second issue mentioned, the GLI applet does not accept unknown users or wrong passwords, but requires a correct re-entry for authentication until the user presses Cancel. Then the applet area contains a Java wait image. The applet does not accept an empty URL and asks the user to re-enter one. At present if the URL is wrong then the Applet launch button ends up appearing anyway. This last still needs to be fixed.

Changed 6 years ago by sjm84

  • milestone changed from 2.84 Release to 2.86 Release
Note: See TracTickets for help on using tickets.