-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
[BUG] Cannot run Playwright via shell from IIS #5197
Comments
@minusdavid I remember there were some user permissions that have to be configured in IIS. In this case, it looks like the user that runs the service has very limited access, so subprocess can't do much. As a result, launched Chromium cannot access libraries required for its operations. Here's some documentation regarding this: https://docs.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/access-denied-run-batch-job +cc @kblok in case Darío happens to know more about this |
Thanks @aslushnikov but it's not clear what needs the permissions. If I shell out to launch chrome.exe itself (with minimal parameters in headless mode), I have no problems. If I shell out to launch Puppeteer, I have no problems. It's just Playwright. All with the same IIS user. So I figure Playwright must be activating some functionality in Chrome which needs higher permissions. I'm not very familiar with the Chromium codebase, but my guess is that Playwright is activating some security mechanism - or the newer version of Chromium (v90) it uses has higher security requirements than the one used by Puppeteer (v88) and the vanilla Chrome (I can't recall the version but it'll be high 80s). |
I'm not sure if my issue is related, but it looks like having same nature. I'm not running it in IIS, but it is executed remotely by Powershell.
It started to happen on the new PW1.8.0, switching back to 1.6.2 solves the problem. My user |
Oh that's really interesting @creage! |
I found an interesting solution, that might work - I'm about to try it out. UPDATE: no, this didn't work |
In my case, I looked at line 70 of https://chromium.googlesource.com/chromium/src/+/master/components/os_crypt/os_crypt_win.cc, which got me looking at DPAPI. Then my Googling led me to https://blog.dotsmart.net/2011/01/26/solved-windows-identity-foundation-the-system-cannot-find-the-file-specified/ but changing "Load User Profile" to true didn't really make a difference. https://bugs.chromium.org/p/chromium/issues/detail?id=1000799 makes me think that DPAPI is being used for encrypting cookies? Yet I don't have the problem with Puppeteer or chrome.exe directly... |
Guessing that this is the right documentation for CryptProtectData... https://docs.microsoft.com/en-us/windows/win32/api/dpapi/nf-dpapi-cryptprotectdata This part is interesting: "Typically, only a user with logon credentials that match those of the user who encrypted the data can decrypt the data." My IIS user wouldn't have logon credentials... Looking at https://security.stackexchange.com/questions/51779/securing-an-iis-application-with-a-complex-configuration, it talks about how my virtual user account will likely have troubles unless I switch to the "NetworkService" identity or use "LoadUserProfile" (although they're skeptical about the latter and I've had no luck with the latter anyway...) ...but... this doesn't explain why it works with Puppeteer and Chrome and not Playwright... |
I should've looked more closely at that stack trace. That 'OSCrypt::Init(local_state_.get())' was just added to Chromium about 1 week ago. It looks like @dgozman wrote that patch. |
So that explains why it's only happening with Playwright. It's the only thing using a new enough Chromium to be a problem heh. Maybe I'll play more with LoadUserProfile as per https://stackoverflow.com/questions/57061345/cryptprotectdata-fails-with-error-file-not-found-when-the-user-profile-is-not. Maybe I wasn't thorough enough in my experiments. This might help as well... Trying to find the source code for CryptProtectData but I'm guessing it's closed source as all I can find is the API in dpapi.h and a not so helpful Wine implementation. @aslushnikov, you work at Microsoft now, yeah? Maybe you have a colleague who can comment more on the inner workings of that function? |
I don't have much time to spend playing on this one. Since it's working with Puppeteer, I'm just going to use that for the time being, but this really seems like a ticking time bomb. It'll catch out Puppeteer eventually too. Of course, it seems like an issue with Chromium rather than Playwright at this point. I'll try to find some time to play with LoadUserProfile more and maybe Playwright could add some documentation about it if I get it working... I suppose one thing Playwright might consider doing is dropping the version of Chromium used by Playwright, but that's a short-term solution too. Anyone else have any other thoughts on this one? I'm going to call it a night. |
Folks, this is an impressive investigation!
@minusdavid I guess you refer to the https://chromium-review.googlesource.com/c/chromium/src/+/2634681, but that was actually just a code move and should not have changed. Do you think you can help me reproduce this locally on my win machine? Once we can reproduce, we'll be able to fix it upstream. I'll appreciate if you can lead me to setup IIS with a minimal script that reproduces the problem! |
Thanks, Andrey. Apologies for the stream-of-consciousness, but hopefully it was helpful. Ooops, I thought that I had included the commit reference. I was looking at https://chromium.googlesource.com/chromium/src/+/4fbc172e7c66f520a630875ff68de5ff0c764428 but yeah that code review is for the one. I noticed it was a code move, but I was guessing that the code in headless_content_main_delegate.cc must be run later or in a child process or something like that. Hmm, I can certainly try! I'll admit that I'm much more familiar with Linux and tend to use Docker containers for this type of scenario. I'm tempted to try "Windows Sandbox" to see if I can create a temporary reproducible Windows environment. |
Alas, there's seemingly no way of enabling "Internet Information Services" inside Windows Sandbox. That's a let down... |
On my Windows workstation, I use Docker Desktop and WSL 1, which are backed using Hyper-V. It looks like Hyper-V has an easy "Windows 10 dev environment" option. It's a 18.30GB download, but I'm going to give that a go. |
Get Windows environment
Setup IIS
Install PHP
And... it's failing to install. Probably because it's a dev image. I found this link to do it manually but I don't have the stamina to do it after a full work day (https://docs.microsoft.com/en-us/iis/application-frameworks/scenario-build-a-php-website-on-iis/configuring-step-1-install-iis-and-php#13-download-and-install-php-manually) At the end of the day, all you need is IIS, PHP, and Node.js. You could probably substitute PHP for something else that can shell out. |
I've tried playing more with LoadUserProfile. It actually broke things for Puppeteer until I changed the permissions for the user created*... but still broken for Playwright. Changed from ApplicationPoolIdentity to NetworkService for the Application Pool, and now getting different permission issue. *It seems that the ApplicationPoolIdentity is a virtual user based on the application pool name, but the site is actually set up to "Connect as" a real non-login system user. I could only get Puppeteer working with LoadUserProfile when I allowed the real user access to the C:\Users\TEMP folder created by Puppeteer as the virtual user. |
Even when I'm using pass through authentication and the default application pool, I get the same issue. Here's the full log:
|
Anyway, worked way too much on this tonight... |
Provided you can install IIS, PHP, and Node.js, here's the code that should reproduce the problem: PHP:
Node.js:
|
Filed upstream: https://bugs.chromium.org/p/chromium/issues/detail?id=1173214 Chromium friends promised to push a fix! |
Thanks so much @aslushnikov ! You're a champion! (As are your Chromium friends!) |
Wow, the Chromium folk work fast! They've already written, reviewed, and pushed a patch to master: https://chromium-review.googlesource.com/c/chromium/src/+/2665975 I don't think it's been added to a stable release yet. What's the process for updating Playwright's Chromium revision? It seems that Playwright stays quite current, so I imagine once there is a build available that you folk will then look at taking it up? Really impressed with how quickly everything has gone. Once this issue is resolved, I reckon that I'll switch back to Playwright from Puppeteer :D. |
I'm not familiar with the Chrome build numbers but I see that patch in the 90.0.4408.0 version for Chromium. I'm guessing its available now? |
We'll roll Chromium soon'ish (in a few days), and the fix will be available at |
Thanks, @aslushnikov . I'm excited. I'm trying to promote Playwright for use on some of my projects, so looking forward to switching back to it. |
I just tried updating playwright but still had the same problem, but I can see now that playwright 1.8.1 is still too old (7 days old). I'm guessing this fix will be in playwright 1.8.2? |
|
I'd just like to say that I've installed 1.9.1 and it's working as expected. Thanks @aslushnikov and everyone else who helped to make this happen. |
Context:
Code Snippet
Describe the bug
In IIS 8, I'm shelling out from PHP to run "node index.js", but I'm getting the below fatal error.
It looks like an issue related to DPAPI, so I tried setting IIS to load a user profile, but that didn't make a difference. I've read through the Chromium source code a bit, but I'm not sure how the problem traces back.
It's worth noting that replacing Playwright with Puppeteer solved the problem. Puppeteer has no problem. It looks like Playwright uses a newer version of Chromium than Puppeteer, so that may be related, or it may be that Playwright is enabling/disabling a switch that Puppeteer doesn't.
The text was updated successfully, but these errors were encountered: