Have a portal which uses forms authentication
LoginUrl=Login.aspx DefaultUrl=Default.aspx
User credentials are in db... So during login, we get all the user credentials - so we reach db, user authenticated (Fidler shows http 302 for default.aspx), redirect to deault.aspx and back to login page again as we don't authenticated but we do IT!!!
have 4 machines on the project - 3 works ok - mine - not! Compare all the data - I have the same web config, iis setting etc
what it could be?
Thanks
If you have a web farm you need to ensure that all servers in the farm share the same machineKey because if you have autogenerated and different machine keys the authentication ticket might not be properly decrypted.
Did you set a domain on the forms element in the web.config file? If so, the request url must be within the domain or forms authentication just wont work. Localhost won't work either.
If you're testing on a development system you may want to add a fully qualified domain name to the hosts file ( [SystemDrive]:\Windows\System32\Drivers\Etc\hosts ).
so, I fixed the problem... the reason - my inattention...
so, I use fiddler again to analyze my requests/responses... so,
1) go to Default
2)redirect to Login and input login-password
3)the user found in db - FormAuthentication ticket created
4)redirect to Default
5) User became non-authenticated and move back to login page....
so Fiddler shows that on step 3 cookies created and debug shows that the user authenticated. But no cookie passed to Dfeault page.
I found that cookies from Login page has "secure" mark. It means that I have requireSSL=true property in webconfig... but requireSSL has value false on default... so, something overwrites it... I found one more config file in folder of top level with requireSSL=true... when I remove top-level config file - everything start work fine...
surely standard situation to miss someting... but such interesting effect I see first time - to do authentication and its break during redirect to default page - may be it helps somebody to save his/her time in further...
but anyway - thanks the people answer me for the problem :)
Related
we have an odd situation where a user logs into the site (Asp.Net), and upon logging out, it only directs us to the main page "https://newsite/default.aspx" however if we replace default with login, we are immediately logged back in. This happens only when we go through the public IP with associated DNS A record located on the F5. If we open the site on the IIS server via IP binding "https://ipaddress/default", I can login and logout and stay logged out, it works as expected. I have worked with F5 support and have tried multiple different configuration changes, and no dice, same behavior everytime. The newsite is set up identically in F5 to our current production site, and developers say the logout code is identical to current production so we are confused as to why this is happening. Persistence is set on the load balancer as well. Any help in the right direction would awesome.
A couple things I would suggest checking:
If you monitor the traffic with something like Fiddler and compare the results of login/logout with the F5 and without, do you see any difference? I would look for specific things like cookies being set or removed. I know ASP.NET uses specific cookies for sessions, so I would wonder if that cookie is not getting deleted properly on logout.
Once you log out of the site (when going through the F5), if you refresh the page, do you stay logged in (in this case, I could see where some kind of caching may send back the page even though you're logged out. If this is the case, you could have an F5 admin check to see if there's a Web Acceleration profile on the virtual server and remove it to see if that helps.
Looks like specific security cookie code was causing the issue of creating a duplicate cookie within ektron.
Following code was removed, and now log out is working properly via SSL through our F5.
Code removed:
Dim lSec As SecurityAPI.Cookie = New SecurityAPI.Cookie(Me, mServerEnvironment, mCOGUser.PeopleID)
lSec.SetCookie()
I am having a problem implementing Microsoft's latest Identity 2.0 in my ASP.net 4.5 Web Forms project. This is my scenario...
I have downloaded the latest Webforms.Samples code from https://aspnet.codeplex.com/SourceControl/latest and pretty much performed a straight port (for the purposes of testing) into my project.
In development, the code/implementation works correctly, when we move to our IIS 7.5 staging server, after a period of time (usually 3 or 4 hours, but varies) the test users experience the following problem...
When they login, the login process appears to run correctly and redirects them back to the specified return url, but the authorisation is not complete/recognised and they get immediately returned back to the login page.
I should say that the login page/process doesn't fail (no errors) and the underlying code return 'success' (as this is the only path that will invoke the redirect), but the actual mechanism appears to be passive. To prove this, I have created a test page that simply echoes the user's identity and even immediately after an apparently successful login, the user identity is anonymous.
The only way I have found of fixing the issue is to restart the web application and again it runs fun for a while.
Can anyone give me any pointers on where I can look to begin to debug this issue or what the cause might be?
Thanks.
ASP.NET_SessionId + OWIN Cookies do not send to browser This page seems to provide a workaround to the issue by creating a session on application start up.
Starting with this great analysis by #TomasDolezal, I had a look at both the Owin and the System.Web source.
The problem is that System.Web has its own master source of cookie information and that isn't the Set-Cookie header. Owin only knows about the Set-Cookie header. A workaround is to make sure that any cookies set by Owin are also set in the HttpContext.Current.Response.Cookies collection.
The workaround I created is now outdated: I've made a small middleware
(source, nuget) that does exactly that, which is intended to be placed immediately above the cookie middleware registration.
Use Microsoft's suggestion of a SystemWebCookieManager instead.
We've recently run into an issue with our ASP.NET application where if a user goes to ourcompany.com instead of www.ourcompany.com, they will sometimes end up on a page that does not load data from the database. The issue seems to be related to our SSL certificate, but I've been tasked to investigate a way on the code side to fix this.
Here's the specific use case:
There is a user registration page that new users get sent to after they "quick register" (enter name, email, phone). With "www" in the URL (e.g. "www.ourcompany.com") it works fine, they can proceed as normal. However, if they browsed to just "ourcompany.com" or had that bookmarked, when they go to that page some data is not loaded (specifically a list of states from the DB) and, worse, if they try to submit the page they are kicked out entirely and sent back to the home page.
I will go in more detail if necessary but my question is simply if there is an application setting I can say to keep the session for the app regardless of if the URL has the "www" or not? Buying a second SSL cert isn't an option at this point unless there is no recourse, and I have to look at a way to solve this without another SSL.
Any ideas to point me in the right direction?
When your users go to www.ourcompany.com they get a session cookie for the www subdomain. By default, cookies are not shared across subdomains, which is why users going to ourcompany.com do not have access to their sessions.
There is a useful thread discussing this issue here. The suggested solution is:
By the way, I implemented a fairly good fix/hack today. Put this code
on every page: Response.Cookies["ASP.NET_SessionId"].Value =
Session.SessionID; Response.Cookies["ASP.NET_SessionId"].Domain =
".mydomain.com";
Those two lines of code rewrite the Session cookie so it's now
accessible across sub-domains.
Doug, 23 Aug 2005
Surely you are trying to solve the wrong problem?
Is it possible for you to just implement URL rewriting and make it consistent?
So for example, http://example.com redirects to http://www.example.com ?
For an example of managing rewriting see:
http://paulstack.co.uk/blog/post/iis-rewrite-tool-the-pain-of-a-simple-rule-change.aspx
From the browsers point of view, www.mysite.com is a different site than mysite.com.
If you have a rewrite engine, add a rule to send all requests to www that don't already have it.
Or (this is what I did) add a separate IIS site with the "mysite.com" host header and set the IIS flag to redirect all traffic to www.
In either of these cases, any time a browser requests a page without the www prefix, it will receive a redirect response sending it to the correct page.
Here's the redirect site home directory properties:
And the relevant host header setting:
This fixes the issue without requiring code changes, and incidentally prevents duplicate search results from Google etc.
Just an update, I was able to fix the problem with a web.config entry:
<httpCookies domain=".mycompany.com" />
After adding that, the problem went away.
I have a web app that is being hit by facebook. The login page retrieves the keys that I need and sets some session variables. When the server then redirects the user to the next page, the session information is lost. I’m running the IIS engine on vista ultimate at the moment, the app pools don’t matter because I’m using a state service and I’m still losing the session state. I’ve tried both the overloaded method of the response.redirect function and also adding a header to the page to force the redirect and none of this seems to work. Does anyone have any ideas of what I’m missing?
I’ve tried both of these:
Response.Headers.Add("refresh", "3;url=Dashboard.aspx")
And
Response.Redirect("Dashboard.aspx", False)
[EDIT]
So i just did a little experiment and well it turns out that when I hit the url directly from the facebook page I get the problem, but when i copy the url for the IFrame into a new browser window and try it it works fine.
[EDIT]
So I found an article on this and after addin gthe header the problem was solved (for now)
http://support.microsoft.com/kb/323752
Response.AddHeader("P3P: CP", "CAO PSA OUR")
when I hit the url directly from the facebook page I get the problem, but when i copy the url for the IFrame into a new browser window and try it it works fine.
If you're in an iframe, any cookies you set are “third-party cookies”. Third-party cookies may be subject to more stringent conditions than the normal “first-party” cookies you are setting when the user is directly on your site. This can be due to different browser default cookie handling or because the user has deliberately configured it like that. (And for good reason: many third-parties are unpleasant privacy-invading advertisers.)
In particular, in IE6+ with the default settings, you cannot set a third-party cookie unless you write a P3P policy promising that you will be a good boy and not flog your users' data to the nearest identify thief.
(In practice of course P3P is a dead loss, since there's nothing stopping the site owner from just lying. Another worthless complication that provides no actual security. Yay.)
I'd try running Fiddler and see if your session cookie is being sent properly with the response when interacting with your app via Facebook.
The session depends also on cookie support by the client. When you say the app "is being hit by facebook" are you sure that by what ever means they are "hitting" you they are supporting cookies?
Response.Redirect and refresh don't carry session. Server.Transfer() can but loses the ability to transfer to other servers/sites.
I implemented OpenID support for an ASP.Net 2.0 web application and everything seems to be working fine on my local machine.
I am using DotNetOpenId library. Before I redirect to the third party website I store the orginal OpenID in the session to use when the user is authenticated (standard practice I believe).
However I have a habit of not typing www when entering a URL into the address bar. When I was testing the login on the live server I was getting problems where the session was cleared. My return url was hard coded as www.mysite.com.
Is it possible that switching from mysite.com to www.mysite.com caused the session to switch?
Another issue is that www.mysite.com is not under the realm of mysite.com.
What is the standard solution to these problems. Should the website automatically redirect to www.mysite.com? I could just make my link to the log in page an absolute url with containing www? Or are these just hiding another problem?
Solve the realm problem that you mentioned is easy. Just set the realm to *.mysite.com instead of just mysite.com. If you're using one of the ASP.NET controls included in the library, you just set a property on the control to set the realm. If you're doing it programmatically, you set the property on the IAuthenticationRequest object before calling RedirectToProvider().
As far as the session/cookie problem goes with hopping between the www and non-www host name, you have two options:
Rather than storing the original identifier in the session, which is a bad idea anyway for a few reasons, use the IAuthenticationRequest.AddCallbackArguments(name, value) method to store the user's entered data and then use IAuthenticationResponse.GetCallbackArgument(name) to recall the data when the user has authenticated.
Forget it. There's a reason the dotnetopenid library doesn't automatically store this information for you. Directed identity is just one scenario: If the user types 'yahoo.com', you probably don't want to say to them 'Welcome, yahoo.com!' but rather 'Welcome, id.yahoo.com/andrewarnott'! The only way you're going to get the right behavior consistently is to use the IAuthenticationResponse.FriendlyIdentifierForDisplay property to decide what to display to the user as his logged in identifier. It gives more accurate information, and is easier than storing a value in the callback and getting it back. :)
I dunno how OpenID works, but LiveID gives you a token based on the combination of user and domain. I just would have forwarded www to mysite.com.
The cookies and sessions and everything else get lost between www.site.com and site.com. I don't have patience enough to thoroughly read all the specs, but http://www.w3.org/Protocols/rfc2109/rfc2109 states that
A is a FQDN string and has the form
NB, where N is a non-empty name
string, B has the form .B', and B' is
a FQDN string. (So, x.y.com
domain-matches .y.com but not y.com.)
Note that domain-match is not a
commutative operation: a.b.c.com
domain-matches .c.com, but not the
reverse.
I think that means yes, you do need to forward to www. I have always added domain correction code to my sites when cookies and sessions are being used.