New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--disable-local-file-access is ignored on Windows when using invalid URLs #1639

Closed
mctart opened this Issue Apr 15, 2014 · 7 comments

Comments

Projects
None yet
3 participants
@mctart

mctart commented Apr 15, 2014

On Windows, 0.12.1 x64 Dev and Windows 0.11.x x64, the flag --disable-local-file-access appears to be ignored. The command line issued was:

C:\Program Files (x86)\wkhtmltopdf\bin>wkhtmltopdf.exe --disable-local-file-access c:\regvercheck.txt c:\temp\blah2.pdf

which produces a file c:\temp\blah2.pdf rather than error or access denied type message.

My dev machine is Win 7 pro x64 running with admin rights. Fresh install of wkhtmltopdf 0.12.1 dev.

Excellent application BTW

Thanks

@ashkulz ashkulz added the Invalid label Apr 15, 2014

@ashkulz

This comment has been minimized.

Member

ashkulz commented Apr 15, 2014

I think you've got the wrong idea: if you read the command-line help, it says:

    --disable-local-file-access       Do not allowed conversion of a local file
                                      to read in other local files, unless
                                      explicitly allowed with --allow

so the first file will always get processed.

@ashkulz ashkulz closed this Apr 15, 2014

@kyriakos

This comment has been minimized.

kyriakos commented Dec 16, 2014

This is still an issue actually. I am processing a remote file on Windows which contains an img tag which its source is a local file but in the following format: c:\temp\myphoto.jpg. The image still shows up in the PDF even with the --disable-local-file-access active.

It gives the following warning though:
QNetworkAccessFileBackendFactory: URL has no schema set, use file:// for files

This could be a security issue in case someone is converting remote / untrusted html files.

@ashkulz

This comment has been minimized.

Member

ashkulz commented Dec 16, 2014

Can you post complete sample which shows this happening?

@kyriakos

This comment has been minimized.

kyriakos commented Dec 16, 2014

command:
wkhtmltopdf --disable-local-file-access http://localhost/web/html/body.html d:\temp\out.pdf

body.html:

<html>
    <head>      
    </head>
<body>

<a href="#"><img src="file:///D:/sites/web/wordpress/wp-content/uploads/2014/05/IMG_3561.jpg" align="left" width="140" height="140"></a>
<a href="#"><img src="D:\sites\web\wordpress/wp-content/uploads/2014/05/IMG_3561.jpg" align="left" width="140" height="140"></a>
</body> 
</html>

Console Output:

Loading pages (1/6)
QNetworkAccessFileBackendFactory: URL has no schema set, use file:// for files
Counting pages (2/6)
Resolving links (4/6)
Loading headers and footers (5/6)
Printing pages (6/6)
Done

Output looks like this:

image

@ashkulz ashkulz changed the title from --disable-local-file-access is ignored to --disable-local-file-access is ignored on Windows when using invalid URLs Dec 16, 2014

@ashkulz ashkulz removed the Invalid label Dec 16, 2014

@ashkulz ashkulz added this to the 0.12.2 milestone Dec 16, 2014

ashkulz added a commit that referenced this issue Dec 16, 2014

block access to local files on Windows when an invalid URL is used
If you use an absolute path e.g. C:\TEST.PNG it is incorrectly
interpreted as an URL with the scheme as "C". This shows up as a
warning which was added in QTBUG-17731:

QNetworkAccessFileBackendFactory: URL has no schema set, use file:// for files

However, we should simply not process such URLs similar to what was
done for Qt5 via qt/qtbase@9581c90.

Fixes #1639

@ashkulz ashkulz added the Fixed label Dec 16, 2014

@kyriakos

This comment has been minimized.

kyriakos commented Dec 22, 2014

thanks!

@ashkulz

This comment has been minimized.

Member

ashkulz commented Jan 4, 2015

A release candidate 0.12.2-rc-71e97c1 is available, which should fix this issue. Please report back if your issue is not solved with the above build.

@ashkulz

This comment has been minimized.

Member

ashkulz commented Jan 10, 2015

0.12.2 has been released, which includes changes related to this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment