I am trying to find the best way of displaying content that resides under a different server location.
So I have a domain where have the main site content is located at:
/home/user/my_site/www/
and accessed at:
www.example.com
I have another site (a blog) located at:
/home/user/the_blog/www/
I wish to get the blog content to appear at:
www.example.com/news
I was planning on using an .htaccess file at my_site to set the rules for the path:
/news
However the content for the blog resides outside the .htaccess document root, so although U can set a rule it won't be able to access this content.
Is it possible to change the document root somewhere higher up the chain?
Or is it possible to just create a symlink for the /news folder? Is this even advisable?
Thanks in advance
Tom
You could set an alias to that location:
Alias /news /home/user/the_blog/www
But that can only be set in the server or virtual host configuration context and not in a .htaccess file.
Since both directories aren't in your DocumentRoot, I don't see how mod_rewrite can work here. And I don't think anyone would recommend symlinking. The way I see it, there are only two ways out of this: either change your DOcumentRoot or move the latter directory into the current DocumentRoot.
Related
I am using shared hosing for Codeigniter application for deployment.
How can i run staging url on live server?
1) domain.com (Working)
2) domain.com/staging/ (Not working, showing 404 error)
I created staging folder under public_html directory, now put All CI code in staging folder, and tried to run the application with URL domain.com/staging/ but it redirect on domain.com/404
I expect to run domain.com for users and domain.com/staging for development. (Staging URL i will use for development and after that i will place the same code for live URL.)
This is most easily done by using a subdomain for the staging version, i.e. staging.doman.com. The folder where you put the CI files isn't super important as the subdomain will be set to use the directory you choose.
You will either need to have complete control over the server or have a service provider that allows you to set up subdomains.
- Expanded Answer -
If you cannot set up a subdomain then your next best option is to use the advice in the documentation on Managing you Applications. It isn't required to use the file structure shown there. In your case try the following.
Create a folder on the same level as application named staging.
Into that folder copy all the folders and files normally found in /application.
Add all application folders and files required by your site. The files in these folders are those that make up the application you are staging.
Make a copy of index.php (the file at the root of the public folder, i.e. domain.com/index.php) and name it staging.php. Both index.php and staging.php will be in the same folder.
Edit staging.php and change the value of $application_folder to be the absolute path to the staging folder. For example:
$application_folder = '/path/to/domain.com/public_folder/staging';
The path above is an example. You must replace it with the actual path in your server. If you have no idea what the full and absolute path is you can use
$application_folder = dirname(__FILE__).'/staging';
Browse to the URL domain.com/staging.php and you should get your default controller's output. To test that you are actually seeing the staging version of the page temporarily change something in the view file so there can be no doubt.
You will go to other controllers by using the URL domain.com/staging.php/other_controller.
Change the value of $config['index_page'] in /staging/config/config.php to staging.php, e.g.
$config['index_page'] = 'staging.php';
Without the above change redirect() and many other "helper" functions will not work correctly.
(Optional?) You can probably edit the main .htaccess and add rewrite rules for staging.php the same way it is done for index.php. But I will leave that as an exercise for you. (Or for another SO question.)
A final word. It might be necessary to make other configuration changes to accommodate the revised file structure. I tested the answer here but did not go beyond the most basic task of browsing to controllers. Most likely config values for sessions, cookies, and many others will need to be adjusted for the staged version to work correctly. Check out the documentation on Handling Multiple Environments for guidance on making this less painful.
Currently I've put my laravel site online (just for testing). But when I go to for example www.mysite.nl/.env it shows my password etc. for my database. How can I prevent this?
It should be mentioned that use of .env files is intended to be for development only, not production.
Once you're ready to take the site live, the values that you put in the .env file should be moved to the server environment variables.
This should be more secure for two reasons:
The problem you've discovered, that the .env file is accessible, will no longer apply, since there will be no more .env file. Plus, this won't require any server configuration changes (.htaccess files or similar) to restrict access to the .env file.
Server environment variables will not be accessible to anyone without shell access to the server.
Also keep in mind that .env file should not be reachable by users. Only the public/ folder content must be reachable. Set your server configuration to do it ( not always possible though ).
Otherwise, for your production environment you can simply ommit the .env file and define all the settings directly in app/config/
Some hosters also provide their servers with Forge.
Remember to always put your .env file into the .gitignore file if you are using it.
Have a nice day
Removing .env alone doesn't guarantee that your code is safe. As the only reason why this happen is that you ignore the default recommended structure which is to only give access for the web server to public directory.
Now, let say you removed the .env file. Are you sure that:
Nobody can access storage/logs/laravel.log (or daily rotating log file).
Are you sure you're cache and session data is safe, if you're using file based driver.
Are you sure nobody can peek at your compiled blade view under storage/framework/views.
Don't ever skip and compromise security to solve your webhosting limitation.
To hide .env on apache server add this below code in top of your htaccess file. this will also hide directory list view and will hide gitignore webpack config and more. hope that helps
# Disable Directory listing
Options -Indexes
# block files which needs to be hidden, specify .example extension of the file
<Files ~ "\.(env|json|config.js|md|gitignore|gitattributes|lock)$">
Order allow,deny
Deny from all
</Files>
# in here specify full file name sperator '|'
<Files ~ "(artisan)$">
Order allow,deny
Deny from all
</Files>
Be careful, the accepted answer skips over an important detail. Even if the .env file is removed, the directory that it resides in should not be accessible in the first place.
Instead of attempting to deny access to a list of files or folders as some people suggest, the web server's Document Root should be set to the /public folder in a Laravel application. All requests will then be mapped safely starting from /public, which means that the source files of your application are not accessible from the web unless you explicitly give access to them.
I've noticed that on several web pages e.g. StackOverflow instead of stackoverflow.com/questions/ask.php they have stackoverflow.com/questions/ask.
How is this done?
If I understand your question right, you just want to have file-names|tags|titles|categories after the last slash to route semantically to the according file or a hidden path;
If so, you will gain this dependent on the possibilities you have:
A) Do you have access to httpd.conf on your Server?
Look out for the DirectoryIndex;
OR
B) If you are not able to edit httpd.conf, do you have access to .htaccess on your server?
Look out if DirectoryIndex is already set anywhere, in most cases it won't; so you want to create your own new entry;
TODO:
Now define the DirectoryIndex by letting this reserved word be followed by the filenames you want to have
been routed to another filename or path/filename
GODO:
DirectoryIndex
[SPACE]
file-name.ending OR file-name OR tag OR title-with-some-words-bond-together
[SPACE]
repeat step 3 and 4 until you have a set of catchers to be caught ...
at least: add the target of your set by spending a path
DOJO:
RELOAD your server
OR
RESTART if necessary
EXAM:
DirectoryIndex index.html index.htm index.pl index.asp index.jsp index /routed/to-path_of/index.php
DirectoryIndex ask ask.php
MOJO:
This is a quant of what you can achieve; Look out for pretty-printing URL's, apache mod-rewrite, DirectoryIndex, URI URL hiding, domain forwarding and similar keys you can google for.
In most cases it would have been realized by well-known BLOG/CMS-SoftWare like WordPress, JOOMLA, DruPal, etc. via mod-rewrite, as this is the controlled and preset way if necessary rights are given.
Personally i would recommend to use the simple format of setting DirectoryIndex via .htaccess, as i explained before, because if you realize your own magic-words you may want to write a script that checks for hash-changes, sniffs history and responds accordingly to server-errors.
If you program it in DJango, NodeJS, or other WebApp language, they actually parse the URL and do not give you files. Instead it is known as views and map into a certain piece of code.
I suggest your learn NodeJS.
It is done through a .htaccess file...
I noticed Joomla, Wordpress and other CMSs have blank index.html files in ALL their sub folders to prevent people from peeking into the folder structure. My question is why can't they forbid folder viewing using the .htaccess file instead of putting a blank index.html file into all the folders. What's the difference and why have they chosen index.html?
Turning off folder 'Indexes' is best done in the master httpd.conf or vhosts.conf file rather than local .htaccess files.
Joomla (and Mambo before it) have been around quite a while and are used widely on shared hosting servers. The decision was taken to use index.html files as a safe fallback given the 'mixed' nature of shared hosting. Obviously .htaccess files are apache only, can cause server 500 errors if present on servers not expecting them or if they contain directives not supported by certain server setups. Consequently by default Joomla doesn't ship with a .htaccess file as such. There is a htaccess.txt file which the user needs to put in place manually if they activate certain features. It is assumed that a user knowledgeable enough to put the file in place will understand the consequences and if it does kill their site they will immediately understand the cause - due to the error immediately following their actions.
As server setups have advanced there is (sometimes heated) discussion about the current validity of the use of index.html files - but for now the policy is that all add-ons should ship with 'blank' index.html files in all folders.
I recently migrated my magento website to a different server, and here's the process I used:
made a dump of the database.
copied all the system files from the FTP to my hard drive.
emptied the VAR folder
emptied the media cache folders
replaced the strings in the SQL dump from http://www.oldsite.com to http://www.newsite.com
restored the database on the new server
modified the local.xml file to suit the new database host, login and password.
uploaded the system files to the new server
Everything seems to work fine, except for the fact that the product images are not being displayed on the frontend for some reason.
For example, here's a path from an image that was supposed to be showing, which I got through firebug:
http://www.newsite.com/media/catalog/product/cache/1/small_image/113x113/9df78eab33525d08d6e5fb8d27136e95/1/_/1_9.jpg
When I search for the path of the image the site is supposed to show in the FTP, the file is actually there. I can download it and display it on my computer. I don't know why this is happening. It doesn't make any sense to me.
This /media/catalog/product/cache/ was generated by the system, because I erased it myself before uploading the site, so I guess it isn't a cache related issue.
Well, I described the issue the best I could. I hope you can help me out.
EDIT:
Hmm, it turns out the problem was the .htaccess file inside the media folder! Removed the file -> Problem solved!
Just in case anyone else has the same problem, removing the .htaccess in the media folder did the trick. I don't know if that's the best possible solution though! Thanks!
Change Options All -Indexes to Options -Indexes in the above mentioned .htaccess file.
copied all the system files from the FTP to my hard drive.
This one makes me a bit suspecting. Magento has case-sensitive folders in the media folder. There would be, for instance, an 'a' folder and an 'A' folder in the same location.
If you downloaded your files unarchived (file by file) via FTP to a Windows machine, this would cause a conflict and would omit up to half your images.
Ok, since everything checked out with the base URL, my next suggestion is a migration path option if you have cPanel on the old server, and since most do, this should help:
Create a full backup of the account using cPanel. This will create a tar.gz of the entire account.
Download the tarred backup to your computer and unzip.
Find home_dir.tar - this is what contains your HTML root information. You can either upload this directly to the server and untar there using SSH, or do it on your local computer and upload.
Find the SQL folder in the untarred backup. There should be a dump of your database there. Use source to put that information into a new database.
On the server, delete use_cache.ser and change config information for the new database.
Your .htaccess should have come over in the home_dir.tar, but make sure that it's correct per our other question
Once that's done, you should be fully functional, unless you need to make changes in the database base_url for the new server.
Images not showing in Magento 1.7 to 1.9 upgrade:
My solution:
in /media/.htaccess
fixed options syntax:
# Options ExecCGI Includes IncludesNOEXEC SymLinksIfOwnerMatch -Indexes
Options +ExecCGI +Includes +IncludesNOEXEC +SymLinksIfOwnerMatch -Indexes
removed these. Maybe conflict with .htaccess in site root directory??
# For security reasons, Option followsymlinks cannot be overridden.
# Options +FollowSymLinks
# Options +SymLinksIfOwnerMatch
# RewriteEngie on
also changed ownership of .htaccess to apache
chown apache:apache /var/www/mystore/media/.htaccess
Would like opinion of why these may be causing 500 errors.
php bin/magento catalog:images:resize
This helped me, but it take's a lot of time to complete
for magento 2.4.5
in pub//media/.htaccess
change „FollowSymLinks“ to „SymLinksIfOwnerMatch“. example:
############################################
enable rewrites
Options +SymLinksIfOwnerMatch
RewriteEngine on
## you can put here your pub/media folder path relative to web root
#RewriteBase /magento/pub/media/
############################################