I have a ASP.NET MVC3 website. I integrated Yaf 1.9.6.1 into my website's /forum folder successfully. And I have same users in my two user tables. How Can I login yaf with my web sites login?
Resolved.
I created machine key and I used it on application and child application's web config.
And I used yaf.net cookie in my login page.
This is my code:
FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(1, Form.email, DateTime.Now, DateTime.Now.AddMinutes(30), false, "", "/");
string strEncTicket = FormsAuthentication.Encrypt(ticket);
HttpCookie authCookie = new HttpCookie(".YAFNET_Authentication", strEncTicket);
authCookie.Path = "/";
HttpContext.Response.Cookies.Add(authCookie);
Related
I am creating a single page application with angularJs, aspnet and thinktecture. I have created a login screen in thinktecture (as localhost:44304) for customer login and after successful login, it redirects to customer portal like https://localhost:44302.
when I run the customer app then it redirected to thinktecture login screen and after a login success, it come back to customer portal.
Now issue is that any customer can register a request by using registration page which is placed on the customer portal and we are redirecting it from thinktecture login screen as shown
When I click on "here" link then redirect me again same login screen.
I added the code as below in startup.cs for customer poratal.
System.Threading.Thread.CurrentThread.CurrentCulture = new CultureInfo("en-us");
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = "Cookies"
});
string thinkTectureUrl = ConfigurationManager.AppSettings["ThinkTectureUrl"].ToString();
string loginSuccessUrl = ConfigurationManager.AppSettings["LoginSuccessUrl"].ToString();
string clientSecret = ConfigurationManager.AppSettings["ClientSecret"].ToString();
app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions()
{
ClientId = "Provista.CustomerPortal.WebApp.External",
Authority = thinkTectureUrl,
RedirectUri = loginSuccessUrl,
ResponseType = "id_token",
Scope = "openid email",
SignInAsAuthenticationType = "Cookies",
ClientSecret = clientSecret.Sha256()
});
I searched on google and stackoverflow a lot but didn't get a reliable link that help me to solve this.
Please reply as soon as possible if any one have any idea.
You might have global authorization filter which redirects unauthenticated users to identity server. Probably in Global.asax
filters.Add(new System.Web.Mvc.AuthorizeAttribute());
Requests to your 'Register User controller' also treated by this filter and redirect to identity server will happen.
To override global filter and allow unauthenticated users to your Register User controller use [AllowAnonymous] attribute in your 'Register User controller'.
I'm trying to configure DEV environment to support sub-domains with sharing authentication and session between them.
Currently, I configured IIS and hosts file on DEV machine to handle requests for mydomain, sd1.mydomain, sd2.mydomain, sd3.mydomain. Web application itself working as expected, I can browse all pages on all sub-domains, except the pages that requires authentication. When I try to log in, everything looks perfect on server side (user found, cookie created and added to response), but the cookie not arrives to browser (I tried Chrome and IE).
I have a code that creates and stores authentication ticket and I set domain=".mydomain" in authentication.forms in web.config:
var now = DateTime.UtcNow.ToLocalTime();
var ticket = new FormsAuthenticationTicket(
1 /*version*/, _user.Username, now, now.Add(FormsAuthentication.Timeout),
isPersistentCookie, _user.Username, FormsAuthentication.FormsCookiePath);
var encryptedTicket = FormsAuthentication.Encrypt(ticket);
var cookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);
cookie.HttpOnly = true;
if (ticket.IsPersistent)
{
cookie.Expires = ticket.Expiration;
}
cookie.Secure = FormsAuthentication.RequireSSL;
cookie.Path = FormsAuthentication.FormsCookiePath;
if (FormsAuthentication.CookieDomain != null)
{
cookie.Domain = FormsAuthentication.CookieDomain;
}
_httpContext.Response.Cookies.Add(cookie);
When I debug, the code above works fine, the user is correct and cookie with correct domain is added to response.
If I remove domain=".mydomain" from web.config, authentication works, but only on mydomain and not on sub-domains.
What I'm doing wrong?
Remove the dot on the beginning, from the domain=, you must have it as domain=".mydomain.com" with the first dot as stated here http://www.w3.org/Protocols/rfc2109/rfc2109 (page 7), thanks for the comment of #AlbatrossCafe
This setting is both on cookie and on authentication.
Nothing wrong. If the domain is not provided on a cookie, the cookie is supposed to work only for issuing domain.
I am getting 403 when a user accidentally closes their browser without logging out and tries again to open the url.
When they check back, website throws 403. To temporarily resolve the issue I clean out all the cookies and the access is back on.
Error:
403 - Forbidden: Access is denied.
You do not have permission to view this directory or page using the credentials that you supplied.
Details to troubleshoot:
Web.Config file
<forms loginUrl="index.aspx"
protection="All" path="/"
timeout="300"
name="AppNameCookie"
slidingExpiration="true"
defaultUrl="index.aspx"
cookieless="UseCookies"
enableCrossAppRedirects="false"
requireSSL="false"/>
Code to authenticate users
' Create the cookie that contains the forms authentication ticket
Dim authCookie As HttpCookie = FormsAuthentication.GetAuthCookie(sUserName, False)
'HttpOnly cookie means it is not accessible by the client through ECMAScript.
authCookie.HttpOnly = True
authCookie.Expires = Now.AddMinutes(300)
' Get the FormsAuthenticationTicket out of the encrypted cookie
Dim ticket As FormsAuthenticationTicket = FormsAuthentication.Decrypt(authCookie.Value)
' Create a new FormsAuthenticationTicket that includes our custom User Data
Dim newTicket As FormsAuthenticationTicket = New FormsAuthenticationTicket(ticket.Version, ticket.Name, ticket.IssueDate, ticket.Expiration, ticket.IsPersistent, userDataString)
' Update the authCookie's Value to use the encrypted version of newTicket
authCookie.Value = FormsAuthentication.Encrypt(newTicket)
' Manually add the authCookie to the Cookies collection
Response.Cookies.Add(authCookie)
' Determine redirect URL and send user there
I think there is an issue with the cookies but I am unable to figure the root cause for this issue.
UPDATE: I found how to duplicate this issue
Login as a user and close the browser without logging out.
Try to open the home page and it throws error.
Issue has been resolved.
The conflict was with the AuthCookie in the login page and the following line was causing the problem.
authCookie.HttpOnly = True
authCookie.Expires = Now.AddMinutes(120)
Dim ticket As FormsAuthenticationTicket = FormsAuthentication.Decrypt(authCookie.Value)
Dim newTicket As FormsAuthenticationTicket = New FormsAuthenticationTicket(ticket.Version, ticket.Name, ticket.IssueDate, ticket.Expiration, False, userDataString)
authCookie.Value = FormsAuthentication.Encrypt(newTicket)
Replaced with the following lines they work fine.
Dim asx As New FormsAuthenticationTicket(sdata, False, 60)
Now encrypt the ticket.
Dim encryptedTicket As String = FormsAuthentication.Encrypt(asx)
Dim authCookie As New HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket)
Response.Cookies.Add(authCookie)
I have a site that works as expected on my development box. That is, the formsauthentication ticket expires after 30 days. This is achieved through the following code
string roles = UserManager.getAuthenticationRoleString(txtUsername.Text);
HttpCookie formscookie = FormsAuthentication.GetAuthCookie(txtUsername.Text, true);
FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(formscookie.Value);
FormsAuthenticationTicket newticket = new FormsAuthenticationTicket(1, ticket.Name, DateTime.Now, DateTime.Now.AddDays(30), true, roles, ticket.CookiePath);
HttpCookie newCookie = new HttpCookie(FormsAuthentication.FormsCookieName, FormsAuthentication.Encrypt(newticket));
newCookie.Expires = DateTime.Now.AddDays(30);
Response.Cookies.Add(newCookie);
I used fiddler to check that the expiration is set properly and I get this
.ASPXAUTH=84AB5430CF4B1C5F9B59C9285288B41F156FCAFA2A169EACE17A7778A392FA69F66770FD8A08FFD06064B00F0BD788FEEC4A5894B7089239D6288027170A642B3B7EB7DB4806F2EBBCF2A82EE20FD944A38D2FE253B9D3FD7EFA178307464AAB4BCB35181CD82F6697D5267DB3B62BAD; expires=Thu, 21-Jan-2010 18:33:20 GMT; path=/; HttpOnly
So I would expect it to expire in 30 days...But it only makes it about 30 minutes.
I have 3 other interesting tidbits about my environment / code
On the production box there are two sites pointing at the same code one for external access and one for internal access
When the I do get the login page because of premature expiration, the .ASPAUTH cookie is still there and sent to the browser
There is some role checking in the global.asax that looks like this
-
protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
if (HttpContext.Current.User != null)
{
if (HttpContext.Current.User.Identity.IsAuthenticated)
{
if (HttpContext.Current.User.Identity is FormsIdentity)
{
FormsIdentity id = (FormsIdentity)HttpContext.Current.User.Identity;
FormsAuthenticationTicket ticket = id.Ticket;
// Get the stored user-data, in this case, our roles
string userData = ticket.UserData;
string[] roles = userData.Split('|');
HttpContext.Current.User = new System.Security.Principal.GenericPrincipal(id, roles);
}
}
}
}
You'll need to add a machine key tag to web.config file. It's getting regenerated and that causes your premature timeout.
This is similar to the following question:
figuring out why asp.net authentication ticket is expiring
If the problem is that the user on the production box is kicked and has to log in again via FormsAuthentication, it's possible that the problem is IIS related and not .NET.
I've run into issues before where all the timeout settings in the world within the app didn't make a difference and the user was booted far too early.
Check your IIS settings for both the website and the application pool. There are settings in both related to timeouts, etc.
If II6:
Under website properties -> Home Directory tab -> Configuration Button -> Options Tab -> there is session state/length info here
Under application pool for your site -> Performance and Health tabs -> both have several settings that may recycle your pool (and essentially force a re-logon)
To debug, you could disable all health and performance checks on the pool, however be very careful as this could throttle your server if the app gets out of control.
You could also try putting the timeout settings in the web.config:
<system.web>
<authentication mode="Forms">
<forms timeout="XXXXX"/>
</authentication>
</system.web>
Anyway just some ideas from personal experience of similar issues. Hope it might help!
Bug:
I've got an ASP.NET web application that occasionally sets identical cookie keys for ".www.mydomain.com" and "www.mydomain.com". I'm trying to figure out what default cookie domain ASP.NET sets, and how I accidentally coded the site to sometimes prepend a "." to the cookie domain.
When 2 cookies have the same key and are sent up from the browser, the ASP.NET web application is unable to differentiate between the two because the domain value is not sent in the header. (See my previous question)
Evidence:
I've enabled W3C logging on the web server and verified that both cookies are sent from the client. Here's an example from the log file (paired down for brevity).
80 GET /default.aspx page= 200 0 0 - - - - - +MyCookie2=sessionID=559ddb9b-0f38-4878-bb07-834c2ca9caae;+MyCookie2=sessionID=e13d83cd-eac2-46fc-b39d-01826b91cb2c;
Possible Factor:
I am using subdomain enabled forms authentication.
Here's my web.config settings:
<authentication mode="Forms">
<forms domain="mydomain.com" enableCrossAppRedirects="true" loginUrl="/login" requireSSL="false" timeout="5259600" />
</authentication>
Here's and example of setting custom cookies:
HttpCookie cookie1 = new HttpCookie("MyCookie1") {HttpOnly = true, Expires = expiration};
logosCookie["email"] = user.Email;
logosCookie["keycode"] = user.PasswordHash;
logosCookie["version"] = currentCookieVersion;
context.Response.Cookies.Remove("cookie1");
context.Response.Cookies.Add(cookie1);
// set FormsAuth cookie manually so we can add the UserId to the ticket UserData
var userData = "UserId=" + user.UserID;
FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(2, user.Email, now, expiration, true, userData);
string str = FormsAuthentication.Encrypt(ticket);
HttpCookie cookie = new HttpCookie(FormsAuthentication.FormsCookieName, str)
{
HttpOnly = true,
Path = FormsAuthentication.FormsCookiePath,
Secure = FormsAuthentication.RequireSSL,
Expires = ticket.Expiration
};
if (FormsAuthentication.CookieDomain != null)
{
cookie.Domain = FormsAuthentication.CookieDomain;
}
context.Response.Cookies.Remove(FormsAuthentication.FormsCookieName);
context.Response.Cookies.Add(cookie1 );
Here's another example of setting a cookie.
var cookie2 = new HttpCookie("MyCookie2");
cookie2[CookieSessionIdKey] = Guid.NewGuid();
cookie2.Expires = DateTime.Now.AddYears(10);
HttpContext.Current.Response.Cookies.Set(cookie2);
Undesirable Resolution:
I can manually force the cookie domain to be a specific value, but I'd like to avoid explicitly declaring the domain. I'd prefer to use the default framework behavior and change my use of ASP.NET to avoid prepend the "." to the cookie domain for custom cookies.
When no domain is explicitly set by the server on the response, the browser is free to assign the cookie domain value. I haven't figured out exactly what conditions result in the browser setting "www.mydomain.com" vs ".mydomain.com" on a cookie domain when no domain is provided on the response, but it happened.
I have a feeling it's a result of explicitly setting the .ASPAUTH cookie domain value to ".mydomain.com" to enable cross subdomain authentication, while leaving other custom cookie domains set to the default (empty string, or "").
I'm going to go with the undesired solution, and explicitly set the cookie domain for all custom cookies to avoid browser quirks.