New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Send CORs headers for browser applications #266
Comments
Current Fetch Specification from the W3C Adding support for CORS will require some libcups changes as well as cupsd changes. Basic list:
|
…Issue #266) All this does is add HTTP_FIELD_xxx enumerations and the corresponding strings to allow libcups implementations of HTTP clients/servers that send/receive them. For the subject bug we'll still need to do a bunch of work in cupsd (later).
I've added the HTTP headers to CUPS 2.4 to enable some experimentation for this and some related security things: [master bccf2f9] Add support for CORS/HSTS/OSCORE/Interative Client security headers (Issue #266) Implementation of the rest of this will have to wait for a later CUPS feature release... |
…Issue #266) All this does is add HTTP_FIELD_xxx enumerations and the corresponding strings to allow libcups implementations of HTTP clients/servers that send/receive them. For the subject bug we'll still need to do a bunch of work in cupsd (later).
It would really simplify things for users of applications served through the browser that need to print documents if some sort of CORs configuration could be enabled via CUPs.
If you aren't familiar with CORs - this is solved simply by adding a few HTTP headers. Ideally, headers are only allowed for a set of trusted domains which can be enabled in some fashion by the user (i.e. the user needs to allow prints from "fancyprintjobs.example.com"). This page does a better job describing it than I could do here: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
If it is helpful, I can go into more detail about the specific header key/values required to facilitate communication between the application running inside the browser and CUPs. However, know it is simply adding a couple of http headers to the response based on the domain requests are made from.
The browser respects a CORs policy when allowing http requests from an application (i.e. javascript code) to endpoints served from a different domain than the application. When CORs is enabled, javascript applications are able to print directly to CUPs. Without CORs, browsers disallow the ability to submit IPP jobs to CUPs from an application running in the browser context.
Currently, users have two options - they can manually print each document by downloading it via the browser and using a local program to print. This is slow and requires the user to set the print settings for each type of job. Since the remote application already knows how it should be printed (and can set these settings automatically via IPP, it is frustrating for - and confusing to many - users to configure the printer correctly for different types of documents.
The better option is to allow the application to print directly via IPP. However, CORs restrictions make this difficult since they are not considered by CUPs.
Since CUPs does not allow CORs configuration, the user must do one of the following at present:
Of the two choices - CORs is safer and simpler for the end user. However there is a large barrier to entry here due to the configuration of a reverse proxy - this really isn't feasible for the average user who just expects printing to work.
Since there are ways to side step the issue - people are doing it. However, since the steps are complicated, it isn't being done well and users are unknowingly creating risk.
Please consider adding CORs support to CUPs in any fashion. It would be very useful to the end users.
The text was updated successfully, but these errors were encountered: