|
RUN apt-get update \
&& apt-get install -y --allow-unauthenticated \
libc6-dev \
libgdiplus \
libx11-dev \
curl \
vim \
supervisor \
procps
|
Hello all, just FYI update. This thread put me on track to solve this spinning load icon when I take my app from dev to production.
I am running Blazor SfPdfViewerServer on .Net Core 3.1 app with IIS on Win Server 2022. Had this same spinning icon, soon as I published. I just had to give my application pool identity write access to my Application folder on the IIS Server. See the attached screenshot. You just need to look for the security account named the same as your application pool (EIT_Drawings in my case), see below:
Last note - thanks for a great product Syncfusion. Your tutorials combined with your forums are fantastic. It's appreciated, please keep it up.
Hi Dieter,
Thank you for the update. Please let us know if you need any further assistance.
Regards,
Vasugi.
Hi Syncfusion team,
I also had the same problem with the infinite spinning load icon when deployed to IIS.
Quote from Akshaya above:
"We have embedded the Pdfium rendering engine in our PDF Viewer for robust rendering, so Pdfium will be generated on runtime within your project location. So kindly provide read and write access to your project location."
In a production environment, I do not want to grant write permissions for the account running the IIS application pool and I believe this would be a security issue. For instance, if the application were to be compromised in an attack, the attacker could change files or write files into the application directory for execution and that could be a big problem.
I see at runtime there is a directory named x64 gets created and that contains the file pdfium.dll
I would like to deploy all of the required files at deploy time without the need to grant write permissions in order for the application to write the Pdfium files at runtime.
Could the Syncfusion.Blazor.PdfViewerServer.Windows NuGet package be altered accordingly to include pdfium.dll in so that it does not need to be generated at runtime?
Regards,
Dennis
Hi Dennis,
We have the plan to include the Pdfium within the PDFViewer to avoid such issues. But due to the package size, we are avoiding this.
However, We will provide feedback regarding the reported issue tomorrow.
Regards,
Visvesvar K V
Hi Dennis,
Kindly find the feedback below for the reported issue. we don’t have any immediate plans to implement it now. However, It will be implemented in any of our upcoming volume releases.
Feedback : PDFIUM must be integrated in to the PDF Viewer | Feature Feedback
Regards,
Visvesvar K V
Hi Visvesvar,
Thanks for adding the feedback item. However, I am concerned that there is no immediate plan to implement a fix if the requirement poses the security risk I have identified.
Are you able to provide any workaround solutions that we could use to avoid giving the application write access to the application files? Would it be okay if we manually deploy the x64 directory including the file pdfium.dll ?
Regards,
Dennis
Hi Dennis,
Thank you for your update.
We are analyzing your reported query and we will update further details on 26 Oct, 2022.
Regards,
Visvesvar K V
Hi Dennis,
Thank you for your patience.
As we already mentioned we don’t have support to include pdfium.dll with our PDF Viewer, Also we could not provide any workaround solution to include the pdfium along with PDF Viewer.
As of now, you could deploy the pdfium dll manually. We will update once the feature has been implemented.
Regards,
Visvesvar K V
Hi Visvesvar,
Thanks for the update. I will try to deploy pdfium.dll manually and report back for anyone following.
Can you please advise what happens now. Is pdfium.dll embedded in one of your dll files and then extracted at runtime, or is it downloaded at runtime?
Regards,
Dennis
Hi Dennis,
Thank you for your update. Kindly check and revert to us.
If pdfium.dll is embedded in one of your dll files it will get extracted dynamically and it will not get downloaded.
Regards,
Visvesvar K V