[Mono-bugs] [Bug 82043][Nor] Changed - WebMethod and PrincipalPermission

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Sun Jul 15 09:10:46 EDT 2007


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by mmorano at mikeandwan.us.

http://bugzilla.ximian.com/show_bug.cgi?id=82043

--- shadow/82043	2007-07-13 05:54:21.000000000 -0400
+++ shadow/82043.tmp.2736	2007-07-15 09:10:46.000000000 -0400
@@ -1,12 +1,12 @@
 Bug#: 82043
 Product: Mono: Class Libraries
 Version: 1.2
 OS: unknown
 OS Details: 
-Status: NEEDINFO   
+Status: REOPENED   
 Resolution: 
 Severity: Unknown
 Priority: Normal
 Component: Sys.Web.Services
 AssignedTo: atsushi at ximian.com                            
 ReportedBy: mmorano at mikeandwan.us               
@@ -61,6 +61,66 @@
 ------- Additional Comments From atsushi at ximian.com  2007-07-13 05:54 -------
 > There also seem some traps that disables basic authentication
 > stuff, which may be happening with your setup.
 
 Oops, forgot to add a link for this:
 http://www.dotnet247.com/247reference/msgs/29/147430.aspx
+
+------- Additional Comments From mmorano at mikeandwan.us  2007-07-15 09:10 -------
+Sorry for not being so clear.  I am running this through xsp2, and
+have split the asmx and code files.  Below is a modified version of
+your test case which more closely resembles my setup:
+
+First is the asmx file.  This lives in a standard directory that can
+be referenced by the browser (not in a special asp.net directory such
+as app_code).
+
+-- ASMX FILE --
+<%@WebService Language="c#" Class="Bug82043" %>
+
+
+The .asmx.cs file lives in App_Code.  This file contains all the logic
+for the class.  This is working fine on my xsp2 instance:
+
+-- ASMX.CS FILE --
+using System;
+using System.Security;
+using System.Security.Permissions;
+using System.Web;
+using System.Web.Services;
+using System.Web.Services.Protocols;
+
+public class Bug82043 : WebService
+{
+        [WebMethod]
+        [PrincipalPermission(SecurityAction.Demand,
+Authenticated=true,  Role="admin")]
+        public bool Test(int x, int y)
+        {
+                return User.IsInRole("admin");
+        }
+}
+
+As part of the website, I have enabled forms authentication, and am
+using a custom Membership and Role provider to provide authentication
+and authorization services.  That has been working fine for some time,
+and properly allows a user to log into my site and allow/deny access
+to various areas based on who they are.
+
+Given that the code above tries to apply a role level principal
+permission on the method, as I would expect the runtime to raise an
+exception here, as the user is not in the role at first.  However, it
+does get into the method, and then returns false as the user did not
+login.
+
+After logging in as an admin, the method is invoked and returns true.
+
+I might not be correctly understanding what you are getting at with
+the reference to the article.  I am running this on linux, and using
+forms based authentication (not integrated windows or basic auth). 
+Also, I am not authorizing based on username, and am not in an active
+directory domain, so I dont believe the comments concerned with the
+Name attribute apply here.  Is there something I am missing?
+
+
+Thanks,
+Mike


More information about the mono-bugs mailing list