I have an inherited application (let's call it app.mydomain.com) that I'm trying to update the domain in the cookie that gets set via the web.config. Currently, its something like this:
<authetication mode="Forms">
<forms loginUrl="~/" timeout="2880" cookieless="UseCookies" domain=".mydomain.com"/>
</authentication>
There is separate application at app2.mydomain.com also using forms authentication, and the cookie from the app.mydomain.com conflicts with it. The app2.mydomain.com correctly references the full domain in its forms authentication block so it works fine as long as the app.mydomain.com cookie isn't around. My plan was to simply change the .mydomain.com reference in the web.config to app.mydomain.com to resolve this conflict.
My question is how does that existing cookie on app.mydomain.com behave once that web.config is updated in production? Does it overwrite the existing cookie as it sees this update? Does the existing cookie stick around and have to be flushed out before the new one will take effect? Thanks in advance.
So I ended up approaching this a bit differently. It hadn't occurred to me, but it was setup this way to accommodate the app and api being on different subdomains. By setting it to .mydomain, both could access the authentication cookie. When I removed the domain attribute, I was able to login but threw me back to login right away. So I ended up keeping this application using this format (.mydomain), then changed the second application to use it as well. This allows for one login sets credentials that are accessible to both applications. I was just trying to resolve the cookie conflict, but this is even better.
Related
I am working on ASP.Net MVC-4 application. I have to implement windows authentication.
I have set authentication mode as 'Windows' in web.config file as shown below.
<system.web>
<authentication mode="Windows" />
</system.web>
In controller I try to get username as below.
string userName = User.Identity.Name;
but every time I am getting empty value.
Please let me know for any suggestions.
Thanks in advance.
Windows authentication is performed by IIS to establish our managed code User.Identity. Therefore, you need to enable Windows Authentication in your IIS, and in order to force the user to authenticate before being able to access our application, you need to disable Anonymous Authentication
With the given information, it looks like you've configured your project correctly but haven't actually authenticated the user yet.
First some background. There is a simplified tutorial on asp.net where, in between the lines, the following statement is mentioned:
By default, the ASP.NET Development Web Server executes all pages in the context of the current Windows account (whatever account you used to log into Windows).
This means that when you run your project with F5, it executes everything under your currently logged in user account. However, it isn't yet authenticated for the application and therefor your User.Identity.* is not set yet.
In order to verify if this is the case, you should add the [Authorize] attribute on the first controller (or Action) that is called in you ASP.NET MVC project. Most likely you'll be confronted with a "HTTP Error 401.0 - Unauthorized" exception. In this case, you should enable your webserver to authenticate first. The above mentioned tutorial will help you with this.
I have created 2 webapplication in Visual Studio 2013 using C#.
I have registered 2 new users in both the applications.
Now if I run both the application in Google Chrome. I am getting the following;-
1) If I login in one website and if I refresh the other website page. It is also logged in.
How can i make it seperate, so that both can have there seperate users?
Has it someting to do with Context.User.Identity, are both site using same cookies??
Please help me in understanding it.
Thanks
Assuming you haven't explicitly changed the authentication configuration in the web.config across both websites, then the behaviour you are seeing is by design.
To configure forms authentication across applications, you set attributes of the forms and machineKey sections of the Web.config file to the same values for all applications that are participating in shared forms authentication.
...Unless otherwise noted, the name, protection, path, validationKey, validation, decryptionKey, and decryption attributes must be identical across all applications.
So, if you want an independent ticket for each site, the easiest solution would be to give each site it's own distinct ticket name
<forms name=".ASPXFORMSAUTH_SITEA" ... />
<forms name=".ASPXFORMSAUTH_SITEB" ... />
For security purposes, you might also want to consider using different encryption/decryption keys as well.
You can make the logins seperate by doing the following (my guess is that you want the sessions seperate as well), which Microsoft advise to do if running multiple websites from a web server, most likely to avoid this cross cookie issue...
In your web.config give the session and the authentication cookies unique names, e.g.
<sessionState cookieName="UNIQUESESSION1" timeout="20"/>
and
<forms timeout="2880" name="UNIQUEAUTH1" />
I have two applications. The first one is an ASP.NET 4 MVC application that requires authentication. The second is an app that will handle the authentication and set the forms authentication cookie.
On the authorizing app, I call
FormsAuthentication.SetAuthCookie(username, false);
and then I do a simple Response.Redirect back to my MVC application.
In the MVC app, I am making a custom filter that inherits from AuthorizeFilter. On the OnAuthorization method, I was going to decrypt the cookie and grab some additional user data from the authorized user.
My problem is, that
HttpContext.Current.Request.Cookies
has nothing in it. I have checked out fiddler, and the authentication app correctly sets the cookie, and the MVC application gets the cookie, but when it gets to my filter, there is nothing there.
My web.config has in both applications has the exact same setup:
<forms
name=".ASPXFORMSAUTH"
protection="All"
path="/"
timeout="30"
enableCrossAppRedirects="true"
domain="localhost"/>
And I have setup both with the same machineKey to be able to decrypt the cookie. The problem is, I am not seeing any cookie in my OnAuthorization method within my MVC filter.
Right now both applications are running on my local IIS instance.
All the weird behavior was due to the httpRuntime between each application being different. My MVC application was set to 4.5 while my application that was setting the cookie was 4.0. Apparently there was a change in how the crypto happens behind the scenes, and therefore when the cookie came through the pipeline, it would get stripped out as ASP.NET couldn't decrypt it.
I came across this when I manually tried to decrypt the cookie by setting the name property different. That way I could access the cookie and try to dectypt, but at that point I would get an exception.
I found the following link led me in the right direction: Sharing a cookie between two websites on the same domain
By setting the compatibility mode setting on the machine key, the cookie came through just fine and could be decrypted.
Imagine when you create a new MVC4 Project and you start registering an account using SimpleMembership and you logged using Remember Me checkbox.
Now, when you create another MVC 4 Project, the application tries to loggin using the previous account, although throws an error because it does not exist. I mean, if a do a login in a web page, the another one uses the same account.
How can avoid this, I guess has to be with ForgeryTokens or something like that
Customize the name of the cookie so that it's unique per application.
<authentication mode="Forms">
<!-- **Defaults** timeout="30" slidingExpiration="true" -->
<forms name=".MyApplication" defaultUrl="~/" loginUrl="~/LogIn" />
</authentication>
if you are using a single sign on mechanism then it is a exceptionable scenario but if you do not wish to allow the same authentication with same account to another website then make sure the web.config file for both projects must have a different machine keys.
Also, this is happened because of cookies on your machine is set to true, to create cookies file and allow access to other project using this cookies details.
< Authentication />
It happens because when the web page is served the browser sees localhost as the domain name. It saves the cookie for localhost.
When you host another website on the same server with localhost, then the browser sends the same cookie again.
If you are using the same cookie name in both the applications, then the system will try to think that the user is already authenticated and you will get the error.
You can change the cookie name in web.config file.
Read this:
Can I change the FormsAuthentication cookie name?
"Have you ever done any .net programming? Yes? Good, here's a massive broken program, fix it". That is the situation I'm in, so sorry if it's an easy question.
The program I am working on pulls a file from a web server. It is expected that the user is already logged into the web server. I need to pull the username of the current person logged into the server (or just make sure someone is indeed logged into the server).
I have tried the following and it returns an empty string.
user = HttpContext.Current.User.Identity.Name;
Please make sure you are setting windows authentication in Web.Config file. Also check the following before accessing the username,
HttpContext.Current.User.Identity.IsAuthenticated
Set Web.Config as follows,
<authentication mode="Windows"></authentication>
First check in Web.config file for <authentication> tag.
If you don't find it then your application may not be using any standard authentication mechanism. If that is the case look inside the login.aspx or whatever code that does the authentication. There you will get hold of logged in user data.
I wouldn't recommend you to change anything in web.config file without having some firm grasp on whats going in the application.
The properties of the User object are usually populated by the application's authentication scheme (Forms, Windows or Custom) so you'll need to ensure one of these is in place before commencing to access the User.
For more information, take a look at the docs at MSDN.