Bij TRES waren we al bekend met Playwright, collega Richard van der Meer heeft een tijd geleden onderzocht wat je ermee kunt en de conclusie was dat het een geweldige tool is. Kort gezegd is het een tool waarmee je kunt testen, je kunt tig scenario's laten doorlopen waarmee je voornamelijk het UI-gedeelte test. Iets wat je tot nu toe eigenlijk alleen nog maar handmatig kon doen. Ook screenshots, zodat je kunt zien dat met bepaalde invoer ergens iets over een invoerveld heen valt en je dus niets in kunt vullen: een situatie die je nu van tevoren kunt laten testen en fixen voordat een bezoeker van de site er op vast loopt.
Playwright wordt ook in combinatie of als onderdeel van andere tools gebruikt. Een voorbeeld daarvan is het Umbraco sustainability package gemaakt door Rick Butterfield. De releases kun je hier vinden: Github-link. Je kunt met die plug-in in Umbraco testen hoe "zwaar" een pagina is. Het is een kwestie van een browser openen, HTML en een paar javascript-bestanden inladen, het javascript geeft de benodigde waardes terug.
Maar "server-side even een browser openen", dat doe je niet zo maar even. Rick heeft daarvoor Playwright gebruikt en op zich werkt dat prima.
Probleem: rechten van de IUSR
Ik zei dat het "op zich prima werkt". Dan bedoel ik dat je als ontwikkelaar op je machine in Visual Studio (Code) werkt en de website opstart. Dan gebeurt hetzelfde als op de "echte webserver", namelijk de installatie van Playwright wordt uitgevoerd, de browsers die "onder water het werk doen" worden geïnstalleerd. Het uitvoeren van die browsers, dat gebeurt met NodeJS en daarbij liepen we tegen een probleem aan. In de NodeJS-code zit namelijk een controle, als je de website op een Windows-machine opstart, dan wordt gecontroleerd of de schijf waarvandaan je NodeJS opstart "wel bestaat". Dus staat je site op F:\websites\klant1-site1 dan wordt gecontroleerd of de F-schijf wel bestaat.
Als je als developer op je machine de website opstart (en dus met jouw rechten dat doet), dan is dat geen probleem, er wordt geconstateerd dat de schijf bestaat en je code gaat vrolijk door.
Op de productiewebserver werkt het iets anders. Tenminste, als het een "shared server" is, dus je hebt ook nog een F:\websites\klant2-site1, F:\websites\klant3-site1, enzovoort. Elke website draait onder een eigen gebruikersaccount. En dat gebruikersaccount mag alleen maar in die eigen map acties uitvoeren. Dat is zoals het hoort, want anders loop je het risico dat als er wat fout gaat, iemand vanuit klant3-site1 bestanden zou kunnen aanpassen of verwijderen bij klant2-site1. Als je de plug-in installeert wil de website niet meer opstarten. Want de controle of de F-schijf wel bestaat geeft een exceptie, jij mag/kan niet controleren of de F-schijf wel bestaat, jouw account heeft geen rechten.
Nog wel even de aanvullende opmerking, dit geldt dus alleen voor Windows! Deze controle zit niet in het Linux-deel van NodeJS. Umbraco draait inmiddels op .NET Core, wat het ook geschikt maakt om op Linux te draaien. In tegenstelling tot Windows is Linux case-sensitive, dus Header.cshtml is een ander bestand dan header.cshtml.
Als je een site hebt die je volledig voor Windows ingericht hebt, is het omzetten naar een Linux-variant niet altijd appeltje-eitje. Naast dit kleine letter/hoofdletter-probleem zit je ook met systeemverwijzingen. Deed je acties op het file-system en deed je dat in Windows met .\map\bestand.jpg , in Linux ga je naar ./map/bestand.jpg.
Afhankelijkheden van Framework bibliotheken moet je dan ook verwijderen/herschrijven/bijwerken. En zo zul je nog wel meer zaken tegenkomen die niet meer werken en aangepast moeten worden.
Het probleem komt vaker voor en is online te vinden, op de Github van Playwright: link en op de Github van Node: link.
Oplossing 1: geeft de IUSR wel rechten op de F-schijf. Verplaats de sites per klant naar een eigen dedicated webserver.
We liepen tegen dit probleem aan, na ons uitzoekwerk kwamen we tot deze conclusie. En ook tot de conclusie dat als we de IUSR wel rechten op de root zouden geven (en op de eigen website-mappen), maar niet op de andere submappen, dat de website dan wel zou moeten werken. Dat was de theorie, dus op een testserver hebben we deze actie uitgevoerd en zagen inderdaad dat het daarna wel werkte. Maar dit is een configuratie die je absoluut niet wilt op een shared server. Als de webserver alleen voor deze klant is zou dit voor ons (en waarschijnlijk ook de klant) acceptabel zijn.
Maar goed, is dit een oplossing? Want sustainability wordt steeds belangrijker, als straks alle klanten deze plug-in willen, dan zouden we allemaal losse dedicated webservers moeten opzetten voor onze klanten. Dat betekent ook dat de prijs omhoog schiet (de server die je deelde met klanten, daar kon je het totaalbedrag naar rato aan de klant facureren, maar nu komen de volledige kosten per server op de rekening van één klant).
Oplossing 2: zorg dat je file-system naar een andere map gerouteerd wordt
Deze oplossing kwam in mij naar boven toen ik vrijdag 30 augustus een rondje om liep om op mijn dagelijkse 10.000 stappen te komen. Want als je ervoor zou kunnen zorgen dat als je dit draait vanuit webapplicatie F:\websites\klant1-site1 en de NodeJS gaat valideren of F:\ wel bestaat en je die call kunt omleiden naar F:\websites\klant1-site1, dan zou het ook moeten werken. In die map heeft jouw IUSR namelijk wel rechten en de map bestaat.
De vraag is, kan en mag dit ook in Windows? Want het is een beetje tricky. Je wilt alleen de root van F: laten verwijzen naar F:\websites\klant1-site1, maar dat betekent ook dat als je wel iets met "parent-paths" zou kunnen doen, je daar niet meer bij kunt komen. En bij mijn zoektocht naar deze mogelijkheid kom ik ook niet echt oplossingen tegen.
Maar dan loop ik tegen iets anders aan. Je hebt in Windows namelijk het commando subst. Daarmee kun je aan een drive een map koppelen. Dus je gaat voor een nog niet in gebruik zijnde drive-letter en koppelt daar die F:\websites\klant1-site1 aan. In je configuratie geef je die die drive aan als locatie voor Playwright en het zou moeten werken.
Oplossing 2: Proof of Concept
Tijd om uit te zoeken of dit theoretische verhaal ook in de praktijk gaat werken. Als je als developer op je eigen machine Admin bent kun je zelf (als het goed is) ook lokale gebruikers aanmaken. En mocht dat niet zo zijn, vraag dan even je systeembeheerder of hij dat voor je kan regelen (of die gebruiker voor je aan kan maken). Of je doet het lekker op je eigen computer waar je alles op mag doen ;)
- Start op je computer Computerbeheer.
- Onder Systeemwerkset staat Lokale gebruikers en groepen.
- Daar maak je een nieuwe gebruiker aan. Voor het gemak geven we die de naam playwright en deze geef je een goed wachtwoord (en deze sla je op, want die heb je later nodig). Zet alleen een vinkje bij "Wachtwoord verloopt nooit".
- Maak een nieuw Umbraco-project. Instructies gevolgd van de website: link.
dotnet new install Umbraco.Templates::13.*
-- .NET 8 geïnstalleerd, zowel SDK als de runtime. Let op, (ook) de hostingbundle, anders werkt IIS niet
https://dotnet.microsoft.com/en-us/download/dotnet/8.0
-- in IIS een nieuwe site umbraco.local gemaakt, deze verwijst naar c:\inetpub\umbraco127.0.0.1 umbraco.local
-- in het bestand c:\windows\system32\drivers\etc\hosts de entryaangemaaktIIS_IUSRS
-- in het visual studio project een publish profile aangemaakt, naar map en naar deze c:\inetpub\umbraco laten publiceren
-- geef op de map c:\inetpub\umbraco nog even alle rechten aan
-- misschien nog even een IIS reset en je zou het installatiescherm op http://umbraco.local moeten krijgen!
- Inloggen in Umbraco, document-type aanmaken, template bewerken, rechten goed zetten (mag als root aangemaakt worden) en een rich-text editor erop plaatsen. Mocht je niet weten wat ik hiermee bedoel, dit zijn de basisstappen van Umbraco, dus dat ga ik hier niet uitleggen. Hiervoor kun je beter door de documentatie van Umbraco gaan en de voorbeelden volgen (creating a basic website).
- Je maakt een pagina aan en bij die pagina krijg je na opslaan een knop "Sustainability". Daarmee kun je de test uitvoeren en dat zal goed gaan omdat je nu nog als "jou" met volledige rechten dat mag en kan doen.
- Ga in IIS naar de applicatiepool van de site, klik er met de rechter muisknop op en kies voor Geavanceerde instellingen...
- Bij veld Id zal de "ApplicationPoolIdentity" gekozen zijn, klik op "Aangepast account", klik op de knop Instellen en voer daar de gegevens in van jouw gebruiker met gebruikersnaam playwright en het bijbehorende wachtwoord.
- Voer een iisreset uit, dan weet je zeker dat je "opnieuw begint". Log weer in Umbraco in, ga naar je pagina en klik op de knop "Sustainability".
- Ik heb nog wat extra's moeten doen om de playwright-user expliciet rechten te weigeren op de hoofdmap. Want ik zie dat nu namelijk "gewoon" een map ms-playwright op de C:-schijf aangemaakt wordt, niet de bedoeling!
- Vanuit Visual Studio zaken opstarten gaat goed, maar in IIS krijg ik nog steeds de melding dat lstat op C:\ geweigerd is. Schijnbaar wordt niet de Z:\ maar alsnog de originele C:\ opgepakt.