I need to slightly tweak the functionality of the ASP.NET Membership provider to add custom logging functionality. Instead of creating a wrapper class around the methods I wish to modify, I was toying with the idea or creating a custom Membership Provider and override a few of the methods.
All the examples I could find would show how to create it from scratch. I don't want to overwrite everything... just override a few methods. Can somebody point me in the right direction?
Thanks!
EDIT:
DOH! I can simply inherit from SqlMembershipProvider and override the methods. However, how can I get at the connection string?
What is it that you are trying to log?
If you simply want to monitor success and failure of authentication, ASP.NET Health Monitoring is already in the box. Events are logged to the WebEvent tables.
If you have other motives, well then..... ;-)
to answer your question about the connection string, override Initialize and capture the value from the config argument before calling base.Initialize
Related
I'm implementing a custom ASP.NET role provider, and I'm wondering whether its AddUsersToRoles method should throw a ProviderException if a user passed in is already in a role passed in. The default Microsoft SQL Server role provider SqlRoleProvider exhibits this behaviour, even though the official Microsoft documentation doesn't recommend it:
Exception Details: System.Configuration.Provider.ProviderException: The user 'myTestUser' is already in role 'myTestRole'.
I think it would be useful for my provider not to throw an exception in this case but just to move on when a given user is already in a given role; that way the calling code doesn't need to worry about duplicates. But could there be existing role provider-using code that relies on an exception being thrown in this case? If there is, should it be doing so given that Microsoft themselves don't seem to recommend it?
If I do want to implement a method similar to AddUsersToRoles that doesn't throw an exception when a user is already in a role, I can see 3 alternatives:
Implement it as AddUsersToRoles and just have different behaviour from the default SqlRoleProvider.
Implement it as a new EnsureUsersInRoles method in my role provider class, and access it from my calling code using ((MyProvider)(Roles.Provider)).EnsureUsersInRoles().
Just implement it in a totally separate class.
Personally, I'd conform to what Microsoft does. It would be hard to rule out the possibility that something somewhere does require that exception to be thrown.
I ended up going down route 2) that I proposed in my question; I implement a RoleProvider with some additional methods as well, and then use the cast ((MyProvider)(Roles.Provider)) to get access to my additional methods, one of which is EnsureUsersInRoles(), which has the non-Exception-throwing functionality that my calling code wants.
I have an ASP.NET website and I am doing logging with log4net. As logging requirements change often, I want to enable PMs to modify the information that gets logged and also to be able to log extra information for debugging in production (i.e without having to recompile)
My plan is to expose certain values to log4net, for example the GET / POST params from context. To log such a param, the user would just go to the log4net config and do something like %message{userId}
I have found a way to do it using a property bag on log4net.ThreadContext but I am not sure if this doesn't have side-effects, i.e. the values are persisted for too long.
Another way is to use a forwarding appender, and inject the extra values whenever the logger gets called, but I haven't been able to implement this, there are not enough examples out there.
Any ideas?
Look at my answer to this question. The linked question and answer are specifically about adding the username from HttpContext.Current.User to the logfile, but it should be pretty easy to make a more generic solution that might fit your needs.
It might provide you with some ideas of how to incorporate information from the HttpContext into your log4net logging. There are other good ideas in that thread as well.
You should have a look at NDC (Nested Diagnostic Context) in log4net. This will provide you with to possibility to add information logging messages like setting up a stack:
using(log4net.NDC.Push("My extra info")){
}
All logmessages within the NDC scope will have the inner_context available (pattern layout format):
[%ndc] - %message%newline
I've got confused . We hear a lot about Provider in ASP.NET . Membership-Provider , Role Provider , XmlDataProvider ,CustomProvider, ....
What are those and why we need them in ASP.NET ?
Provider is a synonyme with "Supplier" which means:
Someone whose business is to supply a
particular service or commodity
Just as in real life, a provider is someone / something that helps you solve communicaiton with a certain service or help you solve a problem.
For instance, the Membership Provider in .NET is used to handle Membership such as Authentication, Registering new Users and many more options comes with this.
The Role Provider goes hand in hand with the above, because it helps you handle Roles attached to users that you have in ( They have Memberships! ).
You might want to read this: Microsoft ASP.NET 2.0 Provider Introduction from MSDN
Using the Provider model means that if you don't like the way something in ASP.NET works or you want/need to extend it, you can write your own. As long as it supports the core functionality that ASP.NET needs to work as part of the platform i.e. it inherits from MemrbershipProvider/RoleProvider/WhateverProvider, you can do what you want in the internals.
You can then swap out the default Provider and use yours in it's place e.g. say you don't use SQL Server, you use CouchDB for all your data storage. You can't use the SqlMembershipProvider, but you can write a CouchDBMembershipProvider* - as long as you inherit from MembershipProvider and override its' methods to work with CouchDB you're good to go.
* I'm not saying you should do this, I'm just saying you can :-)
I am using The Policy Injection Application Block to log methods that are called in my ASP.NET application. I would like these log entries to include information like the current user identity, whether the user is authenticated and so forth. All of this information is provided by the ManagedSecurityContextInformationProvider, but I can't figure out how to get the PIAB to use that provider and how to get that information into my log file.
I may be missing something obvious, but I can't quite figure out what it is.
Sorry to say, it looks like there is no way to get the ManagedSecurityContextInformationProvider information into method call logs. That information is usually logged in extended properties but the LogCallHandler.GetLogEntry method dumps out all of the method parameters and assigns them to the TraceLogEntry ExtendedProperties.
It seems to me that you could either modify the block to add that information or (even better) create your own Custom Call Handler based on LogCallHandler that adds the information that you require. Either option is not that much work.
I am trying to build an ASP.NET 3.5 website that allows users to log in and browse a couple of pages. I would like to restrict certain users to be able to view certain pages but I'm having trouble coming up with a custom and flexible system. I have seen MS's version of this but it's not what I am looking for. Can anyone direct me to some good online articles or even a video tutorial so I can do further research. Thanks!
P.S. I have tried creating a class that inherits from System.Web.UI.Page which does some checking but it's getting messy. All my other pages inherit from that common page. Is this a common practice? How have you guys solved this problem in the past?
The best way to implement this would be, Forms Authentication coupled with Custom Role Provider.
Hope you know, for Forms Authentication to work, you need not have to use the Complete Database Setup that MS uses to Authenticate.
You can simply have your own Database and Validate a user yourself, and just set the cookie.
String UserName = "CoolGuy";
Boolean isValidUser = YourClass.YourMethod(UserName);
if (isValidUser)
{ FormsAuthentication.setAuthCookie(UserName, false); }
This will authenticate the user "CoolGuy" for the session, provided YourMethod returns true.
You can use this, coupled with custom role provider. This gives you the facility to check User.IsInRole("Role"); in your code.
To Start with CustomRoleProvider.. here is a good reference... http://davidhayden.com/blog/dave/archive/2007/10/17/CreateCustomRoleProviderASPNETRolePermissionsSecurity.aspx
Raja
Well, without knowing the exact details of your app, one thing you could use is the Role Manager built into the Membership API.
Basically, you would create roles for each page and assign users to the roles (pages) you would want them to view.
In the code behind for each page, on the On_Load event, I would simply call the method
if(Roles.IsUserInRole(rolePageName))
{
//Continue page loading logic
}
{
//Redirect or transfer the user elsewhere
}
For this kind of logic you may want to reconsider using an inherited page, otherwise you're going to have to come up with a way to retrieve the URL of the page and pass that into some long list of if-else or switch statements to call the proper Roles.IsUserInRole method.