Forms authentication failing when using SQL Server session state - asp.net

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.

Related

ASP Authentication set to None and still prompting for login

Firstly I just want to say I'm not an ASP developer, I'm PHP through n through...
So my problem is this, all of a sudden a client site has started prompting for users to be logged in when viewing pages in a sub directory, when I download the web.config file I can see the authentication mode set to "Windows" this would appear to be an issue but it was working up until now, so I set it to None and uploaded the file (there isn't a web.config in the sub directory, just the site root) and it continues to prompt me for the login.
Is there something I need to do to "refresh" the server or something? I've looked through the hosting control panel and can't find anything about anonymous access or restarting the server, its on a shared hosting account and the control panel is pretty below average
Any help is greatly appreciated!! I'm in a panic and the hosting company don't have ASP support on hand
Thanks,
Mark
In the folder that you want anonymous access, just use the web.config authorization section to allow anonymous users:
<configuration>
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</configuration>
The * essentially means Everyone so it just saying that for the current directory, everyone is allowed access- you only need this in the web.config...nothing more.
If you are still receiving prompts after this, then the folder itself must have permissions at the operating centre level (NTFS permissions) which do not allow Anonymous access...Although you say the ASP support isn't at hand, I presume you can raise help tickets with them to enable this access?
Edit
I should add that this setting of authorization is different to setting an Authentication scheme (Windows Authentication, Forms Authentication etc). For example, you might have Forms Authentication for your website but specifically want anonymous access to a folder (like this case) so setting your authentication option isn't actually relevant.

ASP.NET forms authentication encoded in URL

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.

How can I secure an ASP .NET website that already uses Forms authentication?

I've got an ASP .NET website which uses Forms authentication to secure certain parts of the site. We have a test version of the site on a server and are making it available to partners over the web, e.g. at test.mydomain.com.
I need to secure all parts of the site so that only our partners can use it. Ideally it would be nice to have basic authentication pop up when they first hit the site, then have it work as normal thereafter, i.e. forms auth for certain areas.
However it seems ASP .NET and IIS don't support this. I'm aware of MADAM but that achieves something slightly different to what I need.
I'm considering restricting access by IP but that has two drawbacks, one it requires parters to "sign up" with their IP, and two, their IP could change.
Does anyone else have any suggestions?
One solution is to check for the existence of a 'basic authentication' cookie on each request. If it doesn't exist or doesn't have valid data, don't allow access to the site. This could be checked in a base page that all pages inherit from or masterpage etc.
In order to set the cookie, you could create page that you send your partners to. It might just be at a obscure url, or require that they enter a password. Basically what ever security mechanism suits you, but once they 'pass the test', you set the cookie that gives them access to the site.
Then they would have access and be able to login using your existing forms authentication.
Does that make sense.
Assuming your site implements roles, you can block access using traditional forms authentication and the location attributes. Something like:
<configuration>
<location path="Testing">
<system.web>
<authorization>
<allow roles="partners" />
<deny users="*" />
</authorization>
</system.web>
</location>
</configuration>
You would then need to make sure all of the users that need access to that part of the site were in the partners role.
Ummm....
Well, the above solutions will work, but overall there is a better way. But does require some planning ahead.
your development and staging servers shouldn't be open to the general public, search bots, ect.. ect..
your dev and stg boxes can be locked down buy firewall or even ip access controls via IIS
No code solution
In the end we decided that securing the entire site via Forms authentication, and issuing test accounts to our partners, was the best solution.
Thanks to all for your suggestions.

ASP.NET Membership user login error cookie problems

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" ... />

ASP.NET website requires login after each compile

I am working on two ASP.NET websites. Both use custom authentication process based on forms authentication with:
<authentication mode="Forms">
<forms cookieless="UseCookies"/>
</authentication>
set in Web.config.
When I compile the first website, it always remembers my credentials I've entered before, like expected.
When I compile the second website, each time it forgets completely all credentials I've entered a minute before, and .ASPXAUTH cookie is not here nevermore.
What can cause the second website to do so? Where to start to search for the resolution of this problem?
Perhaps when the 2nd site recompiles some class or other object changes that is stored in the session so the application has to restart the session, but in the first site the only thing being stored in the session are standard .net objects that havn't been recompiled. Is this causing a real world problem, it is fairly usual to lose your session state when you recompile a website, but this does not cause any problems i the wild unless you are updating your live code several times a day and kicking users of the system.

Resources