2010-11-25 21 views
2

J'utilise WPF WebBrowser pour afficher de l'aide en ligne dans une application (juste quelques petites pages Web). Certaines de ces pages utilisent des cookies pour afficher les éléments uniquement pour les premières fois que les pages sont consultées (c'est un type de "Pourquoi ne pas essayer X"). Toutefois, pour une raison ou une autre, les cookies ne semblent pas fonctionner dans le contrôle WebBrowser. Ils fonctionnent bien dans IE complet ainsi que Firefox et Chrome (donc les éléments se cachent correctement), mais ils ne se cachent jamais lorsqu'ils sont vus à travers le contrôle WPF WebBrowser.Cookies persistants dans le contrôle WPF WebBrowser?

Y a-t-il quelque chose de spécial à propos de l'utilisation de cookies dans le contrôle WPF WebBrowser? Il semble se comporter comme si tous les cookies ne sont stockés en mémoire, plutôt que d'être conservés sur le disque.

est ici l'une de ces pages dans un navigateur (où les cookies fonctionnent):

Help pane inside a browser

Et voici exactement la même page dans l'application:

Help pane inside the application

Ce contenu supplémentaire ne devrait être visible que pour les premières utilisations du logiciel (c'est-à-dire qu'il devrait être caché après N vues de cette page web), mais parce que je ne peux pas faire fonctionner les cookies, c'est toujours visible.

Répondre

6

Cookies Gestion dans Internet Explorer (ou versions hébergées) est liée à la propre notion de "URL des zones de sécurité" de l'IE, doc ici: About URL security Zones

Ainsi, IE détermine une zone d'URL en utilisant différents alogorithms appliqués à l'URL . Selon la zone, votre navigateur hébergé peut ou non prendre en charge les cookies de session ou persistants. Bizarrement, lorsque je crée un petit échantillon WPF, ajoutez-y le navigateur Web et naviguez jusqu'à cette page d'utilisation du testeur de cookie persistant: http://www.rbaworld.com/Security/Computers/Cookies/givecook.shtml, cela fonctionne très bien. Chaque fois que je lance l'exemple d'application, le compteur est incrémenté correctement, donc tout le monde ne peut pas reproduire votre problème. Eh bien, c'est tout le but des zones de sécurité URL: cela peut varier selon la machine, l'utilisateur, la politique de Windows, etc ...

La question suivante est: Puis-je changer la zone dans laquelle vous courez? La réponse courte et facile est ... non parce que c'est fortement lié à la sécurité.

Si vous hébergez IE vous, vous pouvez mettre en œuvre votre propre poignée de zone de sécurité comme décrit ici: Implementing a Custom Security Manager et un échantillon ici: SAMPLE: Secumgr.exe Overrides Security Manager for WebBrowser Host mais vous comptez sur le navigateur Web de WPF qui ne permet pas de dérogation ... Vous pouvez obtenir à Reflector et copier tout le code privé/interne de WPF mais c'est un journal de travail risqué!

La dernière chose que vous pouvez essayer est de manipuler le standard Internet Security Manager. Voici un exemple de code qui donne quelques indices.Vous devriez au moins pouvoir déterminer la zone dans laquelle vous vous trouvez (MapUrltoZone) et changer le cookie (TryAllowCookie). Le problème avec le gestionnaire est la norme la plupart du temps, il apparaît en boîte de dialogue à l'autorisation permettant l'utilisateur final ... (sécurité à nouveau!):

[ComImport, Guid("7b8a2d94-0ac9-11d1-896c-00c04Fb6bfc4")] 
private class InternetSecurityManager 
{ 
} 

[ComImport, InterfaceType(ComInterfaceType.InterfaceIsIUnknown), Guid("79eac9ee-baf9-11ce-8c82-00aa004ba90b")] 
private interface IInternetSecurityManager 
{ 
    void Unused1(); 
    void Unused2(); 
    [PreserveSig] 
    int MapUrlToZone([In, MarshalAs(UnmanagedType.BStr)] string pwszUrl, out int pdwZone, [In] int dwFlags); 
    void Unused3(); 
    [PreserveSig] 
    int ProcessUrlAction(string pwszUrl, int dwAction, ref int pPolicy, int cbPolicy, ref Guid pContext, int cbContext, int dwFlags, int dwReserved); 
    // left undefined 
} 

public static SecurityZone MapUrlToZone(Uri uri) 
{ 
    IInternetSecurityManager securityManager = (IInternetSecurityManager)new InternetSecurityManager(); 
    int zoneId; 
    if (securityManager.MapUrlToZone(uri.ToString(), out zoneId, 0) < 0) 
     return SecurityZone.NoZone; 

    return (SecurityZone)zoneId; 
} 

private const int URLACTION_COOKIES = 0x00001A02; 
private const int URLACTION_COOKIES_ENABLED = 0x00001A10; 
private const int URLPOLICY_ALLOW = 0x00; 
private const int URLPOLICY_DISALLOW = 0x03; 
private const int PUAF_DEFAULT = 0x00000000; 

public static bool TryAllowCookies(Uri uri) 
{ 
    IInternetSecurityManager securityManager = (IInternetSecurityManager)new InternetSecurityManager(); 
    int policy = 0; 
    Guid context = Guid.Empty; 
    int hr = securityManager.ProcessUrlAction(uri.ToString(), URLACTION_COOKIES_ENABLED, ref policy, Marshal.SizeOf(policy), ref context, Marshal.SizeOf(context), PUAF_DEFAULT, 0); 
    return (hr == 0) && policy == URLPOLICY_ALLOW; 
} 

Bonne chance :)

+0

Merci, cela semble être un bon point de départ. – Wilka

0

Le contrôle WebBrowser ne le permet pas par défaut. Pour des raisons de sécurité, vous ne voudriez probablement pas que différentes applications de différents développeurs/entreprises puissent accéder aux informations de cookie créées par une autre application.

Cependant, consultez cette réponse How to delete Cookies from windows.form?

qui a trait à la suppression des cookies par javascript, mais vous pouvez être en mesure d'utiliser une méthode similaire pour persister et créer le cookie du site chaque fois que l'application est chargée.

+0

Je ne comprendre cette réponse. Le cookie n'est-il pas lié à la page, plutôt qu'à l'application? C'est la page qui définit le cookie. L'application est complètement passive. –

+0

J'ai mis à jour la question pour mieux illustrer ce que j'essaie de réaliser ici. Les cookies ne sont pas mis en caisse par l'application, ils sont tous créés sur le serveur. L'application affiche simplement les pages Web. – Wilka

+0

Correct, le serveur crée les cookies, mais ils sont ensuite stockés par le navigateur côté client après chaque requête. Le contrôle WebBrowser ne permet pas le partage/stockage de ces cookies par la suite. – rossisdead