I am working on several asp.net sites simultaniously. All of them use cookie-based (out of the box) authentication mechnism. When a web site on localhost:4587 was being bedduged in VS I have logged in as an "admin" user and did some testing.
The next day I am opening different project for debugging that runs on localhost. And when I attempt to access the MVC controller action that is marked with Authorization atribute, the system assumes the current user is "admin" and is looking for it's roles based on a custom provider. But on this site, there isn't even a user named "admin". How can I make sure cookies from other sites don't make it to Role check in ASP.NET MVC application?
I would suggest it is always a good practice to delete all localhost cookies after testing. As explained here : asp.net cookies, authentication and session timeouts , you can also add details to the authentication cookie to ensure it is discarded after a session, ie when you close the browser or to differentiate between two sites. Another approach to avoid cookies 'clashing' is to use two different browsers : Chrome for the one and a Comodo Dragon or Chromium for the other.
Give your forms tag a unique name in each application
<authentication mode="Forms">
<forms name="myVeryUniqueNameForApp1" />
</authentication>
<authentication mode="Forms">
<forms name="myCompletelyUniqueNameForApp2" />
</authentication>
Related
How i can implement Windows Authentication to authenticate user while logging in? I do not want to get a pop up window rather i would like to let my login page(LoginPage.aspx) do the same. Please provide me with the steps/ code(vb.net). Thanks
It requires a good amount of code to access active directory and authenticate.Please refer the article on codeproject.com or msdn articles.
Maybe you could use this tag in your web.config
<authentication mode="Forms">
<forms loginUrl="login.aspx" defaultUrl="Login.aspx" timeout="60"></forms>
</authentication>
And in your login.aspx you would write code to access Active Directory.
You are missing the point about what windows authentication is. Forms authentication can be used when not part of a domain or there is some specific requirement that windows authentication cannot solve. If a computer is registered in an active directory domain, authentication with the web site will be transparent based on the credentials that were used to login to the domain, eliminating the need to supply credentials each time the application is accessed.
I have a pair of websites I am building in Asp.Net. In development, they are both on my machine. One is hosted in IIS and one is in IISExpress. I have configured both websites to use FormsAuthentication, and set the same authentication and httpCookies elements in each web.config:
<authentication mode="Forms">
<forms loginUrl="~/LogOn" timeout="2880" domain=".mydomain" />
</authentication>
<httpCookies domain=".mydomain" requireSSL="false"/>
However, after a standard FormsAuthentication.SetAuthCookie , the second site cannot read the .ASPXAUTH cookie from the first. It CAN read the same Asp.Net_SessionID cookie from the other website. So, one cookie is being passed across applications, but the second is not.
Additionally, when the debugger is attached to the second application and it receives the redirect from the from the first site, the Chrome debugger shows both cookies, Fiddler reports that both cookies were transmitted, and the Response.Headers["cookie'] contains the .ASPXAUTH cookie.
How can I effect this cross-application sign-on? In production, these two sites will answer on separate sub-domains.
I've found the answer to my problem.
IISExpress and IIS use separate MachineKey values, even though they are originating on the same physical machine. To solve my problem, I generated a MachineKey entry at http://aspnetresources.com/tools/machineKey and dropped the same MachineKey element into all participating application's web.config files.
Thanks to Robert Smith #smithrobs on Twitter for suggesting I check this line of the problem.
I've got the following structure
www.website.com --> ASP.NET 4.0 Web-site
www.website.com/blog --> NET 4.0, Web-Application
Both do form-authentication against the same SQL database and use the framework ASP.NET memberships and roles. I can log into each portion just fine (same user/password) but the authentication doesn't carry over i.e. if I log into / and then click a link to /blog/, /blog/ thinks I'm Anonymous and prompts for login again. I've done the basics
i.e.
Identical <authentication mode="Forms"> in both the site as well as app web.configs
Identical <machineKey> section (yes, identical validationKey and decryptionKey)
So I then inspected the cookies generated and noticed that website and the web application seem to be working on different cookies.
Cookies created by website.com/blog
.ASPXFORMSAUTH-27604f05-86ad-47ef-9e05-950bb762570c
.ASPXROLES
Cookies created by website.com
.ASPXFORMSAUTH
I think this is the problem, although I see it despite having identical <authentication> sections which looks like
<authentication mode="Forms">
<forms timeout="30" slidingExpiration="true" name=".ASPXFORMSAUTH" enableCrossAppRedirects="true" protection="All" cookieless="UseCookies"/>
</authentication>
I did read several other posts like
Single Sign On with Forms Authentication
as well as
http://msdn.microsoft.com/en-us/library/eb0zx8fc.aspx
There were also a few other posts I can't recall now. I've gone through them (all?) but am still stuck. I can gladly supply more debug data if needed.
Would really appreciate any tips someone might have! I think I'm hitting a wall on this one!
Ok, so I was able to answer my own question after beating around it for longer.
Basically, BlogEngine.NET 2.5 (my web-app) seems to be overriding the .NET 4.0 framework way of doing things. There are a couple of things you need to fix, all within BlogEngine.Core\Security\Security.cs (download the BlogEngine.NET source code)
Part 1: Fix cookie name
In there is a method FormsAuthCookieName which I changed as follows:
File: BlogEngine.Core\Security\Security.cs
Method: FormsAuthCookieName()
// return FormsAuthentication.FormsCookieName + "-" + Blog.CurrentInstance.Id.ToString();
return FormsAuthentication.FormsCookieName;
This ensures that the cookie names are the same. One hurdle down ...
Part 2: Avoid web-app/BlogEngine.NET's login page/controls/code
Instead of directing users log into the BlogEngine.Net's login.aspx (www.website.com\blog\account\login.aspx), I pointed all login links to my main website's login.aspx page (www.website.com\login.aspx). In case you're wondering how to implement you own site-wide authentication, this is a super-quick guide
msdn.microsoft.com/en-us/library/ff184050.aspx.
I also had to add something like this to both the website web.config as well as the web-app web.config, so anytime a protected resource is accessed (from website or web app) my own global /login/aspx is used.
<authentication mode="Forms">
<forms timeout="30" loginUrl="/login.aspx" blah blah />
</authentication>
Now, my own generic, site-wide user login controls will be creating the (.NET framework standard) authentication cookies and the (user) role cookies. By avoiding the BlogEngine.NET's login.aspx we're cleaner plus we avoid calling this code which is problematic.
File: BlogEngine.Core\Security\Security.cs
Method: AuthenticateUser(string username, string password, bool rememberMe)
Details:That code adds a "blog instance" into the cookie, so so if you have multiple blogs on the same domain, this prevents user1 authenticated on blog instance 1 from NOT being automatically authenticated on blog instance 2. I'm guessing most will only have one blog per domain (www.domain.com\blog!), so this is unnecessary. More importantly, that check breaks our single sign-on.
Two hurdles down ...
Part 3: Fix Per-access authorization check
Now, our site wide, standardized login.aspx doesn't add the specific BlogEngine.NET instance ID (see above). This would have been ok, except that there is still some BlogEngine.NET code that specifically looks for that. We don't need that check either, so lets remove that offending check...
File: BlogEngine.Core\Security\Security.cs
Method: void Init(HttpApplication context)
// Comment line below to revert to only-framework/default processing
//context.AuthenticateRequest += ContextAuthenticateRequest;
So at this point you should have
All logins handled by a single, site wide login.aspx
All authentication cookies and user role cookies created by the above site wide login.aspx
All such cookies encrypted and protected per of both the website & web-app web.configs (which should match!)
Which in turn allows single sign on :) !! Hooray !
In addition: in both web.configs you must insert machinekey with the same validationKey and the same decryptionKey.
I have an ASP.NET MVC2 app using jQueryMobile. It is a secure app, and i'm using the ASP.NET authentication within the MVC2 framework.
I am using standard authentication via the web.config:
<authentication mode="Forms">
<forms loginUrl="~/Account/LogOn" timeout="2880" />
</authentication>
I am securing certain controllers using the Authorize attribute:
[Authorize]
public class ClientController : Controller
All my web pages as based upon the same master page, which has a top-level container div as follows:
<div class="page" data-role="page">
It all works perfectly on Chrome. However, on the iPad the authentication does not work. It seems that the authentication cookie never gets stored on the client. The iPad keeps displaying the logon page, even if I type correct credentials. I have tried setting Safari Accept Cookies settings to 'Always' too.
Has anyone had any success deploying a jQueryMobile app using ASP.NET MVC2 authentication on an iPad? Thanks.
Edit: Ok, I have ascertained that the cookie is indeed being stored on the client, but it appears that jQueryMobile+Safari are somehow consipring to continually display the login page rather than redirecting me to the page that should be shown according to the logon redirect.
I believe I have the answer. With regard to the iPad, you need to specifically set web.config to force the use of cookies. My authentication setting in web.config now looks like this:
<authentication mode="Forms">
<forms loginUrl="~/Account/LogOn" timeout="2880"
cookieless="UseCookies"
/>
</authentication>
It is the cookieless="UseCookies" entry that solved the problem. The default value for this is UseDeviceProfile. It must have been the case that an iPad does not have a consistent UseDeviceProfile regime. On the iPad, sometimes it worked, sometimes it didn't. Don't ask me why. It now seems to be consistently working.
I agree with Journeyman, thats what I used. However if they add the website to the Homescreen, then these settings still do not work.
some have asserted they don't store the cookie in that case.
see related Q: iPhone/iPad WebApps don't allow cookies?
I'm seeing some new behavior in Forms Authentication after upgrading to .NET 4.0. This occurs only on IIS 6, not on 7.
Background - In web.config, we configure Forms Authentication, and then use <authorization> tags to globally deny anonymous/unauthenticated users access. Then we explicitly allow access to a login.aspx page using a <location> tag. Generally, this works fine, as it did when we were on .NET 2.0 (3.5).
The issue only occurs when we visit the root path of the site, ie "http://myserver/". Our default document is configured in IIS to be login.aspx. Under .NET 4.0, upon visiting that URL, we're redirected to "http://myserver/login.aspx?ReturnUrl=/". If you log in from here, you're logged in and returned back at the log in page (yuck).
Just wanted to post this here to see if anyone else is experiencing this. It's not listed on any "breaking changes" documentation I've been able to find. Either I'm missing something, or the UrlAuthorization module has changed and is no longer "smart" about IIS default documents.
You shouldn't have IIS defaulted to login.aspx.
ASP.NET have its own mechanisms for ensuring authenticated access.
In particular for any unauthenticated request to a content which requires authenticated users it will redirect it to the page specified in loginUrl attribute of the Web.config authentication\forms element.
...
<authentication mode="Forms" ...>
<forms name="login" loginUrl="login.aspx" ... />
</authentication>
...
('login.aspx' is a default value for that property)