michaelrsweet
commented
3 years ago Current Fetch Specification from the W3C
Adding support for CORS will require some libcups changes as well as cupsd changes. Basic list:
- [x] Add
Access-Control-xxxandOriginheaders to HTTP field enumeration and header list - [ ] Add cups-files.conf (not cupsd.conf for security reasons) directives to enable remote JavaScript access
- [ ] Document changes and how to use/configure
- [ ] Add test file with simple IPP request to test suite
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:
1) (easiest approach from a user perspective) place the printer on the public internet. This allows the server component of the browser application to submit print jobs. Hopefully the user exposes their printer securely - however - considering most people cannot configure a router, it is unlikely that the average person working from home is sharing their printer over the internet securely. This seems worse than exposing CORs to the LAN. There is a little more to this as most users have dynamic ip addresses, but that is ignored for the sake of discussion. 2) place a reverse proxy in front of CUPs and apply CORs headers there. This method allows the Javascript application running in the browser to print via their local network without exposing the printer over the public internet.
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.