I am having trouble with I guess Forms Authentication..
Site runs perfect can login and log out.. but after a while (this is not a specific time frame) suddenly URLs start to look like this:
http://www.mydomain.com/(A(EvoNg_065oCKJ1l_AcU4ND7Uzkm05wugwbYu4jiKb-_24aJmbmE_r5djE-mw9b_3tvEBOLIH1f64rrtq6RZOSFto_o0MaN-3edRpjH2Bfn8uBnrUFhv2xmk4_9oLXHVEt-Dg5BfdPA3VprkCIixmbhr2KPs1))/Default.aspx
What does this encoding (A) mean... is it the authorization ticket or Anonymous user ticket or what is it.
The funny thing is that it stays there and also include the encoding in all links on the page. Until at recycle the application pool for the site... when it is gone..... and it just starts over again after a while....
Anyone to point me in the right direction. Site is ASP.NET 4, using form auth and deployed on a IIS7
Please help...
Best regards
Henrik
This could be related to a cookieless session which you might have configured. Look for the following in your web.config:
<sessionState cookieless="true" />
Also checkout if cookieless Forms Authentication is not enabled.
Related
I've been trying to resolve this question for a couple weeks now via Google and reading SO, and not had much luck, so I thought I'd finally try asking myself.
I'm setting up a very, very simple ASP.NET site on our intranet to generate some information for internal users. I'm using Windows authentication, rather than anonymous access, because based on what user hits the site I will be generating different information.
Long story short, this works perfectly in testing on my local Windows 7 machine where I developed the application. However, from the Windows 2008 R2 server where I want it to reside, when I hit the site I get a pop-up asking for my credentials, and even if I enter them it asks me for them again and again. This happens regardless if I'm hitting the site remotely or locally. If I try using anonymous access I can reach the site both ways but as I cannot identify the user I cannot generate the information I would like to provide.
Notes:
In IIS, I have Windows Authentication and ASP.NET Impersonation
enabled for the site. Everything else is disabled.
For the sake of figuring it out, I currently have the web.config set to allow all users and am not denying any.
The host/URL I'm using for it is toolName.organization.local
I was concerned that it was an issue of the 2008 R2 server admin user residing in a different domain then my remote user that I was testing with but again it does not work locally either.
In the AppHost file, I currently have windowsAuthentication enabled.
<windowsAuthentication enabled="true">
<providers>
<add value="Negotiate" />
<add value="NTLM" />
</providers>
</windowsAuthentication>
Admittedly, I typically use forms authentication on this server for all of our other internal sites so I'm a bit new to windows authentication and this issue. At this point I'm just not sure what to try or check next, so any advice would be helpful. Thanks.
I know this is a slightly old topic, but I had this exact same problem. Turns out I had the AppPool using Identity: ApplicationPoolIdentity instead of NetworkService. Once I switched that (under Advanced Settings in IIS7.5) I no longer got the server prompting for additional credentials and the pass-through worked perfectly.
Hope that helps!
First, you should realize that Windows passthrough authentication only works with Internet Explorer, and then only if the site is in the trusted sites, or intranet sites security group. Firefox, Chrome, etc.. will always prompt for credentials.
Having said that, you have a couple of issues.
You should have an <authentication mode="Windows" /> element in your web.config
You should decide if you want the app to run in the context of the user, in which case you would also need an <identity impersonate="true"/> tag. If not it should be false (although this is the default).
You do not need to have any authorization rules in your web.config if the site itself is completely guarded by windows authentication.
Just in case it's helpful, the problem for me was that I had left my application pool in Classic mode, in order to try to use NTFS permissions. I never got that to work, but once I switched it back to Integrated mode, I could use <allow> and <deny> tags to configure specific users' access.
Cookies in ASP.NET are causing me some problems.
For the most part, I want to use cookieless sessions. This is mainly to get around a problem where safari won't let me set the cookies from an iFrame. So that part all works fine. Cookieless sessions do the job.
However, I have a page which is called from a POST. It uses a post to pass in a hidden field from a form which then does some stuff....you don't really need to know what.
So it turns out that when cookieless sessions are on, the POST is disabled and only GETS can happen in ASP.NET web forms. This is breaking my functionality.
What I want to do is add a web.config to the folder that contains my POSTing pages to go back to normal cookie sessions so I can get my POSTs working again, but this doesn't work.
<?xml version="1.0"?>
<configuration>
<system.web>
<sessionState cookieless="false" />
</system.web>
</configuration>
Does anyone know a way of making a folder work with normal cookie sessions while the rest of the site works with cookieless sessions?
I've found a solution to this:
What I do is create an HTTP Handler (a .ashx file). This takes specific post values form Request.Form and tags them on as Querystring parameters. This then does a redirect to my original page which now looks for Querystring params instead of Form ones. Phew!
The HTTP handler is what my app posts to now - it was a Facebook Signed request.
So the good news is, that I can use HTTP Handlers now - you learn something every day.
I been struggling with an issue lately. My website which is using forms authentication is behaving pretty wierd suddenly. Once forms authentication is timing out, I can see I'm logged out of my application but for some reason, I'm not getting redirected to the login page. This was working absolutely fine before. Not sure what has happened to it suddenly. I'm using SQL Server to store session state and when I made my application to inProc, everything looks fine.
I even deleted and recreated my ASP.NET Session state database but no luck yet. When I look into Event viewer, I have many entries with the following message:
"Forms authentication failed for the request. Reason: The ticket supplied has expired."
On little search, someone said, this could happen with app pool recycling. I even deleted and recreated my app pool now. But still, I'm not getting redirected to login page.
Can someone help me out here.
Thank you.
For Forms Authentication to actually block access to pages, you need to tell your application under what circumstances to block access.
This will block all users who aren't logged in and cause a redirect back to your specified login page. Place it right after your <authentication> tag for simplicity.
<authorization>
<deny users="?" />
</authorization>
If you want to limit on more specific terms, you can add <location> elements with more detail. See this article for more information.
This is a follow on to a previous post about being unable to impersonate a currently logged in Windows user. There were many good suggestions, but the previous thread was getting messy, so I am resetting with this post. Hopefully with the current state documented below it will be obvious what the issue is. This is a well worn path, so I have to believe all I am missing is a little configuration step.
PROBLEM: I need to have ASP.NET impersonate the currently logged in user. When I run under IIS 7.5, it doesn't work. IIS Express works fine, but I believe that is because the debugging session is running under my user id.
I am using Environment.Username to determine who this user is. There was a suggestion that this property always returns the logged in user name, but from my testing it returns the impersonated user from IIS.
For example, if my web.config has…
<identity impersonate="true" />
When I run under IIS 7.5 with that setting, Environment.Username returns IUSR. I believe this is the IIS anonymous user account.
If I change web.config to…
<identity impersonate="true" userName="domain\jlivermore" password="mypassword" />
… then Environment.Username returns jlivemore. However, I need it to return jlivermore without me explicitly setting it in web.config.
Here are my IIS settings…
.NET Authorization Rules
Authentication
One question, if I disable Anonymous Authentication, then I am prompted to login to the site. I thought if you were logged in with an Active Directory account on a domain then this challenge wouldn't appear? Even if I enter my username/password into this prompt, I still don't get the impersonation to work.
Basic Settings
I'm not sure if you've found an answer, but if anyone is having problems with it you will need the following in your web.config file
<authentication mode="Windows"/>
<identity impersonate="true"/>
And in IIS you will need Asp.net Impersonation enabled as well as Windows Authentication enabled, the others should be disabled. And in Windows Authentication, go to Advanced Settings and UNCHECK the Enable Kernel-mode authentication. That should do it. Your site should now be set for Local Intranet apps and using any of the following will work
System.Security.Principal.WindowsIdentity.GetCurrent().Username()
HttpContext.Current.User.Identity.Name
System.Threading.Thread.CurrentPrincipal.Identity.Name
But using Environment.Username will only return the server name, hopefully this helps anyone struggling with this
I had a similar problem as you describe. The basic crux of the matter is that there is a difference between impersonation and delegation. My simple understanding of this is that impersonation will work when the client and server are on the same machine. If however, the client is on a different machine, you need delegation.
MSDN Reference
What is the difference between impersonation and delegation?
Impersonation flows the original
caller's identity to back-end
resources on the same computer.
Delegation flows the original caller's
identity to back-end resources on
computers other than the computer
running the service.
Related SO questions
Impersonation in ASP.NET MVC
Starting a console application from asp.net using authenticated user credentials
Have you tried using
HttpContext.Current.User.Identity.Name ?
We recently updated a site from Classic ASP to ASP.Net 3.5.
The old site used a login system based on cookies.
It would remember the users login information if a checkbox was selected when they first logged in. This would of course be done in a cookie.
We then upgraded the site Using ASP.net.
We transferred the old users to the built in ASP.net Membership Authentication.
It works great except for a really strange occurrence.
When a user logs in to the site, but had the old cookie for the site which stored the login information, the ASP.net Authentication seems to crash.
There is no error message, no information of any kind.
The user tries to login, gets no error message, just gets transfered back to the login page.
It seems to be looking at the old cookie and just doesn't know what to do.
The domain names of the old site and the new site are the same.
This does not occur for new users who have never been to the old site.
If an old site user clears out his cookies in his browser he can log in fine and the error never happens again.
But we have 5000 users, we can't tell all of them to clear out their cookies.
I tried changing the setting in the following line of code in my web.config.
<authentication mode="Forms">
<forms cookieless="UseCookies" loginUrl="~\User\Login.aspx" defaultUrl="~\Default.aspx" timeout="26280000" />
</authentication>
But I'm not sure if it helped or not.
Any assistance would be greatly appreciated.
Thanks
With forms authentication, your login is controlled by forms authentication cookie. So I don't understand how is your old cookie interfering with FAC?
In case you are storing some value in your custom cookie, one way would be change the name of the cookie in your new code. i.e. if the code is creating "CookieA", the same name as old application, change it to "CookieB" and same while reading.
Specify cookies token name:
<forms name=".ASPXFORMSAUTH" ... />