We haven't configured any password for the chrome-pdf recipe in JSReport. However, it seems to automatically apply a password even when manually removed. How can this issue be addressed?
-
Yes. It is rendering successfully when a new template is created, any changes to the configuration, we are encountering forced password and viewport errors.
-
Are you able to replicate the problem in the playground?
If now, can you email me the data folder and specify the jsreport version you use?
jan.blaha@jsreport.net
-
I am unsure if this can be replicated in the playground as I suspect this to be a configuration issue. The templates function smoothly locally at times, yet they prompt for a password within the application. I'm curious if anyone else has encountered a similar issue and if there's a solution available.
-
The password is enabled through pdf utils configuration.
When you run in the studio, the password application is disabled to avoid constant prompting.
When you run a real API request, the password may pop up even when you don't see it in the studio.
Note an older version (a year or something) had a studio bug causing that clearing of the password wasn't working. You may try the same with the latest to test as well.
-
You're absolutely right. We haven't enabled this feature at all; it's suddenly started happening. Even after deleting the password, it reappears. Is there a method to disable this feature?
-
Have you tried updating jsreport to the latest?
-
Yes. We bumped up to 4.2.0 from 3.6.0
-
You can disable pdf utils extension just like any other,
https://jsreport.net/learn/configuration#disabling-extensionsHowever you can't disable just particular password protection feature.
If you prepare for me some kind of replicable workspace, I would look at whats happening.
-
Hi, thank you for the response. I may not be able to recreate this in the playground. My team has decided to proceed with the HTML recipe for now. Your assistance is greatly appreciated.
-
I would happily look also on some minimal app repository if you would have time to prepare it.
-
Hello, thank you for your reply. We identified that the issue was caused by the developer's Chrome browser auto-saving the password settings. Accessing the studio in Safari resolved the issue. Nonetheless, this remains an interesting research topic for future reference.