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
Related
I have made my own theme in concrete 5 and produced a 600 page site, however im looking at speeding the site up according to Google Site Speed.
I did place the ..htcaccess file in the "themes" directory which contains my custom theme, however I think this was causing my site to have 500 internal server errors.
Where is the correct place of putting the .htcaccess file in the Concrete5 directory? Even better, does anyone have tips for what to include inside the .htcaccess. I have most of the content for it, but its mostly copied from gzip sites etc
Thanks in advance
It depends what you are doing in your .htaccess file and what the intention is. Usually though, you'll want to put it in your web root, i.e. place it at the same level as your main index file.
If you enable the "pretty url" feature of C5 via Dashboard > System & Settings > SEO & Statistics > Pretty URLs , it will generate an htaccess file for you at the proper place on your server (at the web root, as #danmullen mentions in his answer). Putting .htaccess in your theme directory will just not work, period.
How exactly does one do something like create a unique URL.
Like how facebook does it facebook.com/mynamehere
One way would be to create multiple folders each time we have a new user..but that doesn't seem to be the best approach
You can try a program like Elgg if you are trying to build a social media site. Otherwise, a person's profile can be custom in a couple of ways. Most of them mentioned. You, as mentioned, can use .htaccess for rewrites. You can use an automated custom url plugin (this may help: How to generate a custom URL from a html input?). Similarly, you can use the previously mentioned Elgg for social media, and but also as a last resort can use your folder method, but only if absolutely required.
I think the question is: how is it done technically, so we don't need to have physical file for every valid URL?
The answer is URL rewriting. In case of Apache server, you want to enable mod_rewrite and configure it to translate particular URL pattern (like myfbclone.com/mynamehere to myfbclone.com/index.php?username=mynamehere). This way you need to have one script file that handles all the URLs accordingly.
Different servers have different means of rewriting URLs, like Nginx or IIS, so the exact way of configuration depends on your server, but the concept is usually the same.
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.
I have a new client who asked me to make 2 websites and no payment so far!
I have the ftp accounts, but he can always close my access and leave me without pay.
Can I upload the CSS to another server of mine and encrypt the link to CSS file?
If yes, can I restrict peoples to see the file if they find the URL to CSS file?
Thank you!
If they are his hosting accounts, then accessing them to tamper with the code for the purpose of disabling his sites without his authorisation is probably illegal.
If he hasn't paid you, you own the copyright. If he refuses to pay you, file a DMCA complaint with his hosting company.
Technological measures like this are futile and unprofessional. Next time use a contract.
This is simple. Same scenario happened to me, and what I did was added an new index.html which was an under-construction page, and renamed the original index.php as index_to_be.php.
I then added a redirection using htaccess to the new index.html.
The client contacted me straight away and paid up in no time.
If you don't know how to use htaccess, you can simply add a header location value to the top php page.
header("location:index.html");
The best way to do this is to create a simple PHP file that allows you to access, edit and delete files on the server. You can also search for a ready made lightweight ftp script. Place the PHP file somewhere on the server nested in other folders and name it something like temp.php. Now even if the client blocked you access to the server, you can still access, edit and delete files on the server by pointing your URL to temp.php. When you get paid, be kind enough to remove the file. Don't forget to password protect it.
In your PHP file you can use opendir() to read files from a directory, and unlink() to delete files. If all you want to do is be able to delete files, then the script will not take you more then a minute to create.
UPDATE
You can use the following lightweight ftp script that will let you view, edit delete files and also give you the option to password protect it. http://sourceforge.net/projects/pafm/
You could remove the style sheet from the client's site, upload it to one of your servers and embed it from there:
<link rel="stylesheet" href="http://your.server/styles.css">
however, you will not be able to seriously obfuscate this. One idea that comes to mind is to add a huge number of spaces before the "link" tag to hide it in the source code view.
<link rel="stylesheet".....>
You could also lazy load it using jQuery, but that would disable the style sheet for users who have JavaScript turned off - mostly a no-go.
In the end, no matter what you do, all this will be trivially easy to circumvent. There is no way to reliably keep control over the site in the scenario you describe. Like #thirtydot says, the best thing to do is to send a screenshot instead.
This is probably like trying to kill a fly with a ICBM but...
You could always use a JavaScript to add the link element to the DOM, and run the JavaScript code through a JS obfusticator.
But still, that's hackish, and overkill, and ways you can get the link anyway.
If I have a very simple http directory:
default.html
info.html
contact.html
etc...
Should default.html link to the other files in the directory, I've always been able to simply use an anchor tag thus:
Contact me!
Will this always work, assuming that there is only one file in the directory with a name matching this extension-less href value?
It depends on the server and how it is set-up.
Remember that there's no innate mapping between URIs and files on a webserver, the webserver is always following some sort of rule as to what file to send. The simplest takes the path part of the URI and does a direct mapping to a filepath local to the webserver, but it could be doing just about anything else. A common case is using the file extension to do con-neg, so if you have contact.html and contact.atom and so on in the same local directory corresponding to the path, it picks that closest to the Accept header from the user-agent.
Putting file extensions (whether of "static" files or handlers like .php, .aspx, etc.) in URIs is rather pointless since there is no such thing as a file on the web (there are files on the server, and the client can save the stream to a file, but on the web itself there are octet streams that may or may not correspond to a file). And less than ideal; presumably contact.html has something to do with contact details, while "contact" expresses this idea well, ".html" has nothing to do with contact details and doesn't belong there.
Hence the more sensible URI would not have ".html" in it, unless this was in some way expressing something useful (such as explicitly asking for a HTML version and bypassing content-negotiation, or if the page was actually about HTML).
On the other hand, just mapping directly to file names is a quick and easy way to do things, so while I certainly frown on such arbitrary cruft in URIs I won't jump through too many hoops not to use it, especially in secondary URIs used for stylesheets, images etc. rather than those which are expected to regularly appear in the address bar of a browser.
On the third hand, once you remove such cruft, adding more sophisticated handling later if required, becomes a much easier transition.
There is a content negotiation feature in Apache2 which does that, but personally, I do not like to rely on that.
If I need nice URLs, I'd better use mod_rewrite and implement completely custom url scheme which would be easy to modify & customize without limits.
http://httpd.apache.org/docs/2.0/content-negotiation.html
No it does not automatically appends .html as he could not know which file extension to use. Let's say you have a contact.html and a contact.php. Which one should he use.
However you can do all this using rewrite rules (e.g. in a .htaccess file). Just search for some examples here on SO or in the web.