I am wondering whether changes to pmwiki security introduced in beta 67 (or possibly a later change) may have broken the PublishPDF library's ability to request a PDF of a password-protected page. While I am still investigating the issue, I thought it best to seek an informed opinion early, as this is potentially a serious problem with the recipe, needing an urgent fix.
The problem as reported occurs when an authenticated user calls for a PDF of a password-protected page. The problem occurs both for password access (standard pmwiki security) and username/password (via authuser) access. The PDF comes back with "Password required" instead of the page's contents. This has worked with no problems for several years. For unprotected pages, everything works fine. For password-protected pages: - the reader requests a PDF, which causes the wiki to pass the PHPSESSID as a hidden form variable to the PDF server - the PDF server issues a request to the wiki for the page's content, including the PHPSESSID in the URL (via a header cookie), along with the other parameters - the wiki server refuses access and prompts for a password, instead of returning the page content - when the reader attempts to return to the page from the wiki's "request PDF" screen, the wiki asks for a password, even though the reader is already authenticated; if the reader returns to the page without submitting a PDF request, it's fine For authuser protected sites, it uses IP-based authentication. Code in local/config.php inspects the IP address of the incoming request ($_SERVER['REMOTE_ADDR']) and if it matches that of the PDF server, it sets $_POST['authid'] and $_POST['authpw'] to valid values. This also no longer works on the site in question. I will keep investigating this, but it would be useful to have an informed opinion that "pmwiki [should still/will no longer] support these solutions." The site in question is running pmwiki 2.2.1 plus the latest PublishPDF library. There is a test wiki with no other local customisations. AFAIK, I haven't changed the recipe's security handler. The fact that both access methods broke makes me wonder if it could be a pmwiki change, and if so, what I need to do to fix it. I have asked the user to revert to beta 66 to see if the problem goes away. TIA -- John Rankin Affinity Limited T 64 4 495 3737 F 64 4 473 7991 021 RANKIN [email protected] www.affinity.co.nz _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
