Champ personnalisé dans le journal IIS a « - » pour la valeur de certains chemins

voix
0

J'ai configuré la règle de réécriture suivante dans un « web.config » de l'application ASP.NET hébergé sur IIS:

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

Et dans « applicationHost.config », j'ai les extraits suivants:

    <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>

ET

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

Cela fonctionne bien (je vois les 2 champs personnalisés dans les journaux) , sauf lorsque les extrémités de chemin avec « / » (par exemple: /ou /APath/). Dans ces cas, la valeur du container-appchamp ( en utilisant la variable de serveur) est toujours « - ». Par exemple:

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

rendement:

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 -

Tandis que:

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

rendement:

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

J'ai même permis la requête a échoué Tracing pour voir si peut-être la règle de réécriture n'est pas ramasser ces chemins, mais je peux confirmer que la règle correspond au chemin et la variable du serveur est défini sur la valeur souhaitée.

Je me demande s'il y a quelque chose que je peux essayer de résoudre ce. Pourquoi ces chemins ne sont pas enregistrés correctement?

Créé 02/12/2019 à 23:58
source utilisateur
Dans d'autres langues...                            


1 réponses

voix
0

Je pense avoir trouvé la question et l'afficher ici pour d'autres.

En regardant les traces de demande a échoué, je peux voir que IIS crée enfant demande pour les documents par défaut de répertoires (se terminant par des URIs « / »). Apparemment, par la conception, règles de réécriture ne sont pas applicables aux demandes de l' enfant (par exemple: https://forums.iis.net/t/1152699.aspx ).

Pour résoudre ce problème, j'ai créé une règle de réécriture de modifier ces demandes comme des demandes explicites aux documents que l'autre règle de réécriture soit appliquée au niveau principal du processus:

       <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>

L'idée est venue de https://support.microsoft.com/en-ca/help/3050055/iis-digest-authentication-does-not-permit-pass-though-authentication-f

Créé 03/12/2019 à 01:16
source utilisateur

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