My main Site (hostsite) has an IFRAME with a registration site (regsite) hosted on a different domain.
I want to host the registration on a different domain, because I feel storing the DB login information on hostsite is not safe as many people have access to the backend.
All browsers accept the login session-cookie coming from regsite - Internet Explorer 8 does not. The only way to make IE accept this cookie is by adding both sites to "Trusted Sites" which is not what i want.
Is there any way I can work around the cross-domain issue besides a local browser setting or is my only option to move the registration to hostsite (curl is not an option as it's not static HTML I'm displaying on the registration site, but PHP files)?
I think this can be solved without moving anything, and little programming. Just with some DNS rules.
For example, you can create a new subdomain called register.hostsite(.com) pointing to the ip where regsite is.
Then re-direct the IFRAME to that new subdomain.
It will get the same bits from the same server, but now it will be inside hostsite's domain.
That should (at least in theory) be enough to satisfy IE. I'm not 100% sure though, I haven't used IFRAMES in a long time.
If that doesn't work, I'd suggest asking on serverfault, too.
EDIT: I was looking for another issue and found this 'micro-proxy' PHP implementation by yahoo. It's their recommended way of resolving this kind of issues:
http://developer.yahoo.com/javascript/samples/proxy/php_proxy_simple.txt
The problem with the iframe and IE is that IE considers the iframe's content as 3'rd party (as in advertisements etc).
To have IE actually store the cookies set by this domain document you need to have the other domain emit an P3P-header stating its intentions. This is easy to do and requires only a single http-header to be added.
I'm, not sure what you mean by cross domain issues though as there are none - you simply have two different documents from two different domains. You have not stated whether you are trying to have one domain set cookies for the other, or one page access the other.
Related
I'm building a PHP Web Application for Company A in which users can login and manage certain items in their inventory. I want to host this application myself for reasons such as maintenance, to make sure the servers meet expected performance standards and because Company B or C might also want the same service.
What Company A (B and C also) wants is to have this application be accesible from their a subpage on their domain. I've gone through possibilities of URL rewriting and linking, but i've decided to use iframes to display the application on their website.
I've used iframes before, but never when dealing with private data, so i'm not very familiar with the security risks attached to using iframes. A lot of the examples i found after googling were risks attached to hackers adding iframes with their own destination to existing code, as opposed to harmfully use an existing one. What should I look out for and try to prevent from happening?
In case im completely off with this, what other method could i use instead of iframes? Given the above-mentioned requirements of course.
To start, your best solution is probably to use a subdomain pointing to your server hosting the app. So Company A can have their regular web site on companya.com but have the application on app.companya.com.
Regarding frames, I don't think in your situation there are any security "risks" to worry about. The iframe will belong to you and you control it. Javascript's Same Origin Policy prevents frames on different domains (and subdomains unless document.domain is set) from accessing each other. So the iframe won't be able to access the parent and vice-versa.
However I'm assuming the application is free standing and doesn't rely on anything from the parent site. In which case, everything would happen in the frame and there's no need for the frames to communicate in any way.
The disadvantage of frames of course is that the apparent URL and page title will remain the same when you load new pages in the iframe, which is bad usability (and bad for SEO, if that is a concern).
Im interesting in how bookmarks work for social networks sites like facebook for example, when you look at someone's profile its
www.facebook.com/customname
or if they didnt make one yet its
www.facebook.com/generatedname
Is there a get request somewhere im missing??? Is the
www.facebook.com/profile.php?key=
hidden in the url? But how does the server know to interpret the url to look for someone's profile page? How does it work!!!!! Thanks!
Yes, the request is usually hidden using rewrite engines such as mod_rewrite.
As such something like facebook.com/customname is rewritten to facebook.com/profile.php?key=customname, which then internally looks up the correct profile page from the database.
There is some solution called mod_rewrite, which actually translates the URL visited by the user (and visible to the user) into the path of the script (along with all the parameters).
Example: when you visit eg. http://www.facebook.com/ben, server may actually translate it into www.facebook.com/profile.php?name=ben without you noticing it (because it happens on the server side).
That is how it is done.
But there is still another, loosely related solution that happens on the client side (within the user's browser, not on the server). This solution is called pushState and it is HTML5's feature (HTML5 is new standard, supporting application-like behaviours in modern browsers).
Just look at this demonstration (it allows you to change URL, go back and forth, but if you type the visited URL directly you will show that there is nothing on the server). To make similar thing, you will need to learn JavaScript (language of the scripts executed on browser's side).
Alternatively to pushState some pages (like Twitter and - afair - Facebook) use solutions based on location hash (the part of the URL after #), which lets them maintain compatibility with some deprecated browsers, like IE7 etc.
Maybe this is far too much to answer your question, but you now should be pretty informed about how the URL visible to the user may differ from what is really invoked.
If you have any additional questions, let me know.
They probably use .htaccess or a similar mechanism to redirect all requests to a single entry file. That file starts processing the request and can also check to see if there is an account for customname that was specified on the url.
I am currently researching the best way to share the same session across two domains (for a shared shopping cart / shared account feature). I have decided on two of three different approaches:
Every 15 minutes, send a one time only token (made from a secret and user IP/user agent) to "sync the sessions" using:
img src tag
img src="http://domain-two.com/sessionSync.png?token="urlsafebase64_hash"
displays an empty 1x1 pixel image and starts a remote session session with the same session ID on the remote server. The png is actually a PHP script with some mod_rewrite action.
Drawbacks: what if images are disabled?
a succession of 302 redirect headers (almost same as above, just sending token using 302's instead:
redirect to domain-2.com/sessionSync.php?token="urlsafebase64_hash"
then from domain-2.com/sessionSync, set(or refresh) the session and redirect back to domain-1.com to continue original request.
QuestionL What does Google think about this in terms of SEO/Pagerank?? Will their bots have issues crawling my site properly? Will they think I am trying to trick the user?
Drawbacks: 3 requests before a user gets a page load, which is slower than the IMG technique.
Advantages: Almost always works?
use jsonp to do the same as above.
Drawbacks: won't work if javascript is disabled. I am avoiding this option because of particularly this.
Advantages: callback function on success may be useful (but not really in this situation)
My questions are:
What will google think of using 302's as stated in example 2 above? Will they punish me?
What do you think the best way is?
Are there any security considerations introduced by any of these methods?
Am I not realizing something else that might cause problems?
Thanks for all the help in advance!
Just some ideas:
You could use the jsonP approach and use the <noscript> tag to set the 302-chains mode.
You won't find a lot of js disabled clients in the human part of your web clients.
But the web crawlers will mostly fall in the 302-chain mode, and if you care about them you could maybe implement some user-agent checks in sessionSync to give them specific instructions. For example give them a 301 permanent redirect. Your session synchronistation needs are maybe not valid for web crawlers, maybe you can redirect them permanently (so only the first time) without handling any specific session synchronisation for them. Well it depends ofg your implementation of this 302-chains but you could as well set something in the crawlers session to let them crawl domain-1 without any check on domain-2, as this depends on the url you generate on the page, and that you could have something in the session to prevent the domain-2 redirect on url generation.
I have seen a few answers to this on SOF but most of these are concerned with the use of subdomains, of which none have worked for me. The common one being that the use of session.cookie_domain, which from my understanding will only work with subdomains.
I am interested in a solution that deals with deals with entirely different domains (and includes the possibility of subdomains). Unfortunately project deadlines being what they are, time is not on my side, so I turn to SOF's expertise and experience.
The current project brief is to be able to log into one site which currently only stores the user_id in the session and then be able to retrieve this value while on a different domain within the same server enviroment. Session data is being stored/retrieved from a database where the session id is the primary key.
I am hoping to find a "light wieght" and "easy" to implement solution.
The system is utlising an in-house Model View Controller design pattern, so all requests (including different domains) are run through a single bootstrap script. Using the domain name as a variable, this determines what context to display to the user.
One option that did look like to have potential is the use of a hidden image and using the alt tag to set the user id. My first impressions suggest this immediately seems "too easy" (if possible) and riddled with security flaws. Disscuss?
Another option which I considered is using the IP and User Agent for authentication but again I feel this not going to be a reliable option due to shared networks and changing IP addresses.
My third option (and preferred) which I considered and as yet not seen discussed is using htaccess to fool the user into thinking that they are on a different domain when infact apache is redirecting; something like
www.foo.com/index.php?domain=bar.com&controller=news/categoires/1
but displays to the user as
www.bar.com/news/categories/1
foo.com represents the "main site domain" which all requests are run through and bar.com is what the user thinks they are accessing. The controller request dictates the page and view being requested. Is this possible?
Are there other options? Pros/Cons?
Thanks in advance!!!
Have you thought about using session_set_save_handler. You can store your sessions in a database and access them from any domain.
Define a main session server (I do this in combination with memcached)
use Ajax / JSON(P) to request a session from this server, this allows you to share sessions over multiple domains
Reuse this session
For the benefit for anyone else interested in this functionality, there is no simple answer I am afraid. Google "Single Sign On" and it will come back with the technology and some solutions avialable.
As for using htaccess to hide the domain name, this is not possible as it could be used for malicious activities.
I have now successfully implemented a system to achive my requirements.
I need to share SSO information between two different domains with a cookie, can this be done in PHP and how?
On both domains, place an image or other web element that is pulled from the other domain. Use the URL to notify the other domain that user X is on domain A, and let domain B associate that user ID with that user on their system.
It's a little complex to carry out correctly, but if you think it through it'll work out very well.
Vinko points out in a comment (thanks!) that I shouldn't take it for granted that you understand the security risks involved. If this information is of any value to anyone, then you should make sure you use proper encryption, authentication, etc to avoid releasing sensitive information and to avoid various attacks (replay, man in the middle, etc). This shouldn't be too onerous since you control both websites and you can select a secure secret key for both, since the communication is only going between the two servers via this special URL. Keep it in mind though.
-Adam
You don't, cookies are bound to a domain. There are restrictions on this and it's referred to as cross site scripting.
Now, for some help to your problem.
What you can do is create a script that helps bridge them.
You can globally rewrite all links to your second site are going to need cookie information from the first site.
You would save all the cookies from site-a to a database that they both can read, then programatically appending the cookie-id querystring on all of the links to site-b, then you lookup that cookie id and re-set the cookies under the new domain.
There is a really good PHP database abstraction library (PHP ADODB) and it has a session sharing plugin that makes all of this a whole lot easier.
I'm not sure about the security implications, but there is an Apache setting that allows you to change the domain of a cookie.
# in httpd.conf (or equivalent)
php_value session.cookie_domain mydomain.com
I have successfuly employed this method for subdomains, but have never attempted for different domains.
There is also a method to set the variables direction in PHP described at http://us.php.net/manual/en/function.session-set-cookie-params.php. The documentation makes no reference to the ability or inability to set cookies on a different domain.
There is a different Stack Overflow thread on this same topic, but I don't think it was ever sufficiently answered.
Well, if your domains are just different subdomains you could do it in an easy way by creating a .yourdomain.com cookie. Then the cookie is passed along with all the requests across all the subdomains.
It's not that simple if you want to share cookies between different domains as browsers treat it as a security risk.
What is the exact example?
In case of some software like Google Analytics and other tracking images, etc. you might be forced to use P3P headers to let browser know you don't care about security when sending your cookies. Then a browser requesting image gets a cookie as part of the response and also inspects P3P. If all is OK it saves the cookie on the hard drive and the next time you request an image that sits on your website (but is part of other domains page) the browser will send the cookie along. But I guess this does not help ;-)
I have never used a cookie value across domains in a direct meaning of it.
If you have two sites using the same domain and would like to share cookies between them, set something like this in your settings.php file for each domain:
ini_set('session.cookie_domain', '.EXAMPLE.com');
Be sure you include the leading '.' before the domain name, or it won't work.
This allows users to maintain login status between any sites configured for domain-wide cookies.
This can also have negative side effects, so don't do this unless you're familiar with all the cookies involved for the sites you want to share cookies between.