URL to PDF Microservice • Hacker News Board

Re: URL to PDF Microservice

#31

Post by hobofan » Thu, Oct 05, 2017, 4:28 PM UTC

misterbwong wrote: post #27

hobofan wrote: post #16

Earlier quoted context omitted.

You are contradicting yourself. It is scalable. It scales linearly (and for practical purposes indefinitely) with the amount of money you spend on AWS Lambda. It might not have a nice constant factor, but it is scalable.

This is just pedantic. Anything can be scalable using that definition. Heck, I could hire a 3rd world worker to manually draw the PDF's, scan them to PDF using a scanner, and put them on a server and it would "scale linearly with the amount of money I spend" on labor.

> Anything can be scalable using that definition.

No, some things can't be, like badly architected monoliths, or databases. Especially with databases it's not a given, which is why for quite some time in the last years things like the "MongoDB is web scale" blew up and people started mindlessly asking "is it scalable" (which as you figured out, means very little for a lot of systems). I'm also pretty sure that your example scales worse than linearly, since you have to introduce multiple levels of management at some point.

"scalable" = "can it be scaled", which is not a given for every system

Re: URL to PDF Microservice

#32

Post by dotmanish » Thu, Oct 05, 2017, 4:36 PM UTC

homero wrote: post #13

erdbeerkaese wrote: post #6

Unfortunately, the "sensible defaults" don't seem to check input URLs correctly and allow file:// URLs. Just try ?url=file:///etc/passwd on the demo instance. That seems to be a quite common issue with services like this built on generic libraries.

I've moved all my pdf to client side. Less security and processing on the server. http://pdfmake.org/#/gettingstarted

Interesting. There's jsPDF as well which is similar: https://github.com/MrRio/jsPDF

Re: URL to PDF Microservice

#33

Post by dotmanish » Thu, Oct 05, 2017, 4:40 PM UTC

edoceo wrote: post #7

See also: http://any2web.io

with no privacy policy link or info on how long the documents are stored on the server.

Stuff like receipts, etc to be converted to PDF will contain customers' information - not to be put on a site with no info on how it's used.

Re: URL to PDF Microservice

#34

Post by rocky1138 » Thu, Oct 05, 2017, 4:50 PM UTC

kimmobru wrote: post #17

erdbeerkaese wrote: post #6

Unfortunately, the "sensible defaults" don't seem to check input URLs correctly and allow file:// URLs. Just try ?url=file:///etc/passwd on the demo instance. That seems to be a quite common issue with services like this built on generic libraries.

Oh wow, that's a bit embarrassing :) The urls are now restricted to http and https only. Thanks for noticing!

Consider adding FTP.

It might be better to blacklist file:// rather than trying to have a comprehensive whitelist.

Re: URL to PDF Microservice

#35

Post by nothrabannosir » Thu, Oct 05, 2017, 4:54 PM UTC

rocky1138 wrote: post #34

kimmobru wrote: post #17

Earlier quoted context omitted.

Oh wow, that's a bit embarrassing :) The urls are now restricted to http and https only. Thanks for noticing!

Consider adding FTP. It might be better to blacklist file:// rather than trying to have a comprehensive whitelist.

Not sure if this is sound advice. Blacklisting is a cat and mouse game, especially for security. The risk of a missing entry on a blacklist is worse than on a whitelist.

Re: URL to PDF Microservice

#36

Post by maslam » Thu, Oct 05, 2017, 5:13 PM UTC

We use urlbox.io and are really happy with it. Don't recommend building this yourself.

Re: URL to PDF Microservice

#37

Post by garou » Thu, Oct 05, 2017, 5:28 PM UTC

URL or HTML to PDF: https://github.com/tecnospeed/pastor

Re: URL to PDF Microservice

#38

Post by default-kramer » Thu, Oct 05, 2017, 5:37 PM UTC

It looks like chrome's javascript interface exposes options that the command line doesn't. Or else I'm overlooking something, because I couldn't find a way to to hide the header and footer (which shows the date, title, url, and page number) using the command line. But this project does hide the header and footer.

I can't use an externally hosted service like this because some of my URLs are non-public. So when the user requests a PDF, I render the HTML to a temp file on the server, invoke chrome via command line, and serve up the converted PDF.

Re: URL to PDF Microservice

#39

Post by leesalminen » Thu, Oct 05, 2017, 5:39 PM UTC

dotmanish wrote: post #32

homero wrote: post #13

Earlier quoted context omitted.

I've moved all my pdf to client side. Less security and processing on the server. http://pdfmake.org/#/gettingstarted

Interesting. There's jsPDF as well which is similar: https://github.com/MrRio/jsPDF

Does anyone have advice on rendering wide tables (with lots of text) with this library? We have a constant cat ant mouse game with this library.

Re: URL to PDF Microservice

#40

Post by caidan » Thu, Oct 05, 2017, 5:42 PM UTC

Oddly enough I just implemented my own one of these in 34 sloc using flask and weasyprint. I chose to only have it accept html in a post rather than a url so that it could render non-publically accessible urls. You can also pass it a base_url (which it passes on to weasyprint) for resolving relative urls for static assets in the html, which are usually publicly accessible. Runs on heroku for simplicity.