This code works fine in all of the browsers. Chrome redirects to the correct URL and displays the content on that page. IE7 + IE8 and Firefox all redirect to the new page, and then display the login box again. So essentially it is treating the user as if they haven't logged in and taking them back to the login page that I specified in the 'Public Access' section.
I have confirmed that the one test user is part of the Group that is specified in the 'Public Access' section of the page that I'm hitting.
I have a login status control on the page that would perform the same functions, but when I step through my code....it's never even hit. It just goes straight from my redirect page back to the login page.
So one point is that you might say to use the login control. the reason that I'm not using it is that the login is actually occuring on a 3rd party service. I'm just using Umbraco's login functionality to protect the back pages from unauthorized use (hence why they all log ino as the same user). I have a bypass set-up to skip the 3rd party system, so I have confirmed that the error is not on that end.
Any direction, ideas or help is greatly appreciated.
The header instructing the browser to redirect could be interfering with the cookie persistence on the client - which would explain why it's a browser issue. Could you post the code for RedirectUser?
Does the behaviour still occurr if you comment-out the actual redirect call, cause the rest of the code to execute (i.e. setting the auth ticket cookie) and then manually going to the destination URL yourself after that in the browser?
I'm currently testing in XP with wildcard mapping on so that I can use directory URL's.
I took off the Public Access and the page now loads up, but without any data. I can step through the my Login Status code and HttpContext.Current.User.Identity.IsAuthenticated is False in Firefox, but true in Chrome. Weird.
Auth ticket cookie is not persisting how - across sessions or page views within the same session? If it's arriving in Firefox but not persisting that could point to an expiry date prob.
At the end of the day, I just changed some values in the <form /> tag in the web.config and it fixed itself. Still don't know why...but man that was painful.
I think it might also have to do with setting a session before the cookie, but who knows.
Login works for Chrome, but not other browsers
I'm having a strange login issue. I'm programmatically loginning in a user:
bool isUserValid = Membership.ValidateUser(umbracoUsername, umbracoPassword); if (isUserValid) { FormsAuthentication.SetAuthCookie(umbracoUsername, true); this.RedirectUser(umbracoUsername, currentEloquaContact); }This code works fine in all of the browsers. Chrome redirects to the correct URL and displays the content on that page. IE7 + IE8 and Firefox all redirect to the new page, and then display the login box again. So essentially it is treating the user as if they haven't logged in and taking them back to the login page that I specified in the 'Public Access' section.
I have confirmed that the one test user is part of the Group that is specified in the 'Public Access' section of the page that I'm hitting.
I have a login status control on the page that would perform the same functions, but when I step through my code....it's never even hit. It just goes straight from my redirect page back to the login page.
So one point is that you might say to use the login control. the reason that I'm not using it is that the login is actually occuring on a 3rd party service. I'm just using Umbraco's login functionality to protect the back pages from unauthorized use (hence why they all log ino as the same user). I have a bypass set-up to skip the 3rd party system, so I have confirmed that the error is not on that end.
Any direction, ideas or help is greatly appreciated.
-C
Oh. This is a 4.5.2 site. This issue happens in both Windows XP and Windows Server 2008.
-C
I'm using directory URL's and Integrated Pipeline in IIS7.
I've tried to disable both and switch to classic, but it still does the same thing.
-C
The header instructing the browser to redirect could be interfering with the cookie persistence on the client - which would explain why it's a browser issue. Could you post the code for RedirectUser?
I've tried both true and false
string redirectUrl = FormsAuthentication.GetRedirectUrl(umbracoUserName, false); string renewalPageUrl = umbraco.library.NiceUrl(MembershipSettings.RenewalPage); if (currentEloquaContact.MyAccountInformation.HasRenewed == false && currentEloquaContact.MyAccountInformation.NumberOfRegularVisits <= 1.0 && !string.IsNullOrEmpty(renewalPageUrl)) { Response.Redirect(renewalPageUrl, false); } else { Response.Redirect(FormsAuthentication.DefaultUrl, false); }Does the behaviour still occurr if you comment-out the actual redirect call, cause the rest of the code to execute (i.e. setting the auth ticket cookie) and then manually going to the destination URL yourself after that in the browser?
Nope. And I can't even get it to hit a break point on any of the sub pages.
In Umbraco, if I change the Public Access Login page, then that is where I get redirected.
I've checked that the cookies exist in Firefox and they do.
I'm completely stumped.
-C
I'm currently testing in XP with wildcard mapping on so that I can use directory URL's.
I took off the Public Access and the page now loads up, but without any data. I can step through the my Login Status code and HttpContext.Current.User.Identity.IsAuthenticated is False in Firefox, but true in Chrome. Weird.
-C
Another strange thing is that in Firefox, I can see my AuthCookie plus my session ID. The session is persisting, but the Authorization is not.
-C
Auth ticket cookie is not persisting how - across sessions or page views within the same session? If it's arriving in Firefox but not persisting that could point to an expiry date prob.
I checked the cookie, it's 30 minutes from when I log in.
At the end of the day, I just changed some values in the <form /> tag in the web.config and it fixed itself. Still don't know why...but man that was painful.
I think it might also have to do with setting a session before the cookie, but who knows.
It's working.
Thanks for your help,
C
I just looked at this (having a similar problem), was it by any chance the cookie name you changed?
Regards
Jonas
Yup. That was one of the things.
-C
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.