I have a splash page hosted at www.someserver.com and I'm looking to have one link on the page lead to a site hosted on another server, www.anotherserver.com. I probably need to keep these on distinct servers for the time being.
I'm hoping to have the whole thing appear under a a single company domain, www.company.com, and to have it so that when a user clicks on this link, you see neither www.someserver.com nor www.anotherserver.com, just www.company.com.
I know that I can set up some kind of domain masking (we're using GoDaddy for our hosting), but I'm worried that clicking out to www.anotherserver.com is going to keep this from all appearing under the same domain.
Is there a way to set this up so that links from and to both of these servers appear as www.company.com?
The good news is that what you are wanting to do is very common, it is called "proxying". I believe that godaddy uses apache so specifically you will want to look for mod_rewrite. You will more than likely simply have to provide a .htaccess file with the rewrite rules in it.
Here are the gotchas that you will run into though:
Client hits www.company.com
www.company.com pulls content from www.anotherserver.com
www.company.com sends content back to the client.
The issues come in with the data that www.anotherserver.com sends back to the client. Enter the world of relative and absolute paths.
Let's say that the actual request is www.company.com/widget:
Client hits www.company.com/widget
www.company.com requests www.anotherserver.com/widget
www.anotherserver.com/widget returns a page but on that page it has a link to www.anotherserver.com/widget/image.jpg
www.company.com returns the content back to the client but now the client has a link to www.anotherserver.com/widget/image.jpg
You will need to make sure that your backend servers use relative paths instead of absolute paths. http://en.wikipedia.org/wiki/Path_(computing)
Related
I am creating a small internet site for my personal stuff. I want to put there a few links to e.g. FTP resources or SVN server.
The important thing is that the FTP server has the same IP address as the page. I don't want to hard-code the address of my site in the link, because I consider this an anti-pattern. Instead, I would like to tell browser that the resource is on the current server, whichever server it is.
Let's say that the current page is https://example.com/stuff/index.html. If I create a tag things, it will lead to https://example.com/things.index.html.
However, if I add a protocol identifier to an URL, it won't work. For example, download will lead to ftp:///files/thingies.tar.gz, not to ftp://example.com/files/thingies.tar.gz.
What magic code should I put in the place of question marks:
download thingies
UPDATE:
I would prefer a client-side solution. My server machine has very low processing power and RAM amount.
In php (server side language code) if you'd like to forward
ftp:///files/thingies.tar.gz
to
ftp://example.com/files/thingies.tar.gz
considering example.com is the domain where your server is hosted, just do
echo 'ftp://'.$_SERVER['HTTP_HOST'].'files/thingies.tar.gz';
or, in your specific case
download thingies
Not 100% sure if this is the right SE site to ask this, so feel free to move/warn me.
If I have a site www.mysite.com with a form on it and define its action as "http://www.mysite.com/handlepost" instead of "/handlepost", does it still get parsed as a local address by apache? That is, will apache figure out that I'm trying to send my form data to the same server the form resides on and do an automatic local post, or will the data be forced to make a round trip, going online, looking up the domain and actually being sent as an outside request?
Apache does not look at this information. It's your browser which does this job.
On the Apache side the job is only outputing content (html in this case), apache does not care about the way you write your url in this content.
On the browser side the page is analysed and GET requests (images,etc) are sent automatically to all collected url. The browser SHOULD know that relative url /foo are in fact http://currentsite/foo - or it's a really dump browser -. It is his job. And then it's his job to push the request to the right server (and to known if he should make a new DNS request, build a new HTTP connection, reuse an existing opened connection, build several connections -- usually max 3 conn per DNS--, etc). Apache does nothing in this part of the job.
So why absolute url are bad? Not because of the job the browser should have to do handling it (which is in fact nothing, his job is transforming relative url to absolute ones); It's because if your web application use only relative url the admin of the web server will have far more possibilities on proxying your application. For example:
he will be able to server your web application on several different DNS domains
(and then make the browser think he's talking to several servers, parallelizing static files downloads)
he could as use use this multi-domain to set up the application for different costumers
he could build an HTTPS access for external network access and an HTTP (without the S) access on a local name for the local network
And if your application is building the absolute url these tasks will become really harder.
dont use absolute URL's . As i feel it will do a round trip in your case as you have used round trip for the action part. so better use releative URL's
I was wondering how to keep images secure on my website. We have a site that requires login then then user can view thousands of different images all named after their ID in the database.
Even though you need to login to view the images the proper way...nothing is stopping a user from browsing through the images by typing <website-director>/image-folder/11232.jpg or something.
this is not the end of the world but definitely not ideal. I see that to stop this facebook just names the images something much more complicated + stores them in hashed folders.
Gmail does a very interesting thing, their image tags looks like this:
<img src=/mail/?attid=0.1&disp=emb&view=att&th=12d7d49120a940e5>
I thought the src attribute has to contain a reference to an image??...how does gmail get around this?
This is more for educational purposes at this point, as I think this gmail scheme might be overkill for our implementation.
Thanks for your feedback in advance,
Andrew
I thought the src attribute has to contain a reference to an image?
GMail is referencing an image. It's just being pulled dynamically, probably based off of that th=12d7d49120a940e5 string.
Try browsing to http://mail.google.com/mail/?attid=0.1&disp=emb&view=att&th=12d7d49120a940e5
Instead of it being a direct path to its location on the server's filesystem, it uses a dynamic script (the images may even be in a database, who knows).
Besides serving up an image dynamically from your webapp, it's also possible to use a webapp to dynamically authorize access to static resources that the webserver will serve -- commonly by putting the files somewhere that the webserver has access to, but not mapped to any public URI, and then using something like X-Sendfile (lighttpd, Apache with mod_sendfile, others), X-Accel-Redirect (nginx), X-Reproxy-File (Perlbal), etc. etc. Or with FastCGI you can configure an application in a FastCGI "authorizer" role rather than a content provider.
Any of these will let you check the image being authorized, and the user's session, and make whatever decision you need to, without tying up a proceses of your backend application for the entire time that the image is being sent to the client. It's not universally true, but usually a connection to the backend app represents a lot more resources being reserved than a connection to the webserver, so freeing them up ASAP is smart.
The code that runs after this GET request is issued:
/mail/?attid=0.1&disp=emb&view=att&th=12d7d49120a940e5
outputs an image to the browser. Something doesn't have to be named with a .jpg or .png or whatever ending to be considered an image by a browser. This is how captcha algorithms are able to serve up different images depending on a value in the id. For example, this link:
http://www.google.com/recaptcha/api/image?c=03AHJ_VusfT0XgPXYUae-4RQX2qJ98iyf_N-LjX3sAwm2tv1cxWGe8pkNqGghQKBbRjM9wQpI1lFM-gJnK0Q8G3Nirwkec-nY8Jqtl9rwEvVZ2EoPlwZrmjkHT7SM32cCE8PLYXWMpEOZr5Uo6cIXz1mWFsz5Qad1iwA
Serves up this image:
So the answer really is to just obfuscate your image names/links a bit like Facebook does so that people can't easily guess them.
We have 2 different websites. One is xy.com another is xyz.com. The domain xyz.com is redirected to a folder on xy.com\one
This works fine. Now we want a particular link to be opened (for example, www.xyz.com\abc.html). I am placing this file in xy.com\one\abc.html. But when I enter this url, it takes me to home page, instead of abc.html. Though I can open abc.html, by entering www.xy.com\one\abc.html.
I need to open this file, from link, www.xyz.com\abc.html. How to accomplish this??
Regards,
Rahul Jain
I think the problem is your slashes are reversed. Did you keep your url's near a strong magnet?
If you are using apache you might want to have a look at mod_rewrite. There are similar methods available for other servers.
Would be good to know which environment you are using (web server and server side language) and if you are applying the re-direct rules in a programmatic way or via server configuration.
To give a serious reply, there could be several things wrong in the redirect.
You have to setup a redirect from the old domain to the new, by using a .htaccess on the old domain, changing the DNS records for the domain, or probably some other alternatives. Which of these have you used?
In case of the second option the receiving server (xy.com) has to accept the incoming domain (xyz.com). When I set my DNS records for a domain to go to a certain server, I have to actually setup the server to accept that domain, usually by "parking" it in Cpanel. Some hosts charge per parked domain, which is why they don't accept the incoming traffic automatically.
Depending on the method used, the receiving server has to be told what to do with the request.
So most importantly: HOW did you set up the redirect? Was it a DNS record? Was it a htaccess on the side of xy.com? Any other methods? (sorry, this isn't really an answer either but it was too long for the comments)
I was wondering what's the best way to switch a website to a temporary "under costruction" page and switch it back to the new version.
For example, in a website, my customer decided to switch from Joomla to Drupal and I had to create a subfolder for the new CMS, and then move all the content to the root folder.
1) Moving all the content back to the root folder always create some problems with file permissions, links, etc...
2) Creating a rewrite rule in .htaccess or forward with php is not a solution because another url is shown including the top folder.
3) Many host services do not allow to change the root directory, so this is not an option since I don't have access to apache config file.
Thanks
Update: I can maybe forward only the domain (i.e. www.example.com) and leave the ip on the root folder (i.e. 123.24.214.22), so the access is finally different for me and other people? Can I do this in .htaccess file ?
One thing to consider is you don't want search engines to cache your under construction page - and you also don't want them to drop your homepage from the search index either (Hence just adding a "noindex" meta tag isn't the perfect solution).
A good way to deal with this is do a 302 redirect (temporarily moved) from your homepage to your under construction page - that way the search engine does not cache your homepage as an under construction page, does not index your under construction page (assuming it has a NOINDEX meta tag), and does not drop your homepage from the search index either.
One way would be the use of an include on your template page.
When you want the construction page to show, you set a redirect in the include to take all traffic to the construction page.
When you are done your remove the redirect.
What about hijacking your index.php file?
Something simple, along the lines of
<?php
if (SITE_OFFLINE)
include 'under_construction.html';
else
//normal content of your index page
?>
where you would naturally define SITE_OFFLINE in an appropriate place for your needs.
What I did when I used PHP for websites was to configure Apache to direct all requests to a front controller. You then would have full access to all requests no matter where they are pointing to. Then in your front controller (PHP file, static html file, etc.), you would do whatever you need to do there.
I believe you need to configure pathinfo in Apache and some other settings, it has been about 3 years since I have used that approach. But, this approach is also good for developing your own CMS or application so that you have full control over security.
You have to do something similar to this:
http://www.phpwact.org/pattern/front_controller
I am looking for more details, I know my configuration had more to it than that.
This is part of what I'm looking for too:
http://httpd.apache.org/docs/2.0/mod/core.html
Enabling path_info passes path information to the script, so all requests now go through a single point of entry. Let me find my configuration, I know vaguely how this works, but I'm sure it looks like a lot of hand waving.
Also, keep in mind that because all requests are going through this single PHP file, you are responsible for serving images, JavaScript, CSS, etc. So, if a requests is coming in for /css/default.css, that will go through your php script (index.php, most likely), then you'll need to determine how to handle the request. Serving static files is trivial, but it is a little more work.
If you don't want to go that route, you could possibly do something with mod_rewrite so that it only looks for .html, .htm pages or however you have your site configured. For me, I don't do extensions, so that made my regex a little more difficult. I also wanted to secure access to all files. The path_info was the solution for me, but if you don't need that granularity, then writing a front controller might be a bit too much work.
Walter