[cups.general] Re: How to authenticate from printing software?

[Michael Sweet]

Colin Walters wrote:
> ...
>>>After the job is ultimately sent, yes.  Imagine a very large job (say a
>>>100 page OpenOffice document).  We want the user to just be able to
>>>click "print", and close OpenOffice, and the job should keep printing.
>>
>>I don't think you get it - OpenOffice creates a print file, and the
>>file is sent to the print server (or even to a printer).  The
>>application cannot exit before the job is completely sent, otherwise
>>the job will be cancelled by the IPP server (this is part of the IPP
>>spec - the HTTP request would not have completed).
> 
> 
> You didn't read the printing-architecture document carefully enough. For
> a remote printer, the document is sent to the session cups server.  The
> applications are not responsible for sending jobs over the network,
> which is the point.

Sigh...  You are passing a file over a network connection (local or
remote, doesn't matter), and once that file has been accepted by
the server, the job is created and the app can go away.

Given that the CUPS API provides support for all of the supported
authentication methods, it is trivial to add a password dialog to
the GNOME/KDE print APIs, and the remote server will challenge
the print request immediately, why do you need to add a layer of
indirection to the printing process?

> ...
>>I'd say the same, but I'm not sure you understand that the lifetime
>>of a job lasts beyond the life of an application in IPP.
> 
> 
> Um, certainly I understand that, since I implemented eggcups, which
> provides job status feedback independent of the application.

OK, I think I see what you are trying to do now.  You want a thin
layer between the system cupsd and the application which provides
job monitoring and support for remote authentication.

Somehow I think you might be better off just providing a GUI
application (think kprinter, gtklp, etc.) which talks directly
to the (possibly remote) server and puts itself in the background
to show a job status window to the user.

>>>For MTAs, or for CUPS?  I very seriously doubt it is used for many MTA
>>>setups, since for example with Kerberos, short of actually shipping the
>>>user's Kerberos credentials over the network (violating several
>>>principles of Kerberos), you can't do it.  In the case of plaintext
>>>logins, you need to ship the user's unencrypted password. 
>>
>>With CUPS for sure,
> 
> 
> How does it work then?

You setup multiple servers to act as proxies to tunnel print jobs
between networks.  E.g. system A queues job 123 on system B, which
sends it to C, which sends it to D, which sends it to the printer.

Right now you have to hardcode the user:pass in the device URI
when setting up the proxy/tunnel servers, however in the future
it will be possible for upstream servers to notify the job
originator when authentication is required. The user will send
credentials via an IPP request to the upstream server, which will
then resume the job (that's the plan, anyways).

We are still working out the secure password store and the method
that the backends will use to access it (we want this to work for
any backend and/or authentication method)

>> and my previous life working for the Navy saw
>>a 2-level MTA setup which was a major pain.
> 
> 
> I can imagine, it must have been a proprietary protocol on top of SMTP.

Not really, it basically looked like a moderation system - all outgoing
email had to be authenticated first with the local SMTP server, the
mail was sent and held on the final server, and then we approved it
(with more username/password stuff) via a UI at the final server.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com