I've been having a weird issue for over a month now where PDFs are intermittently printing our InvalidPermissions screen instead of the desired content. This started shortly after I upgraded to the most recent version of Ultimate PDF from a very, very old version where you still had to leave your PDF generation screens set to be anonymously accessible and then secure them using short-lived tokens. I was excited to remove that and just start using screen roles with the new version since it copies user cookies into the headless Chrome instance on the server to mimic the access of the user that requests the PDF. It's a good feature, but after LOTS of troubleshooting, swearing, and crying, I have uncovered the root cause of my woes, which appears to be a bug in Ultimate PDF. I'm reporting that bug here so the team can look into it and hopefully fix it in an upcoming release.
The root of the problem comes from the way Ultimate PDF reuses Chrome instances from a pool when PDFs are generated in a short period of time. Suppose you have 2 users: Alice and Bob. Alice is in marketing and has the Marketer role, while Bob is in finance and has the Finance role. Suppose also that the marketing team has a PDF they need to generate. It's just a marketing brochure so the screen to generate that PDF is anonymously accessible. The finance team, however, has a PDF they need to generate with sensitive financial information on it, so that screen requires the Finance role.
In this scenario, Alice generates her marketing PDF first. A Chrome instance is fired up, her session cookies are applied, and the PDF generates without issue. Bob, meanwhile, generates his finance PDF moments after Alice generates her brochure. Ultimate PDF attempts to reuse the Chrome instance Alice just used to generate her PDF and, even though you can clearly see in the logs that it successfully clears Alice's session cookies out and adds Bob's session cookies, something else is left behind that confuses OutSystems' session management system. A security exception is thrown, and Bob gets a PDF with the InvalidPermissions screen from the OutSystems module where the finance PDF screen is implemented. Bob is angry and yells at Grayson.
I've spent a lot of time in the code for Ultimate PDF these last few weeks troubleshooting and I must say, it's very robust and elegant. I appreciate that it pools Chrome instances and attempts to reuse them. There is, however, something other than cookies being left behind that Ultimate PDF is not clearing that's causing OutSystems to get confused and throw a security exception when that browser instance is reused. I can reliably reproduce this error by setting up a scenario like the one I described, so I know for a fact this bug exists.
For now, the workaround is that I will be implementing PDF screen security the old way with short lived tokens and anonymously accessible screens to avoid this issue. I don't know what is being left behind that's causing the issue and I don't really have more time to diagnose, but I hope this is enough information for the Ultimate PDF development team to do their own analysis and implement a fix. Please don't hesitate to let me know how I can be helpful in fixing this. Love the product! Keep up the good work.