[
https://issues.apache.org/jira/browse/PDFBOX-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14156213#comment-14156213
]
Bertrand GILLIS edited comment on PDFBOX-2397 at 10/2/14 8:18 AM:
------------------------------------------------------------------
It does work now. Thanks a lot Tilman for the quick fix !
But I still have a question about how to deal correctly with SecurityException
in PDFBox source code. Instead of swallowing the exception (using a try/catch),
I think it is more recommended to use java.security.AccessControler instead.
In my applet code, when I try to use a protected resource, I always use this
type of code:
{code}
/**
* Locates printer names capable of printing PDF document.
*
* @return array of printer names.
*/
public String[] lookupPrinterNames()
{
return (String[]) AccessController.doPrivileged(new
PrivilegedAction()
{
public Object run()
{
String[] printerNames = null;
PrintService[] services =
PrintServiceLookup.lookupPrintServices(DocFlavor.SERVICE_FORMATTED.PAGEABLE,
null);
if (services != null && services.length > 0)
{
printerNames = new
String[services.length];
for (int i = 0; i < services.length;
i++)
{
printerNames[i] =
services[i].getName();
}
List<String> printerNameList =
Arrays.asList(printerNames);
Collections.sort(printerNameList,
String.CASE_INSENSITIVE_ORDER);
printerNames =
printerNameList.toArray(new String[printerNames.length]);
}
return printerNames;
}
});
}
{code}
I'm not sure that swallowing SecurityException is the correct way to handle
these exceptions. Even if PDFBox is embbed in an applet, I might want to force
any system property of PDFBox (eg. org.apache.pdfbox.forceParsing or
org.apache.pdfbox.ICC_override_color). And currently, I will not be able to
force these system property because a SecurityException will be thrown and will
be swallowed.
Then I guess SecurityException swallowed in classes referenced in PDFBOX-2397
and PDFBOX-1946 should be fully reviewed and handled using
java.security.AccessControler instead.
It might be also necessary to review the full PDFBox source code in order to
verify that any other class does not have this type of issue.
was (Author: bgillis):
It does work now. Thanks a lot Tilman for the quick fix !
But I still have a question about how to deal correctly with SecurityException
in PDFBox source code. Instead of swallowing the exception (using a try/catch),
I think it is more recommended to use java.security.AccessControler instead.
In my applet code, when I try to use a protected resource, I always use this
type of code:
{code}
/**
* Locates printer names capable of printing PDF document.
*
* @return array of printer names.
*/
public String[] lookupPrinterNames()
{
return (String[]) AccessController.doPrivileged(new
PrivilegedAction()
{
public Object run()
{
String[] printerNames = null;
PrintService[] services =
PrintServiceLookup.lookupPrintServices(DocFlavor.SERVICE_FORMATTED.PAGEABLE,
null);
if (services != null && services.length > 0)
{
printerNames = new
String[services.length];
for (int i = 0; i < services.length;
i++)
{
printerNames[i] =
services[i].getName();
}
List<String> printerNameList =
Arrays.asList(printerNames);
Collections.sort(printerNameList,
String.CASE_INSENSITIVE_ORDER);
printerNames =
printerNameList.toArray(new String[printerNames.length]);
}
return printerNames;
}
});
}
{code}
I'm not sure that swallowing SecurityException is the correct way to handle
these exceptions. Even if PDFBox is embbed in an applet, I might want to force
any system property of PDFBox (eg. org.apache.pdfbox.forceParsing or
org.apache.pdfbox.ICC_override_color). And currently, I will not be able to
force these system property because a SecurityException will be thrown and will
be swallowed.
Then I guess SecurityException swallowed in classes referenced in PDFBOX-2397
and PDFBOX-1946 should be fully reviewed and handled using
java.security.AccessControler instead.
It might be also necessary to review the full PDFBox source code in order to
verify that any other class do not have this type of issue.
> Running within an Applet throws an AccessControlException
> ---------------------------------------------------------
>
> Key: PDFBOX-2397
> URL: https://issues.apache.org/jira/browse/PDFBOX-2397
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
> Affects Versions: 1.8.7
> Environment: JRE 7u67 or JRE 6u45 (Windows 7 SP1 64bit)
> Reporter: Bertrand GILLIS
> Assignee: Tilman Hausherr
> Fix For: 1.8.8
>
>
> As soon as PDFBox is embedded in a signed applet, the following exception is
> thrown when I try to print a PDF document through PDFBox:
> {code}
> Caused by: java.security.AccessControlException: access denied
> ("java.util.PropertyPermission" "org.apache.pdfbox.ICC_override_color" "read")
> at java.security.AccessControlContext.checkPermission(Unknown Source)
> at java.security.AccessController.checkPermission(Unknown Source)
> at java.lang.SecurityManager.checkPermission(Unknown Source)
> at sun.plugin2.applet.AWTAppletSecurityManager.checkPermission(Unknown
> Source)
> at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
> at java.lang.System.getProperty(Unknown Source)
> at java.lang.Integer.getInteger(Unknown Source)
> at java.lang.Integer.getInteger(Unknown Source)
> at java.awt.Color.getColor(Unknown Source)
> at java.awt.Color.getColor(Unknown Source)
> at
> org.apache.pdfbox.pdmodel.graphics.color.PDColorState.<clinit>(PDColorState.java:50)
> {code}
> This issue was also in previous PDFBox versions for the following instruction:
> {code:title=BaseParser.java}
> FORCE_PARSING = Boolean.getBoolean("org.apache.pdfbox.forceParsing");
> {code}
> But it was fixed in later versions:
> {code:title=BaseParser.java}
> static {
> try {
> FORCE_PARSING = Boolean.getBoolean("org.apache.pdfbox.forceParsing");
> }
> catch (SecurityException e) {}
> }
> {code}
> This fixed is unfortunately not set for the current property:
> {code:title=PDColorState.java}
> private static volatile Color iccOverrideColor =
> Color.getColor("org.apache.pdfbox.ICC_override_color");
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
