I have some code used to determine if a user is logged in and I want to put this on every page in an ASP.NET website so that only logged in users can view it. The problem is that the site is split into multiple projects/solutions so maintaining the single piece of code might be hard.
I was thinking I could create a class that inherits for System.Web.UI.Page and overrides Page_Init, but that would require changing all pages so they inherit from new new class. Also I don't think this will work across projects.
So then I thought approaching the problem from a different side: using AOP. I have never used Aspects before but it looks like I could use PostSharp to write an Aspect that injects code before every Page_Init (or maybe Page_Load?). This might work as a quick solution but I might run into problems if I need a page to not perform the authentication check (available to everyone).
Just to clarify, I already have a login solution; I am just looking for a checking that login on each page.
Look into HttpModules. The asp.net framework is already programmed so that a module runs on every page request, you just have to write it and add it to web.config.
http://msdn.microsoft.com/en-us/library/zec9k340(v=vs.71).aspx
EDIT: Here's a better link that demonstrates handling the BeginRequest event
http://msdn.microsoft.com/en-us/library/ms227673(v=vs.85).aspx
As #jrummell mentioned, there's MembershipProvider which is a great option, but if you're creating custom login solition, check this link which has a pretty simple login implementation step by step
Since you seem to have your login solution handled and working, creating a class that overrides the page_init sounds like your best option. This can work across other projects by simply creating that class in a separate project that you can included in your other solution(s)... To be honest, that's the easiest way to span the logic across multiple projects.. This will also be easily maintained because you'd only have to update one location going forward.
If you are using MasterPages, you wouldn't have to hit all of the pages, you could just include it on specific MasterPage(s) and set all the pages you want authentication to use that MasterPage.
Windows Identity Foundation can solve this for you. See http://msdn.microsoft.com/en-us/security/aa570351 for details on WIF. No need to reinvent the wheel. If you had only one Web application, Forms authentication would suffice.
Related
I am confused with adding ASP.NET Core Identity to my web app. I would like to use parts of the default UI and controllers for my Razor Pages app, such as Login.cshtml and login.cshtml.cs or the register view and controller. However, I dont want to have all the added on 30+ pages along with it.
Scaffolding the views and controllers with .NET CLI only overrides the default RCL. That means I am still able to go to the specified URL from my home page such as Name of Website/Identity/Account/AccessDenied. The only way (that I have seen thus far) of disabling the default UI and controllers is to actually disable it on a per page/controller basis as outlined here. This means Id have to add all the default UIs and controllers to my app and then disable them? Is there no other way to only use the pages and pageModels that you want while using Identity?
UPDATE:
Here are some examples of others asking the same question. See the comment mentioned in the accepted answer to this stackoverflow question to "disable registrations or change redirect routes via Startup.cs without having to scaffold"
Please also see this issue on gitHub about it. Has nothing changed? Is it not easier to just forget the default UI and only add the service AddIndentity and not call AddDefaultUI then create the logic and views yourself to handle users. The whole point of adding Identity as a service is so that you dont have to write and maintain your own code. This seems backwards to me.
Recently created my first httpmodule. It drops and manages a user cookie. This all works fine.
I now need to drop another cookie relating to site affiliates.
The question is, is is better practice to create 2 entirely separate httpmodules or add extra code to the existing one. The reason I ask is because the functionality is closely related (they both drop a cookie).
Why not write a Class Library that deals with cookies, then write your HttpModules that use the Cookies Class Library?
I don't believe you should join them, because they set cookies for different reasons, and it's easier to disable them individually if they aren't in the same module.
I am working on a website (developed in ASP.NET with C#) that was passed on to me. As I'm working through the site, I notice much of the site has this type of code in it:
EmailLabel.Visible = false;
WhateverButton.Visible = false;
AnotherControl.Visible = false;
...
This is all typically done in the code-behind of the site (in the Page_Load method). Essentially, this was put in place to prevent a non-logged in user from accessing components (the rule for the site is that a non-logged in user shouldn't be able to see any part of the site until they log in). The way above works...but it seems rather expensive to have to always check if the user is logged in and then flip to the correct status for all those components.
Is there a different way that this problem could be approached. Just from thinking about it/research, I thought perhaps there would be a way that I could do a redirect back to the home page if a user is not logged in. Even further, I could extend a base page which would do this for any page that extends the base page. However, my knowledge in this area is limited, so my suggestion may not work.
What can SO suggest? Anything better? Is what is there good enough?
We do this a lot at my work.
The way we accomplish this is by creating a BasePage class that inherits from System.Web.UI.Page. Then you override OnInit, call the base.OnInit, and add code to check for a logged in user. If the user is not logged in, Redirect them to a login page (which would not inherit from BasePage.)
Then, on every page that needs to be protected, just change the page to inherit from BasePage.
And contrary to what womp says above, if you write Response.End(); after the redirect, it is much faster that even continue processing the rest of the page!
Hope that helps.
There is a loginview component that is a panel which has an anonymous view, authenticated view, and views for specific roles. This makes it easy to do this.
http://www.creativeui.com/2007/10/05/net-membership-part-ii-loginview/
It would be many, many orders of magnitude more expensive to issue a redirect than to set the Visible flags on a number of controls.
If your page allows both anonymous access and logged in access, then redirecting would also require you to allow anonymous access some other way, probably by building a second version of the page.
The expense question is really just an aside though, it likely doesn't matter at all. To answer your main question, without knowing more about the architecture of your app, I would consider both these things as undesirable. The advantages of just setting the controls to Visible = false is that nothing gets rendered to the output stream for the invisible controls, but they can still interact with server requests.
Without knowing more about the requirements of your page, it's hard to suggest alternatives. As someone else mentioned, a LoginView might meet your needs if the invisible controls don't participate at all with anonymous users.
I want to know if its possible and how to do the following , i have a basic MVC application (ASP.Net) that i have modified to work for me. Now the application already handles authentication perfectly fine but i need to use this authentication in another app.
Without creating a webservice is it possible for me to make calls to the applications authcontroller , if so how
You can't directly call a controller in another application because it is in a separate AppDomain. If you just want to reuse the existing code, you could refactor it into a separate assembly (library project), include that assembly in your new application, and just reference it from your logon controller. If you are trying to do single-sign on, then you may want to look at existing SSO solutions, such as JA-SIG CAS 2.0.
Authentication is a cross-cutting concern that shouldn't be embedded into a single use case/controller. AOP afficionados would say it should be encapsulated in an aspect.
Whoa guys slow down , im still beginning MVC and all its related details , the single sign on looks promising , the reason i dont want to go that route yet or even refactor the code and include it in the second project is because its way too simple a project.
Using a configuration file I want to enable myself to turn on and off things like (third party) logging and using a cache in a C# website. The solution should not be restricted to logging and caching in particular but more general, so I can use it for other things as well.
I have a configuration xml file in which I can assert that logging and caching should be turned on or off (it could also be in the Web.Config, that's not the point right now) which will result in for example a bool logging and a bool caching that are true or false.
The question is about this part:
What I can do is prepend every logging/caching related statement with if (logging) and if (caching).
What is better way of programming this? Is there also a programming term for this kind of problem? Maybe attributes are also a way to go?
Why not just use the web.config and the System.Configuration functionality that already exists?
Your web app is going to parse web.config on every page load anyway, so the overhead involved in having yet another XML config file seems overkill when you can just define your own section on the existing configuration.
I'm curious what kind of logging/caching statements you have? If you have some class that is doing WriteLog or StoreCahce or whatever... why not just put the if(logging) in the WriteLog method. It seems like if you put all of your logging caching related methods into once class and that class knew whether logging/caching was on, then you could save your self a bunch of If statements at each instance.
You could check out the Microsoft Enterprise Library. It features stuff like logging and caching. The logging is made easy by the fact you always include the logging code but the actual logging beneath it is controlled by the settings.
http://msdn.microsoft.com/en-us/library/cc467894.aspx
You can find other cool stuff in the patterns and practices group.
Consult http://msdn.microsoft.com/en-us/library/ms178606.aspx for specifics regarding configuring cache.
I agree with foxxtrot, you want to use the web.config and add in a appsetting or two to hold the values.
Then for the implementation on checking, yes, simply use an if to see if you need to do the action. I highly recommend centralizing your logging classes to prevent duplication of code.
You could use a dependency injection container and have it load different logging and caching objects based on configuration. If you wanted to enable logging, you would specify an active Logging object/provider in config; if you wanted to then disable it, you could have the DI inject a "dummy" logging provider that did not log anything but returned right away.
I would lean toward a simpler design such as the one proposed by #foxxtrot, but runtime swapping out of utility components is one of the things that DI can do for you that is kind of nice.