拒绝访问在 S3 AWS 存储桶上公开的 css 文件

Question

So I have a Django application running on a docker container, on AWS EC2. The static content is hosted on an S3 bucket (css, javascript, etc.). This all works fine.

I did implement a PDF output for some files using weasy print. Locally, it produces the expected PDF fine. However on the server, I get a 500 error. Upon closer inspection, the following error popped in the django logs that I have added to my decorator (that is responsible for generating the PDF). The decorator decorates some handle that is called, and the produced PDF shows up in the download folder.

A decorated handler:

@generate_pdf_httpresponse
def handler_warehouse_packingslip(request, **kwargs):
    id = kwargs.get("pk")                                   
    context = { .... details to provide to print.... }
    filename = "foo.pdf"
    infos = {"context":context, "template_path":'projectlibs/pdf_outputs/pdf_base.html', "extra_css_files":[], "filename":filename,"request":request}
    return infos

The decorator:

def generate_pdf_httpresponse(func):
    @functools.wraps(func)
    def wrapper_generate_pdf_httpresponse(*args, **kwargs):

        try:
            logger.info(f"Wrapper for pdf response")
            value = func(*args, **kwargs)
            html_string = render_to_string(value.get("template_path"), context=value["context"])
            html = HTML(string=html_string, base_url=value["request"].build_absolute_uri())
            css_files = []
            pdf = html.write_pdf(stylesheets=css_files)
            logger.info(f"Creating tmp file for pdf response")
            with tempfile.NamedTemporaryFile() as file:
                file.write(pdf)
                file.seek(0)
                stream = file.read()
            httpresponse = HttpResponse(content_type='application/pdf;', content=stream)
            httpresponse['Content-Disposition'] = f'attachment; filename={value["filename"]}'
            httpresponse['Content-Transfer-Encoding'] = 'binary'
            return httpresponse
        except Exception as ex:
            logger.error(f"PDF wrapper failed: {ex}")
    return wrapper_generate_pdf_httpresponse

Which yields this error (on aws):

27/12/21 14:03:43 INFO DEFAULT: Wrapper for pdf response
27/12/21 14:03:43 INFO DEFAULT: Request to print packing skips warehouse.... 
27/12/21 14:03:43 ERROR DEFAULT: PDF wrapper failed: Attempted access to '/css/pdf2.css' denied.

But that file is public - I can access it directly from a web (https://<my_s3_bucketname>.s3.amazonaws.com/static/css/pdf2.css). The main stylesheet I use is also available there, referenced by the same tags & works fine.

Eg this works fine:

<link rel="stylesheet" type="text/css" href="{% static 'css/mystyle.css' %}">

But not this:

<link href="{% static '/css/pdf2.css'  %}" rel="stylesheet" type="text/css" >

So.... where/how should I troubleshoot this?

Checked:

• pdf2.css exists under the static s3 bucket (and it's an access denied, not a not found)
• if I change the css file referenced from the template (that is used to create the pdf), then I also get denied. So it seems that my application trying to reach the css from the decorator is what causes the issue, somehow.

Answer 1

So, I haven't managed to find an actual answer to the initial question (someone wrote a comment to the effect that the css files wasn't served from the S3 bucket in the pdf case, but I didn't fully understand what he meant and he deleted the comment).

However, one change that does work is to replace the in-template css link, and shifting that to weasy-print. From the code above:

from django.conf import settings
css_files =  [ f"{settings.STATICFILES_DIRS[0]}/css/pdf2.css"]

assuming properly set STATICFILES_DIRS in settings.py

Then remove the <link href="{% static '/css/pdf2.css' %}" rel="stylesheet" type="text/css" > .

Then, since weasy print fetches the actual file locally (eg from the EC2 instance, under its static folder), then it works. I guess since that's also committed to git from the same pipeline (eg collecstatic etc.), it's a decent solution from a devops perspective, doesn't require special cases steps/configs.