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.
Related
I have a password reset email going out to users which uses Request.ServerVariables("SERVER_NAME") to generate a URL for the password reset page. Problem is, the URL of the web application was changed recently, and the old name is still being reflected in the SERVER_NAME server variable. How can I reset this so the new, current server name is used? I'd rather not restart the web app in IIS if I don't have to. (I haven't actually stepped through the code; if I'm understanding this correctly, it will work just fine locally because IIS gets refreshed a lot more frequently on my PC than it does on a production web server.) Or am I misunderstanding how server variables work?
In essence from my reading around, your SERVER_NAME may be the name of the windows server itself and not necessarily the DNS name the rest of the world uses to reach that server. HTTP_HOST might be a better bet because it is the contents of the Host http header, which came from what the user typed into their address bar and subsequently what the user's browser passed in order to gain access to the site.
This is particularly helpful for sites that are multi homed, by which I mean one set of code runs eg two websites with different branding/styling, different bindings in IIS (different dns names) but the same underlying code, repeating back to the user what they typed into the browser means they always think they are interacting with the same site
We have a web application, say mysite.com.
Now users can come and create pages like, mysite.com/page/mypage. Here 'mypage' is unique identifier for the page he/she has created. So whenever mysite.com/page/mypage url is requested, it hits our 'pagerequestservlet', which gives out requested page data.
Now what I want is, whenever user hits, mypage.mysite.com, then also we give out the same page related info (that we give out on mysite.com/page/mypage). This would mean, I need to make all my *.mysite.com requests to be handled by 'pagerequestservlet' (or a similar servlet). Then I can just parse the request URL, identify the identifier 'mypage' and return the data.
Now my question is, how to make all my *.mysite.com requests to be handled by 'pagerequestservlet'? I am using GoDaddy as my domain registrar.
You must setup your DNS to allow such wildcards, I don't know wheter GoDaddy supports this.
A servlet is "DNS-agnostic", normally it does not need to know anything about its domain name. This way it's possible to deploy the same servlet on different environments or even with different context roots (example.com/a and example.com/b).
You still have access to the domain name via ServletRequest#getServerName(). You could implement a Filter that handles the subdomain part and redirect to the correct page. But be aware - if you run in a clustered environment or behind a load balancer, this would not return mypage.example.com, but the name of the host ther servlet was deployed to.
How to respect "Serve static content from a cookieless domain" page speed rule in IIS6?
To create a cookieless site (or subdomain, which is a very common best-practice) in IIS6/IIS7/IIS7.5 is simple : you need to tell the website that you are not to use cookies :) Which means in IIS terms, not to use a session.
This can be achieved in IIS6/IIS7 via two ways.
Modifying the Web.config file (my personal recommendation)
Using the IIS Manager GUI to find the setting and changing it.
IMPORTANT
Before you do any testing, you must must must clear all cookies (or all cookies for the domain u are testing) otherwise, they will get passed along even if u have done all the steps.
1. Via Config File
You need to define the session state to off.
<system.web>
<sessionState cookieName="What_ever" mode="Off" />
</system.web>
NOTE: Please note that the attribute cookieless (true|false) does NOT mean 'send cookies/do not sent cookies). That's for using sessions with/without cookies ... and passes some cookie guid into the url instead (if set to true).
2. Via Gui
Hope this Helps (i assume u know how to test that no cookies are working/not working...)
What this means is that your content needs to come from a domain that has no cookies attached to it. StackOverflow.com is an example of a site that does this. You will notice that all SO's static content comes from a domain called sstatic.net.
http://sstatic.net/stackoverflow/all.css
http://sstatic.net/js/master.js
This is so that the client and the server don't have to waste resources on actually parsing and handling cookie data. The good news is, you can use a sub-domain, assuming that you set your cookie path correctly.
Yahoo Best Practices for Speeding Up
Your Web Site
Use Cookie-free Domains for Components
When the browser makes a request for a
static image and sends cookies
together with the request, the server
doesn't have any use for those
cookies. So they only create network
traffic for no good reason. You should
make sure static components are
requested with cookie-free requests.
Create a subdomain and host all your
static components there. If your
domain is www.example.org, you can
host your static components on
static.example.org. However, if you've
already set cookies on the top-level
domain example.org as opposed to
www.example.org, then all the requests
to static.example.org will include
those cookies. In this case, you can
buy a whole new domain, host your
static components there, and keep this
domain cookie-free. Yahoo! uses
yimg.com, YouTube uses ytimg.com,
Amazon uses images-amazon.com and so
on.
Another benefit of hosting static
components on a cookie-free domain is
that some proxies might refuse to
cache the components that are
requested with cookies. On a related
note, if you wonder if you should use
example.org or www.example.org for
your home page, consider the cookie
impact. Omitting www leaves you no
choice but to write cookies to
*.example.org, so for performance reasons it's best to use the www
subdomain and write the cookies to
that subdomain.
create subdomain ( for example static.example.com ) and store all static content(images, css, js) here
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/
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.