2009-03-16 9 views
2

Cette question a été un peu touchée avant mais pas la réponse que je recherchais. J'utilise le module de réécriture d'URL IIS7 pour réécrire mes pages, et maintenant mon formulaire de connexion asp.net ne fonctionne pas !!!IIS7 réécriture d'URL avec ASP.Net 3.5 SP1 + asp: Le formulaire de connexion ne fonctionne pas

Sur ma page principale que j'ai cette (fonction ASP.Net 3.5 SP1) ...

if (!String.IsNullOrEmpty(Request.ServerVariables["HTTP_X_ORIGINAL_URL"])) 
    { 
     form1.Action = Request.ServerVariables["HTTP_X_ORIGINAL_URL"]; 
    } 

Ce qui rend le poste de page retour à la page actuellement réécrite.

Cependant, mon contrôle de connexion ne fait que publier des retours sans déclencher d'événements. Par conséquent, il ne se connecte pas, les événements onlogginerror etc ne tirent pas, rien!

J'ai essayé ce ...

if (!String.IsNullOrEmpty(Request.ServerVariables["HTTP_X_ORIGINAL_URL"])) 
    { 
     Login Login1 = LoginView1.FindControl("Login1") as Login; 
     if (Login1 != null) 
      Login1.DestinationPageUrl = Request.ServerVariables["HTTP_X_ORIGINAL_URL"]; 
    } 

vec vain ...

S'il vous plaît note également que je suis en utilisant les adaptateurs CSS pour mon friendly contrôle de connexion, et même essayé de changer cette ligne ici de ...

PostBackOptions options = new PostBackOptions(btn, "", "", false, false, false, clientSubmit, true, login.UniqueID); 

à ...

PostBackOptions options = new PostBackOptions(btn, "", HttpContext.Current.Request.ServerVariables["HTTP_X_ORIGINAL_URL"], false, false, false, clientSubmit, true, login.UniqueID); 

sans succès ...

S'il vous plaît aider :(

Répondre

1

Désolé trop tôt parlé ...

Comme mentionné dans un autre sujet, this web site a la solution.

Ajoutez simplement le fichier App_Browser et créez le fichier de réécriture de formulaire.

Form.browser:

<browsers> 
    <browser refID="Default"> 
     <controlAdapters> 
      <adapter controlType="System.Web.UI.HtmlControls.HtmlForm" adapterType="FormRewriterControlAdapter" /> 
     </controlAdapters> 
    </browser> 

</browsers> 

FormRewriter.cs:

using System.Web; 
using System.Web.UI; 

public class FormRewriterControlAdapter : System.Web.UI.Adapters.ControlAdapter 
{ 
    protected override void Render(System.Web.UI.HtmlTextWriter writer) 
    { 
     base.Render(new RewriteFormHtmlTextWriter(writer)); 
    } 
} 

public class RewriteFormHtmlTextWriter : HtmlTextWriter 
{ 
    public RewriteFormHtmlTextWriter(HtmlTextWriter writer) : base(writer) 
    { 
     this.InnerWriter = writer.InnerWriter; 
    } 

    public RewriteFormHtmlTextWriter(System.IO.TextWriter writer) : base(writer) 
    { 
     base.InnerWriter = writer; 
    } 

    public override void WriteAttribute(string name, string value, bool fEncode) 
    { 

     // If the attribute we are writing is the "action" attribute, and we are not on a sub-control, 
     // then replace the value to write with the raw URL of the request - which ensures that we'll 
     // preserve the PathInfo value on postback scenarios 

     if ((name == "action")) { 

      HttpContext Context = default(HttpContext); 
      Context = HttpContext.Current; 

      if (Context.Items["ActionAlreadyWritten"] == null) { 

       // Because we are using the UrlRewriting.net HttpModule, we will use the 
       // Request.RawUrl property within ASP.NET to retrieve the origional URL 
       // before it was re-written. You'll want to change the line of code below 
       // if you use a different URL rewriting implementation. 

       value = Context.Request.RawUrl; 

       // Indicate that we've already rewritten the <form>'s action attribute to prevent 
       // us from rewriting a sub-control under the <form> control 

       Context.Items["ActionAlreadyWritten"] = true; 
      } 
     } 

     base.WriteAttribute(name, value, fEncode); 
    } 
} 
+0

Eh oui, voilà ce que j'utilise - Je viens de lire la question et était sur le point de vous pointer là :) ... sur une note sans rapport, attention à la réécriture sur n'importe quelle URL plus profonde que le chemin physique de la page, car vous avez des problèmes avec les sessions sans cookie (à cause d'un bug asp.net) – eglasius

Questions connexes