[Mono-dev] [PATCH] Fix Roles.IsUserInRole and enhance WebTest Framework

Marek Habersack grendel at twistedcode.net
Thu Feb 11 16:50:29 EST 2010


On Thu, 11 Feb 2010 11:58:53 -0600
"Tiaan Geldenhuys" <tagdev at gmail.com> wrote:

> Hi Marek:
Hey,

> 
> Thanks for committing almost all the changes, especially the ones to
> WebTest.  However, I would still like to get some ideas about a better way
> to then isolate the Web.config settings between different Tests and Test
That's why I created support for standalone tests - see System.Web/Test/standalone* in trunk

> Fixtures -- because that seems to be the main issue with the changes that
> weren't approved, and having one RoleProvider configuration that must be
> shared between all tests is not really an option.
The test suite doesn't like being restarted (which happens if you update Web.config, bin/*, App_*
etc) and I have no time to spend fixing it atm.

> One approach could be to call WebTest.SetupHosting with a delegate that
> calls CopyResources to start with the default Web.config and then perhaps
> add the roleManager section programmatically in the setup delegate (instead
I really see no reason for this. You can provide an implementation of a "meta" role provider which
will dispatch the calls to the specific role provider you need in a particular test - that way you
have only one role provider in the web.config. Or you can access the Roles.Providers collection
directly to get any named provider you defined in web.config

> of overwriting the config file completely, like I did previously; and
> instead of always having the same RoleManager, like you now did, which could
> also interfere with other test that assume the default of not having any
I know this is not ideal, but with the way the current test suite works this is the best we can get
(or we can just create more standalone tests, which for this kind of test is the best option anyway)

> role manager, or at least with tests I would still like to contribute).  If
> isolation between tests is important, then one could add tear-down logic to
> the test that could perhaps call WebTest.CleanApp (so that the next call to
> EnsureHosting would start from fresh).  The problem with this approach is
Yes, this is a solution but as said above - I don't have time to spend on this right now. Patches
are welcome, of course :)

> that it seems to be very slow, and perhaps that's why the tests currently
> have to share their config.
Speed doesn't matter in this case.
 
> Ideally one would want to re-use any existing host and simply add/remove
> settings to Web.config programmatically in the test's start-up/tear-down
> logic (after calling WebTest.EnsureHosting).  But for this to work,
> WebTest.Run should only execute the next test after the updated Web.config
> has been loaded -- I've quickly tried this previously and ran into race
> conditions.  Do you know of a way that this synchronization can be added to
> WebTest without too much trouble?
I haven't spent any time on this, but I imagine it shouldn't be too complicated.

best regards,

