I have a number of different domains where I would like users to be able to select a photo, however I want to photos uploaded/stored on one central separated domain.
Is there a more advisable way to do this?
I've considered using an iframe from the other domain (so they are interacting with the required domain) but haven't tried it yet.
I have also read that curl can potentially do this.
Any other ideas/problems/concerns...
All advise appreciated.
thx
There are a couple ways you can handle this. Here are the scenarios I see.
Scenario A:
All domains are on the same server. With this setup you can actually help your server security by storing the images and other files in a directory that is not accessible by Apache. Then you use PHP to serve the file to the end user through virtual links. Drupal does this with its private file system.
If the users are able to upload images from the other domains then just have all of the domains write the images to the same directory, but then always return the "central" domain's URL for retrieving them.
Scenario B:
The domains exist across two or more servers. With this setup what you really need to do is setup an API where the other domains communicate behind the scenes to send the photo to the core repository domain. This domain saves it and returns a URL for accessing it.
In either case you should really look up CDN technology. Its basically what your trying to accomplish plus a lot more. I would also recommend that in either scenario that you always use the path on the central domain for all the images instead of returning them back through the current domain.
No reason to get iframes or curl involved. Assuming that all these domains are on the same server (or same cluster of servers), there is nothing which requires that a file uploaded using a file on one domain must only be served from that domain. An upload form can do whatever it wants with the uploaded file, including storing it in a location where it'll be available from your central domain.
Related
I have seen a lot of solutions that involve using .htaccess. I would like to know a way to create sub domains using only PHP. For my purposes, this also needs to work using non-host-specific mechanics so it would work on most hosts.
All I know is that I would need a wildcard CNAME record that says all sub domains point to x.x.x.x, but I don’t know what to do from here. What I think you need to do is create a folder that contains the code for the sub domains, and I have done this, but I cannot find a cross-host way to link the sub domain with the folder. There has to be a way to do this as I have seen it done, but I can not find a way that meets my needs.
The problem here is that PHP doesn't handle the request coming in, a web server (e.g. Apache or Nginx) does and it's the config for that software that determines where a request goes. Now the good news is that you can have wildcards in your config (at least for Apache and Nginx, YMMV if you're not using one of those), as long as you can access the config file (you'll need root access on the server). There is plenty of information available out there depending on what web server you are using so you can google that part.
Now, assuming you've done that part, in PHP you just need to check what the root domain for the request is. That information is stored in $_SERVER['HTTP_HOST'], so you can use a simple script to figure out which subdomain has been requested and then launch the appropriate script for that subdomain. Something like this should do the trick:
// Assuming request comes from https://subdomain.mydomain.com
$subdomain = str_replace('.mydomain.com', '', $_SERVER['HTTP_HOST']);
echo $subdomain // Outputs "subdomain"
This will capture multiple levels of subdomains as well, so if your request comes from https://sub1.sub2.subdomain.mydomain.com then $subdomain would contain sub1.sub2.subdomain.
Edit after comment
You can't do this with shared hosting. Basically the config panel you get with the host, when you set up a domain or subdomain it's modifying the config file on the server for you. There's no way a host would let anyone access the config through anything other than their control panel for security. It's possible that hosts will have a similar setup to your test server, where subdomains just work as they use wildcards by default, but I don't know that and there's no guarantee of that.
WordPress itself is just blogging software. It doesn't let you set up lots of separate websites with their own installations. What WordPress Multisite (I assume that's what you mean when you mention WordPress) is use a single installation to host multiple "sites", but it's still one installation, one single database. All of the posts, all the pages, they're all stored in a single database and if you got into that database you could easily include a page from one site on another just by editing some fields in the database. It's not designed for reselling or for multiple, completely separate entities. There are a whole host of security risks in doing that sort of thing. It's designed for single entities that want to split their sites up into multiple sites, but where it's all one company, or related companies. Universities with different departments is one example I read about before, each department has their own "site" and the main IT office has a super user that can access all of them as it's on one single installation.
I could do with a little more information on what you're trying to do, but it sounds like you're trying to do something like WPEngine, where they sell hosting space and install WordPress for you. But they have dedicated servers that run scripts that create the config files and install WordPress on your own individual hosting space using their servers. That's known as SaaS (Software as a Service) and from the little you have said seems what you are trying to do. People subscribe to your site and get their own instance of the software you're selling that they access through an admin portal. That's not something they can install on their own hosting, they have to use yours. That's how most companies do this sort of thing.
I have a server on which I am using dokuwiki to host both a homepage as well as a wiki. The server is available under www.domain.com and the wiki is available under wiki.domain.com. Internally both subdomains are served from different directories.
However this means, that everybody who wants to sign up has to sign up for the both domains and manage a duplicate set of user accounts for both subdomains.
What I would like is to have a system, where anybody can sign up on both pages and only has to log in in any of the domains and get access. ACL should still be managed separately for both domains, since I might use namespace names multiple times.
I looked through the list oft dokuwiki auth plugins, but I was not able to find anything usefull for this purpose. Another idea would be to just soft- or hardlink the auth data directory in the two installations. However this would still mean users would have to log in multiple times. Also I am not sure whether my hoster actually allows such directory links, or if this might mess up the two installations.
Is there any other way to create such a setup?
A DokuWiki farm setup might help with having the same user database for both sites. Symlinking the user file is another way.
More complicated is to share the cookies between both domains. I'm not sure how to approach this best. Maybe others can offer some ideas.
Well since this is on the same server just across your various subdomains I would imagine you would want to store the user info including logins in a shared database so that no matter which app/subdomain you insert their registration data and query for their login info from the same database. Then it's a matter of using PHP sessions for keeping track of if they are logged in across subdomains. There is already a length stack on how to achieve that here:
PHP Sessions across sub domains
Try setting the Cookie Domain to .yourdomain.com
This means your browser will deliver cookies to subdomains of yourdomain.com.
So cookies will beshared among www.yourdomain.com and wiki.yourdomain.com
I have one site completely working for one client , now I have some more clients want same thing replicated for them , Is there any way , that I can use this site as base site , as I plan to access this site from there domain and providing database for each client.
I am using PHP and MYSQL.
Thanks for any support , I appreciate your point of view also in this process. do I have right approach
I have been told that there will be SEO issues if I use one site for multiple domain. I have no competent person available which can direct me on domain name linking. I have www.xyzuniversity.com and 85% data is fetching from database. now i have to create abcuniversity.com and I want that I just create new database and ready to use and I think I can make multiple sites like this , if I succeed
Thanks
You can point multiple domains to the site. You can get the domain name from the server vars ($_SERVER['HTTP_HOST']) and choose you database through that. Make sure you dont have any absolute links.
Put the shared code into a shared directory and give each domain it's own database configuration, so the database configuration is not shared.
Then start your application with the different configuration based on the domain, e.g. by server environment variables like the hostname.
If your design does not support a configuration that can be injected into the application, you need to maintain two code-bases, one for each domain, e.g. in source-code control with one branch per domain.
However I suggest that your code is that modular that it supports configuration for the parts that need configuration according to your needs. If it's not yet, think about coming closer to it and make the changes.
I have a file that is being linked to from other sub websites.
The file: http://site.com/file.img
Website A linking to it <img src="http://site.com/file.img"></img>
website B linking to it <img src="http://site.com/file.img"></img>
I need to reliably identify which of these websites has accessed the file, but I know that $_SERVER['HTTP_REFERER'] can be spoofed. What other ways do I have to reliably confirm the requester site? By IP, get them to register an IP? not sure. setup an API key? What options are there?
If a website is only linking to a file, the "website" itself will never actually access your image. Instead, the client who's viewing the site will make a request for the image.
As such, you're depending on information sent by the client, which is completely out of your control and not reliable at all. If you have the opportunity to set some sort of unique cookie on the client, you may be able to use this in some fashion for extended identification, but even that won't be reliable.
There is no 100% reliable solution.
Getting the referrer is the best you can do without getting into complicated territory.
If you don't mind complicated, then read on: set up your Web server to serve file.img only to Website A and Website B, then require that Website A and Website B set up a proxy configuration on their end that will retrieve file.img on behalf of their visitors.
Example:
A visitor to Website A loads a page that contains an image tag like <img src="http://websiteA.com/file.img"/> (note reference to Website A rather than your site). Client requests file.img from WebsiteA.com accordingly. Website A is configured to proxy requests for the path /file.img to your server, http://site.com/file.img. Your site verifies that it is in fact Website A that is requesting the image and then serves it to Website A's proxy. Website A then serves it to the visitor.
Basically, that makes it a pain for Websites A and B, gives you a performance hit, and also requires further configuration on your part. But I imagine that would satisfy your requirement.
Have a look at how OpenID relying is implemented, it allows one site to authenticate against another. The protocol specification will give a hint at the effort and overhead required to reliably implement such a scheme.
http://googlecode.blogspot.com/2010/11/googles-sample-openid-relying-party.html
I have a page that allows users to submit photos to the server. On another server I need to have a page that will have access to those photos on the first server and give possibility to upload/delete photos. What choices do I have considering that I have full access to both servers and I don't want to use php ftp.
Thanks
I need to have a page that will have
access to those photos on the first
server and give possibility to
upload/delete photos.
You need to have a look at Same Origin Policy:
In computing, the same origin policy
is an important security concept for a
number of browser-side programming
languages, such as JavaScript. The
policy permits scripts running on
pages originating from the same site
to access each other's methods and
properties with no specific
restrictions, but prevents access to
most methods and properties across
pages on different sites.
For you to be able to get data, it has to be:
Same protocol and host
You need to implement JSONP to workaround it.
One thing you can do is to setup a a shared drive (NAS - Network attached storage) between these boxes that the files will be stored on, then you will have access to the files from both servers.
The NAS shares can be mounted via NFS (assuming you using Linux)
HTH