On an asp.net mvc 2 app, I'm using Unity 2.0 interception app for various types of logging where every log entry requires the id of the current user.
Currently I'm passing the User object as an argument to service and repository methods. The only reason I'm doing this is so that it's available on MethodInvocation.Argumants for the intercepted method. Ideally, I'd like to supply the interceptor with a User object somehow. This doesn't seem to be possible. Does anybody know if it is or if any other .net AOP tool provides this? I also remember this being a problem several years ago on a project using Spring/Java so I guess it is a common problem that hopefully someone has solved?
I worked it out.
To handle the intercepted calls, you have to supply an implementation of ICallHandler.
Add a User parameter to the implementation's constructor.
Related
After updating to .net core 2.2 we have the following issue:
Autofac.Core.Registration.ComponentNotRegisteredException: 'The
requested service 'Microsoft.AspNetCore.Hosting.Server.IServer' has
not been registered. To avoid this exception, either register a
component to provide the service, check for service registration using
IsRegistered(), or use the ResolveOptional() method to resolve an
optional dependency.'
We are using preBuilder.Populate(services);.
Any ideas?
Thanks for your help
I had the same problem when following Microsoft migration guide for migrating from Core 2.1 to 2.2.
The problem might occur if you are not using WebHost.CreateDefaultBuilder to create the default web host builder, and you change in the CreateWebHostBuilder method of the Program class to call ConfigureKestrel instead of UseKestrel, as suggested in the migration guide.
As far as I understand if you use WebHost.CreateDefaultBuilder to create the default web host builder, it already calls UseKestrel which registers the IServer service. But you might get into some conflicts if also using UseIIS, so to avoid this problems there is a new ConfigureKestrel call that does not register the IServer. So I think that if you are not using WebHost.CreateDefaultBuilder then you still need to call UseKestrel or UseIIS explicitly.
Of course it might be something else that is causing the problems in your case, but I suspect that following the migration guide blindly (as I did) could cause problems for many developers out there.
I would like to have access to the current user somewhere deep in my models of my Play app, for things like setting the author, checking that the user can actually save this type, etc.
Ideally, what I would like to use is Guice's #RequestScoped to inject the same UserIdentity across my request, wherever I need it. However, as far as I can tell, the Play! Framework only supports #Singleton and no-scope. So either we'd get the same UserIdentity injected across requests or a different one for every model/util we requested. Both are no-gos for obvious reasons.
Is there some way to utilise this behaviour in Play 2.5?
Other things I have tried
I've tried using a combination of Play's session and cache. But the problem I have is that session is immutable, so I can't add anything to it to reuse in that same request.
I've looked at a bunch of auth frameworks but they all seem to focus on securing actions, not providing me with a current User object.
Check out my answer to a question on redirecting requests, where I given an example of getting the current user in each request.
In this case the authorization key is handed out on login and the client passes it in on every request thereafter.
Ok...
I'm writing a ASP.Net MVC 2 application, and one of the requirements is that I log the headers on the requests we receive, and also on the responses we send...
My approach to do this has been to create a controller that overrides OnActionExecuting and OnActionExecuted, and then create our actual "live" controllers by inheriting from this rather than from the usual base class. This way, I basically get the logging functionality for free.
While this approach works fine for handling the requests, responses seem to be another matter. I am getting an error telling me that the Headers property of the HTTPResponseBase class requires IIS to be using the Integrated Pipeline. I therefore have two questions.
Question 1.
Can anyone suggest a means to get the headers through a means other than HTTPResponseBase.Headers? I have considered for example simply parsing the entire resposne and getting them that way myself, but I was hoping someone might have a better way...
Question 2.
What is this Integrated Pipeline? What does it do? How do I enable it?
Cheers in anticipation...
Martin.
In response to Question 2:
Integrated Pipeline is a new feature in IIS 7 and higher, you can change the application pool in IIS7 to use this new pipeline.
I have a concern where I am writing a custom membership provider, but I'm not sure where to put it. I don't really have any code to show you, but basically the provider needs access to System.Web.Security in order to inherit the class, but it also needs data access (i.e. a connection string + LINQ to SQL) to do simple tasks such as ValidateUser.
How can I write a membership provider that adheres to the principles of DDD that I've read about in Pro ASP.NET MVC2 Framework by Apress? My one thought was to write another class in my domain project which does all the "work" related to database stuff. In essence I would have double the number of methods. Also, can this work with dependency injection (IoC)?
Hope this isn't too general ...
Look forward to the hive-mind's responses!
Edit: I just noticed in a default MVC2 project there is an AccountController which has a wrapper around an IMembershipService. Is this where my answer lies? The AccountController seems to have no database access component to it.
Asp.net user management features are super invasive.
They even spam database with profile tables and what not.
When I had to implement users management of my application, I successfully avoided all that mess and still was able to use asp.net in-built roles, user identities etc. Moving away from all that though cause my domain is getting smart enough to decide what can be seen and done so it makes no sense to duplicate that in UI client.
So... yeah. Still have zero problems with this approach. Haven't changed anything for ~4 months.
Works like a charm.
I see a lot of articles and posts on how to create a custom MembershipProvider, but haven't found any explanation as to why I must/should use it in my MVC2 web app. Apart from "Hey, security is hard!", what are critical parts of the whole MembershipProvider subsystem that I should know about that I don't, because I've only read about how to override parts of it? Is there some "behind the scenes magic" that I don't see and will have to implement myself? Is there some attribute or other piece of functionality that will trip over itself without a properly setup MembershipProvider?
I am building a web app, using a DDD approach, so the way I see it, I have a User entity and a Group entity. I don't need to customize ValidateUser() under the provider; I can just have it as a method on my User entity. I have to have a User object anyways, to implement things not under the MemebrshipProvider?
So, what gives? :)
No, you don't need it. I have sites that use it and sites that don't. One reason to use it is that plumbing is already there for it in ASP.NET and you can easily implement authentication by simply providing the proper configuration items (and setting up the DB or AD or whatever).
A RoleProvider, on the other hand, comes in very handy when using the built-in AuthorizeAttributes and derivatives. Implementing a RoleProvider will save you a fair amount of custom programming on the authorization side.