Aangepast veld in IIS log heeft "-" waar voor bepaalde Paths

stemmen
0

Ik heb de volgende herschrijfregel in een ASP.NET-applicatie web.config gehost op IIS geconfigureerd:

    <rewrite>
        <rules>
            <rule name=setappname>
                <match url=.* />
                <serverVariables>
                    <set name=CONTAINER_APP_NAME value=desiredValue />
                </serverVariables>
            </rule>
        </rules>
    </rewrite>

En in applicationHost.config, heb ik de volgende fragmenten:

    <sites>
        <site name=mysite id=1 serverAutoStart=true>
            <application path=/ applicationPool=.NET v4.5>
                <virtualDirectory path=/ physicalPath=c:\mysite />
            </application>
            <bindings>
                <binding protocol=http bindingInformation=*:80: />
            </bindings>
            <logFile directory=c:\iislog period=MaxSize truncateSize=4294967295>
                <customFields>
                    <add logFieldName=x-forwarded-for sourceName=X-Forwarded-For sourceType=RequestHeader />
                    <add logFieldName=container-app sourceName=CONTAINER_APP_NAME sourceType=ServerVariable />
                </customFields>
            </logFile>
            <applicationDefaults preloadEnabled=true />
        </site>
    </sites>

EN

<system.webServer>
    <rewrite>
        <allowedServerVariables>
            <add name=CONTAINER_APP_NAME />
        </allowedServerVariables>
    </rewrite>
</system.webServer>

Dit werkt prima (ik zie de 2 aangepaste velden in de logs), behalve wanneer het pad eindigt met / (bijvoorbeeld: /of /APath/). In die gevallen is de waarde van het container-appveld (met behulp van Server Variable) is altijd -. Bijvoorbeeld:

$ curl --silent --output /dev/null -H X-Forwarded-For:10.3.2.12 http://localhost/APath/

opbrengsten:

2019-12-02 20:47:32 172.29.152.165 GET /APath/ - 80 - 192.168.7.4 curl/7.67.0 - 200 0 0 121 10.3.2.12,+::1 -

Terwijl:

$ curl --silent --output /dev/null -H X-Forwarded-For:10.3.2.12 http://localhost/home.aspx

opbrengsten:

2019-12-02 20:50:17 172.29.152.165 GET /home.aspx - 80 - 192.168.7.4 curl/7.67.0 - 200 0 0 63 10.3.2.12,+::1 desiredValue

Ik liet zelfs de Failed Request Tracing om te zien of misschien wel de herschrijfregel niet het oppakken van die paden, maar ik kan bevestigen dat de regel overeenkomt met het pad en de server variabele wordt ingesteld op de gewenste waarde.

Ik vraag me af of er iets anders ik kan proberen om deze problemen op te lossen. Waarom zulke paden zijn niet goed aangemeld?

De vraag is gesteld op 02/12/2019 om 23:58
bron van user
In andere talen...                            


1 antwoorden

stemmen
0

Ik denk dat ik vond de kwestie en te posten hier voor anderen.

Door te kijken naar het verzoek mislukt Traces, kan ik zien dat IIS creëert kind aanvragen voor standaarddocumenten directories' (URI eindigt met '/'). Blijkbaar, door het ontwerp, herschrijfregels niet van toepassing op kind verzoeken (bv: https://forums.iis.net/t/1152699.aspx ).

Om dit op te lossen, heb ik een herschrijfregel om dergelijke verzoeken te veranderen expliciete verzoeken om documenten, zodat de andere herschrijfregel wordt toegepast op het belangrijkste proces niveau:

       <rewrite>
            <rules>
                <rule name="setExplictDoc">
                    <match url="(.*(APath)/$)" />
                    <action type="Rewrite" url="{R:0}Default.aspx" />
                </rule>
                <rule name="setappname">
                    <match url=".*" />
                    <serverVariables>
                        <set name="CONTAINER_APP_NAME" value="desiredValue" />
                    </serverVariables>
                </rule>
            </rules>
        </rewrite>

Het idee kwam van https://support.microsoft.com/en-ca/help/3050055/iis-digest-authentication-does-not-permit-pass-though-authentication-f

antwoordde op 03/12/2019 om 01:16
bron van user

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more