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.
Related
I want to share session between two different domains .
How can I do this using cookie . I want to share user id across two domains.
For example.
First website : www.example.com In ASP.NET
Second website : www.newwebsite.com IN PHP
When user comes in first website , after login it will redirect to second website.
I want to get user id from first website cookie. How can I achieve this using cookie. My both website are on different platform and hosted on different server.
Code :
// Create cookie on First website :
HttpCookie cookie = new HttpCookie("example ");
cookie.Values.add("Username", "user1");
//Want to retrieve on Second website
HttpCookie LoginCookie = Request.Cookies.Get("example ");
string x = LoginCookie["Username"].ToString();
Thanks in Advance
Cookies are tied to individual sites/servers via (weak) encryption. What you will need to do is tell IIS that they are the same via the Machine Key inside your config. Arguably you could do this inside of IIS but then there is no source control.
Milan Mathew provided a decent start for you here (http://www.codeproject.com/Tips/438319/Sharing-Authentication-Cookie-between-two-ASP-NET). Basically in both sites you apply the same encryption information.
<machineKey
decryptionKey="A225194E99BCCB0F6B92BC9D82F12C2907BD07CF069BC8B4"
validationKey="6FA5B7DB89076816248243B8FD7336CCA360DAF8" />
Keep in mind that depending on which version of IIS and .NET you are running will dictate how you set this up and which configs you apply this two. There have been recent modifications to how this is done.
Please provide more information for a more details on your setup for more specific assistance.
Any case, base your search criteria on this concept and you should be fine.
the HTTP protocol says, two different sites can share a cookie if and only if both sites are deployed under the same domain (or, sub-domain). Internally, your browser stores the cookies locally (either in disk or in memory) against the web site's URL. When you hit subsequent requests to any site, the browser reads those cookies which have matching domain or sub domain names comparing to the currently requested URL and sends those cookies with the request.
With JavaScript/HTML5's "LocalStorage" feature, if you're on myDomain.com:81 and you set a value in local storage, but then redirect to myDomain.com, the local storage will be different, and the value will be lost.
How can I store a simple value that exists across all domains in my browser?
If it makes a difference, this is for a Chrome extension.
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.
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 :)
Is there a way to access referrer information from the server log in a ASP.NET web application?
I would like to know if a customer comes to my web app from a specific site and change the app's behavior accordingly. I could have the webmaster of the other site include a query string, but to my knowledge this wouldn't work because as soon as Tom, Dick or Harry posted the link somewhere else, the query string would be unreliable.
Is there a sure fire way for a web app to know where the user came from?
Why not just check the Request.UrlReferer property and change the behavior if the referer is not any page on your site?
This would be a lot simpler than referencing IIS logs.
You can access the referrer information through the HttpRequest.UrlReferer object.
However you should note:
This can null - so check for null before calling AbsoluteUri on it.
This can be changed fairly easily, so you can't rely on it completely
Why would you not just access the Request host header for the HTTP_REFERER instead of the log file? See here, but note that you are never guaranteed to recieve this information, nor is it reliable if you do.
Request.UrlReferrer.AbsoluteUri
gives you the same as the server logs will. Probably a combo of querystring variable and UrlReferrer will do the best job of ensuring that it came from the right source.
UrlReferrer is sent by the client, and it's not guaranteed to be there.
Are you using a shared environment? Normally they will supply this if you request the logs (normally an option in Plesk or similar). The log directory will probably be one or two folders up from the root http folder, so it may not be accessible using the IIS user.
On a dedicated server then you can obviously configure this manually.
While I realise that this is usually related to cross site scripting attacks, what I'm wondering is how can a session remain valid throughout multiple subdomains belonging to a single domain (example: a user logging in only once, and being able to access both subdomain1.domain.com and subdomain2.domain.com with the same session). I guess I first need to understand how it works, but so far I haven't been able to find much that would be of any relevance.
But then again, maybe I wasn't asking the right question.
Thanks in advance :)
Inproc sessions cannot remain valid, however you can code your web application to allow cookies across multiple subdomains. You will need to set the domain equal to:
Response.Cookies("CookieName").Domain = ".mydomain.com"
Remember the period.
There are quite a few ways to share session data or cookie data across domains. The simplest is to share it on the server side through a shared data store. But you would not be asking this question if it were that easy.
The other way to do this is equally simple. The domain one.com contains some session data say name=aleem and id=123 and wishes to pass this along to two.com. It will follow these steps:
Make a call to two.com/api/?name=aleem&id=123
When two.com gets the data via query parameters, it creates a cookie with the data. This cookie will be stored under the two.com domain.
two.com will then redirect back to the REFERER which in this case happens to be one.com
This is a simplified scenario. The domain two.com needs to be able to trust one.com and not only that but it needs to know that the request is authentic and not just crafted by the user so you need to use public/private keys to mitigate this.
By default, all cookies for a site are stored together on the client, and all cookies are sent to the server with any request to that site. In other words, every page in a site gets all of the cookies for that site. However, you can set the scope of cookies in two ways:
Limit the scope of cookies to a folder on the server, which allows you to limit cookies to an application on the site.
Set scope to a domain, which allows you to specify which subdomains in a domain can access a cookie.
You can learn more here.
The comments about the cookie being set for the domain to allow subdomains to receive that cookie give you that side but what's missing is the consistency of session.
I think this is very much like the problem of maintaining state across servers in a farm and the solution is probably to ensure that your session store is consistent across both sites (if they are not server from the same 'web site' in IIS). You can move the Session store into SQL Server (HOW TO: Configure SQL Server to Store ASP.NET Session State) which would probably serve the purpose as each site would query the same store when looking for the session data related to the cookie they've been presented with.
I hope that gets you on the right track.
If you have the ability to set up a common subdomain, you can do this:
In your subdomain html files, include a javascript file at the top like this:
<script src="http: //common.domain.com/check.asp"></script>
In check.asp, look for your logged_in cookie and if not present, show a page say, http://common.domain.com/login.asp using something like
<%
if (cookie_not_found){
%>
location.href = "http: //common.domain.com/login.asp";
<%
}
%>
Once a person submits username password, submit it back to the same login.asp and set the session cookie, (which will be set in common.domain.com domain) and then redirect to http://subdomain1.domain.com.
What will happen now is, a call will be made to the embedded "common.domain.com/check.asp", and cookies for common.domain.com will be sent by the browser along with the request. So you will know whether your session is valid or not, even when you are in subdomain1.domain.com.
You can set a cookie for a specific domain.
In php, the setCookie() method contains a parameter in which you can specify the top-level domain, so the cookie is valid for all subdomains. Based on your tags, I see you are working in asp.net. Probably this also exists for asp...
after a little search for asp:
try this:
Response.Cookies("CookieName").Domain = ".mydomain.com"
or read this
Here is a solution which works:
http://anantgarg.com/2010/02/18/cross-domain-cookies-in-safari/