2010-06-30 8 views
0

J'ai utilisé le contrôle "OpenIdTextBox" de DotNetOpenAuth sur notre page de connexion. Nous avons utilisé VS 2008 + .NET 3.5 + Ajax UpdatePanel sans aucun problème.DotNetOpenAuth avec Ajax sur Visual Studio 2010 .NET 4 problème

Aujourd'hui, nous avons essayé de mettre à niveau l'ensemble du projet pour VS 2010 + .NET 4.0, l'Ajax UpdatePanel me donne une erreur javascript quand il redirige vers le fournisseur (comme Google) pour vous connecter.

« Sys. WebForms.PageRequestManagerParserErrorException: Le message reçu du serveur n'a pas pu être analysé Les causes courantes de cette erreur sont lorsque la réponse est modifiée par les appels à Response.Write(), les filtres de réponse, HttpModules ou la trace du serveur est activée. Y at-il des paramètres que je peux faire ce travail? La chose étrange est ... cela a fonctionné sur VS 2008 + .NET 3.5. Merci ....

Répondre

1

Je ne sais pas comment le UpdatePanel fonctionne, mais le contrôle OpenIdTextBox doit pouvoir rediriger l'ensemble du document du navigateur vers une autre URL, ce que UpdatePanel ne permet peut-être pas car il attend seulement une réponse de contenu mettre à jour une petite zone de la page Web. Alors peut-être OpenIdTextBox est fondamentalement incompatible avec UpdatePanel - juste une supposition.

Je me demande si vous pouvez choisir d'une manière ou d'une autre côté serveur lors du traitement de la page pour désactiver les optimisations de UpdatePanel, si par exemple l'événement OpenIdTextBox_LoggingIn a été déclenché.

Sinon, bien sûr, vous pouvez déplacer la zone de texte en dehors du UpdatePanel, mais peut-être que cela ne peut pas être fait tout en conservant l'apparence de la page web yoru.

Je pourrais vous dire comment surcharger la façon dont OpenIdTextBox redirige la page Web, mais tout ce que vous pourriez faire d'équivalent rencontrerait probablement le même problème.

+0

Salut Andrew .. Oui, si vous pouvez me dire comment surcharger la redirection OpenIdTextBox s'il vous plaît? ce serait utile .. vraiment apprécié cela. – userb00

+0

Substituez l'événement LoggingIn et définissez 'e.Cancel = true' pour empêcher le contrôle d'effectuer la redirection. Vous pouvez ensuite utiliser les informations contenues dans 'e.RedirectingResponse' pour effectuer vous-même la redirection. Soyez prudent cependant. Ce n'est * pas * toujours juste un simple redirection 301 avec une URL. Ce 'RedirectingResponse' peut inclure un FORMULAIRE HTML d'auto-publication pour les demandes d'authentification extra-larges. Vous devez donc envoyer * toutes * les données de cet objet au client pour être fiable. –

+0

Merci Andrew !!! – userb00

0

Merci Andrew! Cela a fonctionné (je réponds à mon propre poste). Fondamentalement, j'ai résolu ce problème Ajax en utilisant "Response.RedirectLocation".

Selon certains articles, il s'agit d'un appel amical Ajax pour certaines raisons, je ne sais pas exactement quelle est la différence parce que je suppose que "e.Request.RedirectingResponse" fait la même chose. Quoi qu'il en soit, j'ai ensuite extrait l'emplacement de l'en-tête "RedirecingResponse". J'ai testé avec 8 fournisseurs, cela semble fonctionner!

e.Cancel = true; 
OutgoingWebResponse webResponse = e.Request.RedirectingResponse; 
string location = webResponse.Headers["Location"]; 
Response.RedirectLocation = location; 
Questions connexes