I am using Forms Authentication and have the basic logon page and default page.
When I am on the logon page, and call the SignOn this works just great. However, when I am still on the Logon page the Membership.GetUser() returns null. When I redirect to my default page, the Membership.GetUser() returns my user information.
Is there any way I get get this method to return my user while still on the logon page. I have read all over google that other have similar issues where it will only work once you redirect.
Let me know if you need further information.
Here is a simple code snippet of what I am using to verify that the information is being set:
bool authenticated = User.Identity.IsAuthenticated;
string username = User.Identity.Name;
MembershipUser user = Membership.GetUser();
I put this code on both the logon page and the default page in the code behind and only the default page has values and shows that it is authenticated after the authentication process executes.
Something else to try is the following code:
MembershipUser user = Membership.GetUser(username);
GenericIdentity identity = new GenericIdentity(user.UserName);
RolePrincipal principal = new RolePrincipal(identity);
System.Threading.Thread.CurrentPrincipal = principal;
HttpContext.Current.User = principal;
This might be because you allow anonymous users on your login page. Therefore the browser doesn't bother sending any more information to this page than is necessary.
I was in this same situation, here is what worked for me on MVC 4 .NET 4.5.
Membership.GetUser(HttpContext.Current.User.Identity.Name)
I had a similar issue and the problem turned out to be that I was missing authentication method = form in the web config .
<system.web>
<authentication mode="Forms"/>
....
Don't forget that one (I was migrating an old legacy site to aspnet)
I had this issue and found it was due to having multiple membership providers, so instead of
Membership.GetUser()
you can try
Membership.Providers["MyMembershipProvider"].GetUser()
or more specifically
Membership.Providers["MyMembershipProvider"].GetUser(LoginCtrl.UserName, false)
I had a similar problem (it was all pages on the site) and it was caused by an error in the AspNetSqlMembershipProvider connection string, which SHOULD have been different in different environments but wasn't, so it worked locally but not when deployed to the server.
Related
We have a straight forward ASP.NET web application with a login page. After the user enters credentials and submits the form, the server processes the details and if successful, Response.Redirect()'s the user to the Main Menu page. (We also have a navigation bar where the user can navigate to other pages via similar response.redirects)
One of our customers is setting up an IBM Data Power Web Application Firewall, and has told us this Redirect after a POST is an RFC violation and consequently the application does not work.
There are a few questions here that are related to Get/Post/Redirect, and they indicate that its up to the discretion of the browser to use the 302 response as a get or a post. I have also found other links on the public internet that lead me to believe this something the IBM device could be configured to handle.
Before I suggest changing the IBM device configuration, are there any configuration based (or simple code) ways to make a trivial login page (not using the asp.net login control) work where a GET request can send the login credentials, or make all postbacks in the site use a GET instead of POST?
Also, if anyone has tips for working with this IBM device, they would be appreciated.
An example of the code...
var userName = txtUserName.Text.Trim();
var password = txtPassword.Text.Trim();
var authResult = GetAuthService().AuthenticateUser(userName, password);
if (authResult == true)
{
//set forms auth cookie
Response.Redirect("Menu.aspx", false);
}
else
{
lblError.Text = "Unable to login";
}
A POST followed by a redirect is a usual mechanism found in many implementation. For example, consider using JAAS authentication. You present a form to a user and it is posted on '*/j_security_check' URL. Once authenticated you are redirected to a resource page, else you are re-directed to an error page.
I am not sure what is configured on datapower, but if your developer is using MPGW construct for this, then he can try playing around with two properties found in 'Advanced' tab of it. One is 'follow redirects' and another one is allow 'empty request'.
May be this helps you.
ASP.NET Web Forms applications.
I checked our company's legacy code, the way they do login is like this:
when user is validated against database with (username, password), they set a session:
Session["authenticated"] = "true";
Every page other than login.aspx is inherited from a class named SecurePage. In SecurePage's OnInit() method, it checks
if (Session["authenticated"] != null)
if true, means authenticated, otherwise means not. So basically the way to do authentication is to see if there is a session named authenticated.
This seems the most crude and intuitive way of doing authentication... I want to ask: is this safe?
Another thing I feel strange is that in the web.config, they have this:
<authentication mode="Windows" />
Shouldn't it be
<authentication mode="Forms" />
since these are web applications? Users credentials are stored in database and these users are outside clients (not internal users).
A slight different version also does this after user is validated against database:
FormsAuthentication.SetAuthCookie( username, true );
what does this do? Besides this statement in login.aspx, I don't see any other pages have any code related to auth cookie. Do we need to set auth cookie by ourselves in code or does .NET framework handle this for us already?
Still another version have the following:
FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(login, false, 60);
HttpCookie cookie = new HttpCookie(FormsAuthentication.FormsCookieName, FormsAuthentication.Encrypt(ticket));
Response.Cookies.Add(cookie);
what does this do? Do we need to set this cookie by ourselves in code? or does .NET framework handle this for us already?
These web appliations were developed a long time ago, though I am not sure when. I suspect it is .NET 1.0 era? From my understanding since .NET 2.0,
it has this ASP.NET membership thing, and we can just use <authentication> and <authorization> tags in web.config (and subfolder web.config) to achieve the goal of authentication and authorization. Isn't it? Can anyone give me a history of ASP.NET framework authentiation mechanism? (membership -> simple memebership -> Identity?)
<authentication mode="Windows" />
Above should be used mostly in intranet website, because it's like saying use the computer(windows pc) authentication to access the resource. However, this will never work, since inherited class has a method to validate session key value for a login.
You should make sure that the code redirects user to login page in case the session key is not found. That means, in the else section of below code, you should take users to login page to try again. Which I am sure is happening.
if (Session["authenticated"] != null)
{ /*user is authenticated*/ }else{ /*redirect to login*/ }
Its is recommended to use <authentication mode="Forms" /> if the website is accessible over the internet. Other benefit of using this setting is that you can set default and login page.
Finally, FormsAuthenticationTicket is a class with property and values that are used when working with Forms authentication to identify authenticated users.
Read through msdn article to know more about asp.net membership.
https://msdn.microsoft.com/en-us/library/yh26yfzy%28v=vs.140%29.aspx
In SharePoint Application When Claims Based Authentication types are enabled, a URL for redirecting the user to the Sign In page is required.
I want to get that Which Login Page is set Either default or Custom and if it is custom i want to get the 'Custom Sign in Page' URL programmatically.
Read this, explains how it works:
"http://blog.octavie.nl/index.php/2012/06/11/custom-sign-in-and-sign-out-page/"
You do not have to provide a URL if using Windows Authentication in claims mode. The default login page is _login/default.aspx If a custom login page is used, it will be listed in central admin.
A URL for redirecting the user to the Sign In page is required only when using a trusted identity provider. In that case you can get the login page by setting the identity provider to a variable ex. $TIP = Get-SPTrustedIdentityTokenIssuer "YourTrustedIdentityProviderName" then running $TIP.ProviderUri
That will show the host that is being redirected to for login.
I know it's been a long time this post was answered but I was looking up how to get the custom sign in page Url programatically. This is not very documented so here's what I've found:
Get a SPWebApplication object (in my case I used an SPSite.WebApplication property.)
Find the WebApplication IisSetting that has FormsClaimsAuthentication
Get the Claims Authentication Login Redirection Url
Here:
using (SPSite site = new SPSite("http://mysiteurl")
{
foreach(KeyValuePair<SPUrlZone, SPIisSettings> zone in site.WebApplication.IisSettings)
{
if(zone.Value.FormsClaimsAuthenticationProvider != null)
{
string customSignInPageUrl = zone.Value.ClaimsAuthenticationRedirectionUrl;
}
}
}
This gave my the relative path to the custom Sign In page I've set in my central admin.
In my case I was coding my own FBA management solution and I wanted the admin to be able to go see the login page even when already logged in.
I have a scenario in which I need to create a cookie before user is authenticated by my MVC application. Now, here, login is done using external application. (which lies on different server). For this, I did below code in my local environment. I am overriding built-in Authorize attribute and use my custom attribute.
protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
{
HttpCookie _testCookie = new HttpCookie("myCookie");
_redirectCookie.Value = "someValue";
HttpContext.Current.Response.Cookies.Add(_testCookie);
base.HandleUnauthorizedRequest(filterContext);
}
Above code works if I have local url in tag in my web.config. Can somebody please tell me if the same will work with external login url or not?
Thanks in advance,
Suhani.
Well.. solved it.. I just had to use the same domain name while creating this cookie so that the consuming site can see the cookie created by the original site. Deployed the same code (adding domain name while creating a cookie) and it worked.
thank you anyways!
I have multiple subdomains trying to use a single subdomain for authentiction using forms authentication all running on windows server 2008 r2.
All of the forms authentication pages are setup to use the same name, and on the authentication page the cookie is added with the following snippet:
FormsAuthentication.SetAuthCookie(txtUserName.Text, false);
System.Web.HttpCookie MyCookie = System.Web.Security.FormsAuthentication.GetAuthCookie(User.Identity.Name.ToString(), false);
MyCookie.Domain = ConfigurationManager.AppSettings["domainName"];
Response.AppendCookie(MyCookie);
When I am logged in to signon.mysite.com the page.user.identity.isauthenticated and page.user.identity.name properties both work fine. When I navigate to subdomain.mysite.com the page.user.identity.isauthenticated returns true, bue the name is empty.
I tried to retrieve it from the cookie using the following, but it also was blank.
HttpCookie cookie = Request.Cookies[".ASPXAUTH"];
FormsAuthenticationTicket fat = FormsAuthentication.Decrypt(cookie.Value);
user2_lbl.Text = fat.Name;
When googling the issue I found some people saying something must be added to global.asax and other saying it wasn't necessary.
The goal is to be able to login on the authentication subdomain and have the user identity accessible from the root site and other subdomains. Machine keys match in all web.config, and the AppSettings["domainName"] is set to "mysite.com" currently.
Does anyone know what is preventing me from accessing the user information?
Change "mysite.com" to be ".mysite.com" (note the leading ".").
That'll tell the browser that the cookie is valid for subdomains as well.