Yves Forkl wrote: > Under Linux, I can't print from XXE at all, and XXE is blocked each time > when I try to print. > > > My configuration: > > XXE V. 2.11 > Linux 2.4.20-28.9 (RedHat 9A) > Java 1.5.0_02 > Gnome 2.2.0 > CUPS 1.1.17 > > > Problem description: > > As soon as I select the "Print..." option from the File menu with any > document opened, XXE is completely blocked, while in XXE's parent shell > appears a password entry dialog for logging into one of our servers > (which I don't have a password for - and shouldn't need to, as I will > explain). > > > Findings: > > I assume it is a CUPS-related problem because I didn't have it in the > times when my CUPS was broken, which unfortunately ;-) now works fine. > > After investigating the issue with our local printing expert, we think > having found the following explanation: Obviously XXE tries to build up > the list of available printers before showing the Print dialog box. Upon > encountering a printer which the local CUPS daemon knows of but which is > in the responsibility of a CUPS daemon on a remote machine, XXE (or its > "delegate") tries to connect to that CUPS daemon directly in order to > retrieve the properties of the concerned printer. In our case, that > remote CUPS daemon is run with the option "Require authenticated user" > (this is to allow only local users to send print jobs). > > If the user running XXE cannot be logged in automatically to that remote > machine, the password prompt displays, but the user will not be able to > log in if he/she has no account there. > > > Suggested solution: > > 1) Workaround: Make the CUPS Daemon on the remote machine accept access > from non-authenticated users as well. This is not always desirable. > > 2) Real solution: XXE (or its "delegate") should not try to query remote > CUPS daemons directly about printers that are assigned to them, but > rather restrict its queries for printer properties to the local CUPS > daemon, which will then contact the remote CUPS daemon if necessary. > Access control is then done on a typically well-established CUPS-to-CUPS > basis and does not require the user to log in to the remote machine. > > What do you think about it? >
XMLmind does not control what happens just before the Print dialog box is displayed. In Unix, the Print dialog box is a standard Java[tm] component written by Sun. I don't see how we could solve this problem.