marek
> 
> Regards,
> Tiaan.
> 
> 
> 
> -----Original Message-----
> From: Marek Habersack [mailto:grendel at twistedcode.net] 
> Sent: 11 February 2010 8:18 AM
> To: Tiaan Geldenhuys
> Cc: mono-devel-list at lists.ximian.com
> Subject: Re: [Mono-dev] [PATCH] Fix Roles.IsUserInRole and enhance WebTest
> Framework
> 
> On Thu, 11 Feb 2010 03:16:33 -0600
> "Tiaan Geldenhuys" <tagdev at gmail.com> wrote:
> 
> Hello,
> 
> > The attached patch is a fix for System.Web.Security.Roles.IsUserInRole to
> > prevent ASP.NET MVC errors like the one shown at the bottom, which happens
> > when a user hasn't logged on and requests public pages with sections that
> > are dynamically removed using role-based access-restrictions.  It now
> > behaves more like .NET that does not throw an exception.
> Thanks, that part of the patch looks ok.
>  
> > Writing a test for this fix was a bit of a challenge -- it's no wonder
> there
> > is not any working test for the Roles class yet.  :)  To address this, the
> > MonoTests.SystemWeb.Framework.WebTest class was updated slightly to make
> it
> > possible to write self-contained tests for cases where you might want more
> > control over the resources that are copied to your hosted web application,
> > such as when creating Web.config files dynamically.  The test for the
> > current fix also serves as an example of how this can be done.  If these
> > changes are approved, one can expand on this for all the other Roles
> > methods.
> Unfortunately, the test can't be implemented this way. I committed your
> code, but laid out in a
> slightly different manner. The RoleProvider definition went to Web.config
> and Web.mono.config
> resources since overwriting Web.config in the middle of running of the test
> suite is not acceptable
> - the configs contain settings other tests rely upon. However, I have
> decided to commit your
> changes to WebTest as they may come useful in other scenarios.
> 
> > 
> > Please review and commit.
> Committed in r151519 (trunk), r151520 (2.6 branch) and r151521 (2.4 branch -
> backported without the
> WebTest changes)
> 
> > 
> > Thank you,
> Thanks!
> 
> marek
> > Tiaan.
> > 
> > NOTE: The patch files can be used without changes on both trunk and the
> 2.6
> > branch.
> > 
> > ---------------
> > 
> > [System.Web.HttpUnhandledException]: Exception of type
> > 'System.Web.HttpUnhandledException' was thrown.
> >   at System.Web.UI.Page.ProcessException (System.Exception e) [0x00000] in
> > <filename unknown>:0 
> >   at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context)
> > [0x00000] in <filename unknown>:0 
> >   at System.Web.HttpApplication+<Pipeline>c__Iterator5.MoveNext ()
> [0x00000]
> > in <filename unknown>:0 
> >   at System.Web.HttpApplication.Tick () [0x00000] in <filename unknown>:0 
> > [System.Web.HttpUnhandledException]: Exception of type
> > 'System.Web.HttpUnhandledException' was thrown.
> >   at System.Web.UI.Page.ProcessException (System.Exception e) [0x00000] in
> > <filename unknown>:0 
> >   at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context)
> > [0x00000] in <filename unknown>:0 
> >   at System.Web.Mvc.ViewPage.RenderView (System.Web.Mvc.ViewContext
> > viewContext) [0x00000] in <filename unknown>:0 
> >   at System.Web.Mvc.WebFormView.RenderViewPage (System.Web.Mvc.ViewContext
> > context, System.Web.Mvc.ViewPage page) [0x00000] in <filename unknown>:0 
> >   at System.Web.Mvc.WebFormView.Render (System.Web.Mvc.ViewContext
> > viewContext, System.IO.TextWriter writer) [0x00000] in <filename
> unknown>:0 
> >   at System.Web.Mvc.ViewResultBase.ExecuteResult
> > (System.Web.Mvc.ControllerContext context) [0x00000] in <filename
> unknown>:0
> > 
> >   at System.Web.Mvc.ControllerActionInvoker.InvokeActionResult
> > (System.Web.Mvc.ControllerContext controllerContext,
> > System.Web.Mvc.ActionResult actionResult) [0x00000] in <filename
> unknown>:0 
> >   at
> >
> System.Web.Mvc.ControllerActionInvoker+<InvokeActionResultWithFilters>c__Ano
> > nStoreyE.<>m__11 () [0x00000] in <filename unknown>:0 
> >   at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilter
> > (IResultFilter filter, System.Web.Mvc.ResultExecutingContext preContext,
> > System.Func`1 continuation) [0x00000] in <filename unknown>:0 
> > [System.ArgumentException]: Username cannot be empty.
> >   at SomeRoleProvider.IsUserInRole (System.String username, System.String
> > roleName) [0x00000] in <filename unknown>:0 
> >   at System.Web.Security.Roles.IsUserInRole (System.String rolename)
> > [0x00000] in <filename unknown>:0 
> >   at ASP.views_shared_site_master.__RenderTree
> (System.Web.UI.HtmlTextWriter
> > __output, System.Web.UI.Control parameterContainer) [0x00000] in <filename
> > unknown>:0 
> >   at System.Web.UI.Control.RenderChildren (System.Web.UI.HtmlTextWriter
> > writer) [0x00000] in <filename unknown>:0 
> >   at System.Web.UI.Control.Render (System.Web.UI.HtmlTextWriter writer)
> > [0x00000] in <filename unknown>:0 
> >   at System.Web.UI.Control.RenderControl (System.Web.UI.HtmlTextWriter
> > writer) [0x00000] in <filename unknown>:0 
> >   at System.Web.UI.Control.RenderChildren (System.Web.UI.HtmlTextWriter
> > writer) [0x00000] in <filename unknown>:0 
> >   at System.Web.UI.Control.Render (System.Web.UI.HtmlTextWriter writer)
> > [0x00000] in <filename unknown>:0 
> >   at System.Web.UI.Page.Render (System.Web.UI.HtmlTextWriter writer)
> > [0x00000] in <filename unknown>:0 
> >   at System.Web.Mvc.ViewPage.Render (System.Web.UI.HtmlTextWriter writer)
> > [0x00000] in <filename unknown>:0 
> >   at System.Web.UI.Control.RenderControl (System.Web.UI.HtmlTextWriter
> > writer) [0x00000] in <filename unknown>:0 
> >   at System.Web.UI.Page.RenderPage () [0x00000] in <filename unknown>:0 
> >   at System.Web.UI.Page.InternalProcessRequest () [0x00000] in <filename
> > unknown>:0 
> >   at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context)
> > [0x00000] in <filename unknown>:0
> > 
> > ===============
> > 
> > 
> > 
> 



More information about the Mono-devel-list mailing list