Menu
▾
▴
#225 Make it optional to rely on file system access for forms with file input fields
Hello,
I'm using HtmlUnit together with a Java security policy that does not grant java.io.FilePermission of any type. In getSubmitKeyValuePairs, HtmlFileInput constructs a util.KeyDataPair object. The constructor of util.KeyDataPair tests if a file exists, which violates the security policy, causing an exception to be thrown:
java.security.AccessControlException: access denied ("java.io.FilePermission" "" "read")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
at java.io.File.exists(File.java:814)
at com.gargoylesoftware.htmlunit.util.KeyDataPair.<init>(KeyDataPair.java:50)
at com.gargoylesoftware.htmlunit.html.HtmlFileInput.getSubmitKeyValuePairs(HtmlFileInput.java:119)
at com.gargoylesoftware.htmlunit.html.HtmlForm.getParameterListForSubmit(HtmlForm.java:254)
at com.gargoylesoftware.htmlunit.html.HtmlForm.getWebRequest(HtmlForm.java:151)
at com.gargoylesoftware.htmlunit.html.HtmlForm.submit(HtmlForm.java:134)
at com.gargoylesoftware.htmlunit.html.HtmlSubmitInput.doClickStateUpdate(HtmlSubmitInput.java:99)
at com.gargoylesoftware.htmlunit.html.DomElement.click(DomElement.java:786)
at com.gargoylesoftware.htmlunit.html.DomElement.click(DomElement.java:733)
at com.gargoylesoftware.htmlunit.html.DomElement.click(DomElement.java:680)
This happens when the submit input is clicked in the following HTML:
<!doctype html>
<html>
<head>
<title>foo</title>
</head>
<body>
<form>
<input type="file" name="foo">
<input type="submit">
</form>
</body>
</html>
I would like to be able to set the data of the HtmlFileInput object without the call to File#exists in the constructor of KeyDataPair.
//Sebastian Cato
The form was removed, defanged version:
Hi, have you checked
HtmlFileInput.setData(byte[])?Have commited a small fix that hopefully cures your problem. But keep in mind that HtmlUnit might save some responses on the local file system if the responses are too large.
Last edit: RBRi 2015-11-11
Tested it from trunk and it works just fine.
I use a parent process that does all network I/O and controls what page rendering tasks to do. I have HtmlUnit running in a JVM as a child to this process. All page rendering is done by HtmlUnit, and I have a custom WebConnection talking to the parent process over a socketpair inherited on fork. If page rendering uses too much time or memory, the parent kills the JVM process running HtmlUnit, starts a new one and moves on to the next task. This is ideal for my use case. Having a custom WebConnection also means that I don't run into the disk caching "problem" (it would be a problem for me, but that's because of my use case of course) of HttpWebConnection.
Thanks!