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

[Colin Walters]

On Fri, 2004-08-27 at 11:03 -0400, Michael Sweet wrote:
> Colin Walters wrote:

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

Yes.  But there is a big difference between a session CUPS daemon
running on localhost versus a remote server over a network which may be
bandwidth-limited or go down in the middle of a job.

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

Yes.

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

That is more or less what we do.

> >>>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, 

Right, so you're authenticating the servers, not the users.

> however in the future
> it will be possible for upstream servers to notify the job
> originator when authentication is required.

So in other words, it doesn't work with CUPS now, so I don't see how "it
is already used in a LOT of corporate and government environments".

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

Right...not really SMTP anymore :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://lists.cups.org/pipermail/cups/attachments/20040827/3c947038/attachment.bin>