Re: [Mono-list] Current state of FormsAuthentication
Hi! We found regression in latest version of Forms Authentication - in case when the FormsAuthenticationTicket is not persistent (created with FormsAuthentication.SetAuthCookie("userName", false)) the HttpRequest.IsAuthenticated will return false. Attached possible patch (in FormsAuthenticationModule.cs) and test case. Thanks, Ilya Kharmatsky. Gonzalo Paniagua Javier wrote: On Wed, 2005-03-02 at 11:45 -0700, Jesse Pasichnyk wrote: I am working on developing an ecommerce site with mono/postgres and am having some issues with the a Forms based security login area. Last mono release shipped with a regression that might make FormsAuthentication fail. You can get a new System.Web.dll from http://www.go-mono.com/archive/1.0.6/System.Web.dll or http://www.go-mono.com/archive/1.1.4/System.Web.dll -Gonzalo ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list Index: System.Web.Security/FormsAuthenticationModule.cs === --- System.Web.Security/FormsAuthenticationModule.cs(revision 41482) +++ System.Web.Security/FormsAuthenticationModule.cs(working copy) @@ -15,10 +15,10 @@ // distribute, sublicense, and/or sell copies of the Software, and to // permit persons to whom the Software is furnished to do so, subject to // the following conditions: -// +// // The above copyright notice and this permission notice shall be // included in all copies or substantial portions of the Software. -// +// // THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, // EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF // MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND @@ -65,7 +65,7 @@ string reqPath = context.Request.PhysicalPath; string loginPath = context.Request.MapPath (loginPage); context.SkipAuthorization = (reqPath == loginPath); - + FormsAuthenticationEventArgs formArgs = new FormsAuthenticationEventArgs (context); if (Authenticate != null) Authenticate (this, formArgs); @@ -76,13 +76,13 @@ context.User = formArgs.User; return; } - + HttpCookie cookie = context.Request.Cookies [cookieName]; if (cookie == null || (cookie.Expires != DateTime.MinValue && cookie.Expires < DateTime.Now)) return; FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt (cookie.Value); - if (ticket == null || ticket.Expired) + if (ticket == null || (ticket.IsPersistent && ticket.Expired)) return; if (config.SlidingExpiration) private void Page_Load(object sender, System.EventArgs e) { Response.Write("Request.IsAuthenticated "+Request.IsAuthenticated + ""); HttpCookieCollection collection = Response.Cookies; Response.Write("Before setting forms cookie! "); foreach(string o in collection) { Response.Write(collection[o].Name + " " +collection[o].Value + ""); } FormsAuthentication.SetAuthCookie("userName", false); collection = Response.Cookies; Response.Write("After setting forms cookie! "); foreach(string o in collection) { Response.Write(collection[o].Name + " " +collection[o].Value + " " + collection[o].Expires + ""); } }
Re: [Mono-list] Current state of FormsAuthentication
Hi, Hubert! See comeents below. Hubert FONGARNAND wrote: Since about a week, i've problems with FormsAuthentication... I'm using not persistent FormsAuthenticationTicket... I've apply your patch... and it works only with XSP... Let me clearify the problem - the patch caused to regressions on apache and mod_mono? Or it just didn't resolve problem on those servers? With apache and mod_mono, i'm never authenticated... I've another problem with XSP: - With formauthentication enabled, i can't access to images or static html pages without beeing authenticated... With a normal (.NET) behaviour only .aspx pages are protected... Thanks... Le Dimanche 06 Mars 2005 17:49, Ilya Kharmatsky a écrit : Hi! We found regression in latest version of Forms Authentication - in case when the FormsAuthenticationTicket is not persistent (created with FormsAuthentication.SetAuthCookie("userName", false)) the HttpRequest.IsAuthenticated will return false. Attached possible patch (in FormsAuthenticationModule.cs) and test case. Thanks, Ilya Kharmatsky. Gonzalo Paniagua Javier wrote: On Wed, 2005-03-02 at 11:45 -0700, Jesse Pasichnyk wrote: I am working on developing an ecommerce site with mono/postgres and am having some issues with the a Forms based security login area. Last mono release shipped with a regression that might make FormsAuthentication fail. You can get a new System.Web.dll from http://www.go-mono.com/archive/1.0.6/System.Web.dll or http://www.go-mono.com/archive/1.1.4/System.Web.dll -Gonzalo ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] successful port of MS .net application to linux/apache/mono1.1.4
Hi, Simon! I want just clarify the status of FormsAuthentication - see already fixed bug: http://bugzilla.ximian.com/show_bug.cgi?id=73545 which should resolve this issue. Thanks, Ilya. simon wrote: Ive recently successfully ported an ASP.Net application from MS .net to mono-1.1.4. This application was approximately 250-300 days development, is currently deployed and in production on windows server 2003, has 2 external interfaces and used an MS SQL server database. As an experiment I ported it to mono and mysql in approximately 20 hours, and had it running under apache on an ubuntu linux box. The application used a number of 3rd party libraries including nHibernate and wilson master pages. Some of the major problems encountered during the port were; - trouble with mulitple cookies and the FormsAuthentication cookie disappearing. - not sure what the problem was, made work around. - ALOT of trouble with differences in what I would call the current executing path of pages and the inclusion of user controls. It appears that IIS executes pages in a different path to apache/mod_mono and this causes the page directives at the top of the aspx file to be incorrect. Solution (really work around) - change ALL Server.Transfer calls to Response.Redirect (whether this is a better approach anyway is debatable) - problems with libraries compiled under MS .net framework not being compatable with those compiled under mono. I am not sure what the expected compability between things compiled under mono and MS are but ive found that if you can get the source for something, try and compile it under mono, it will cause you less trouble in the end. Apart from that the port was successful, and relatively painless. Unfortunately this forum is not the place for me to say what the application is (at this time). The next task is to find 2 identical boxes, deploy under both win2k3 and linux/mono and load test both to see the results. Only problem being i dont have 2 identical boxes :( Simon ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] LANDED: managed collation (CompareInfo) support
Hi, Atsushi! Great news! Thank you! Are you planning to make some performance banchmarks and compare results to "old" and may be MS.Net performance results? Ilya. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Atsushi Eno > Sent: Monday, August 08, 2005 9:34 AM > To: mono-devel mailing list; mono-list mailing list > Subject: [Mono-list] LANDED: managed collation (CompareInfo) support > > Hello, > > I checked in managed collation (CompareInfo) support in mscorlib.dll. > It enables culture-sensitive string/character comparison support. > > For now, it will not be activated unless you explicitly set > environment variable MONO_USE_MANAGED_COLLATION=yes. > > Culture sensitive comparison is done in almost all areas > where basic System.String methods are used - Compare(), > IndexOf(), LastIndexOf(), StartsWith() and EndWith(). Note > that culture- sensitive comparison will happen even in > InvariantCulture. > > There are still some characters that I have not supported > precise implementation, but it should mostly work fine. If > you found problem in culture-sensitive comparison, please > tell me and/or file a bug to bugzilla: http://bugzilla.ximian.com > > Atsushi Eno > ___ > Mono-list maillist - Mono-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list