Htaccess separate for Localhost and Production - .htaccess

How to create an Htaccess which will have a specific and separate code for Localhost and Production. I mean when we work on localhost, it should be work localhost code and in Production it should be load only Production code. So that i can use one Htaccess for Local and Production and it will save lot of time. Following is the model i would like to implement. It would be much appreciate anyone can help on this. Because i spend lot of time on it and not found any good approach on this. Thanks in Advance!
<Localhost>
---localhost code goes here
---it should be only work in localhost and not at all in Production
</localhost>
<Production>
---production code goes here
---it should be only work in Production and not at all in Localhost
</Producton>

Most of the code in .htaccess should be the same on local and production. (Otherwise, how do you test it?)
However, one of the cleanest ways to separate directives between servers is to Define (requires Apache 2.4) a variable in the server config of one of the servers (eg. the development machine):
Define DEVELOPMENT
This can be defined anywhere in the server config (not .htaccess), but is always seen as global to the server, regardless of whether it is defined inside a <VirtualHost> container or not. You do not need to specify a value (2nd) argument since the <IfDefine> directive (see below) does not check this. As always, whenever you make changes to the sever config you'll need to restart Apache for the changes to take effect.
And reference this in .htaccess:
<IfDefine DEVELOPMENT>
# Local / development directives only
</IfDefine>
<IfDefine !DEVELOPMENT>
# Live / production directives only
</IfDefine>
The ! prefix tests that the variable is not defined.
Depending on what type of directives you need to contain you can use an <If> container and check something like the requested hostname (eg. staging.example.com vs www.example.com for the live site). However, <If> containers do not work the same with mod_rewrite.
Reference:
https://httpd.apache.org/docs/current/mod/core.html#define

Related

Is it possible to create a .htaccess rewrite/redirect rule which works like a symlink?

I want to publish a eclipse-updatesite in different versions.
All versions will be copied to a server, which i can only access via ftp.
i want to a folder structure like following:
myhost.de/storr/releases/0.0.1/ (/kunden/homepages/xx/dxxxx/htdocs/software/storr/releases/0.0.1/)
myhost.de/storr/releases/0.0.2/ (/kunden/homepages/xx/dxxxx/htdocs/software/storr/releases/0.0.2/)
myhost.de/storr/releases/0.0.3/ (/kunden/homepages/xx/dxxxx/htdocs/software/storr/releases/0.0.3/)
myhost.de/storr/latest/ (/kunden/homepages/xx/dxxxx/htdocs/software/storr/latest/)
If someone use myhost.de/software/latest/ he should get all the files out of the latest released version.
I tried to create a symlink and to copy it to the server, but it doesnt worked. i dont have ssh access.
Is it possible to create a .htaccess file which acts like a symlink?
Thanks in advance
Apache's Alias directive closely resembles a symbolic link, please check the documentation for that: https://httpd.apache.org/docs/2.4/mod/mod_alias.html#alias
Alias /storr/latest /storr/releases/0.0.3
Another option is indeed a rewriting rule:
RewriteEngine on
RewriteRule ^/?storr/latest /storr/releases/0.0.3 [END]
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
Both rules will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the modules needs to be loaded inside the http server and enabled in the http host (mod_alias or mod_rewrite). In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).

htaccess redirect to assets folder

Root:
/assets
/sms-sending
However, I have a ton of files: .svg, .png, .jpg only that are pointing to /sms-sending/assets, which is non-existence. How can I auto re-point those files to /assets instead of /sms-sending/assets
I already tried multiple answers, and wasn't able to find a similar problem.
Thanks
Not sure why that situation should be special in any way. There are endless solutions for this here on SO. Except of course if your situation is different to what you actually wrote in the question ;-) We can't say, since you did not post any of all those attempts you already made yourself...
Probably this is what you are looking for:
RewriteEngine on
RewriteRule ^/?sms-sending/assets/(.*)$ /assets/$1 [END]
If you want to place that rule in side a dynamic configuration file (as opposed to the http servers host configuration), then you need to store that file in the http servers document root and you need to enable the interpretation of such files (see the AllowOverride) directive in the documentation). Also you obviously need to enable the rewriting module.
In case you receive an http status 500 with that (internal server error), then chances are that you operate a very old version of the apache http server. In that case try replacing the [END] flag with the [L] flag.
And a general hint: you should always prefer to place such rules inside the http servers (virtual) host configuration instead of using dynamic configuration files (.htaccess style files). Those files are notoriously error prone, hard to debug and they really slow down the server. They are only supported as a last option for situations where you do not have control over the host configuration (read: really cheap hosting service providers) or if you have an application that relies on writing its own rewrite rules (which is an obvious security nightmare).

Mod_Proxy doesn't show OpenRefine App properly

I have OpenRefine (a webapp hosted by jetty) running on:
http://127.0.0.1:3333
Which looks like this:
Everything works perfectly.
Now I would like to tunnel this through Apache2 (for security and renaming reasons), so I changed my http.conf file and modified it like this:
ProxyPass /refine http://127.0.0.1:3333
ProxyPassReverse /refine http://127.0.0.1:3333
Now if I try to open the page through the proxy this is what I see:
It looks like all the dynamic content is not working properly. How can I solve this?
Notes:
I made sure mod_proxy is updated and working. Tested with other webapps from Tomcat.
You can use mod_proxy with OpenRefine without using virtual hosts.
I needed to do this exact same thing today. I have an SSL portal through which users must authenticate with some complicated PKI and LDAP tracking, and I need OpenRefine to be hosted behind this because of some data which it has access to. The answers to this problem given in this thread and elsewhere simply weren't acceptable, so I went through the source code expected to patch this behavior in--but I didn't have to!
I noticed that because OpenRefine runs out of a WEB-INF directory, it probably is probably built as a typical java web app. And sure enough, when I looked for how the context was being set on the server, I found this in Refine.java:
final String contextPath = Configurations.get("refine.context_path","/");
So this is what you do:
NOTE: StackOverflow won't let me write things that look like URLs because I don't have any reputation here. So when you read http:\, that really means http://.
1) In refine.ini, make sure that JAVA_OPTIONS includes "-Drefine.context_path=/refine". (It should go without saying that you changed refine.host to 0.0.0.0 instead of 127.0.0.1 and you also set refine.headless=true.) When you restart OpenRefine now, you'll access it at http:\your.refine.server:3333/refine (obviously put your server hostname in that url).
2) Now, for a simple example, we will make https:\your.apache.server/refine proxy to http:\your.refine.server:3333/refine .
In one of your httpd config files (maybe make a openrefine.conf in /etc/httpd/conf.d) put the following lines after enabling mod_proxy:
ProxyPass /refine http:\\your.refine.server:3333/refine
ProxyPassReverse /refine http:\\your.refine.server:3333/refine
The difference here is that OpenRefine is kept out of the global context, so the root of the application can be proxied. OpenRefine makes requests for resources with an absolute path, based upon how the context is set. So if you don't do this, OpenRefine will make javascript files which fall outside your proxy location, as everyone else on this thread was experiencing previously,
In real life, you might want to have mod_proxy use a load balancer over multiple OpenRefine instances and you might want to put some logic about which users are allowed to use this proxy tunnel.
Hope this helps someone else!
I also recommend that you review the undocumented Refine server properties which are also in Refine.java.
You changed the app location from http://your.server:3333/ to http://your.server/refine
You can see that a link with, for example, href="/resource.css" would no longer be valid since that resource has now moved to "/refine/resource.css". I think if you go digging through the HTML source you will find dozens of these links with absolute paths.
This configuration will break any absolute path references. The complicated way to resolve this issue is called URL rewriting, and there are in-depth tutorials for how to set up Mod-Proxy and Reverse with URL rewriting. It is complicated to explain, and easy to do wrong; instead add a VirtualHost so that absolute path links don't need rewriting.
<VirtualHost *>
ServerName refine
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass / http://127.0.0.1:3333/
ProxyPassReverse / http://127.0.0.1:3333/
<Location />
Order allow,deny
Allow from all
</Location>
</VirtualHost>
It's unlikely that you're going to find any absolute links to localhost:3333 so this will probably work for you. Change your /etc/hosts so that refine resolves to 127.0.0.1 and you'll be golden. You can now use refine with no problem from http://refine/.
127.0.0.1 localhost refine
If you're trying to enable access from outside hosts, a slightly more complicated setup will involve a new DNS record and should be easy to imagine from here.

IP restrict a subdomain using .htaccess

I would like to add a IP restriction based on the URL in my htaccess file.
This way I can keep my .htaccess file inside my git repo and use the development branch for dev.domain.com and the master branch for the live website on www.domain.com.
I need 1 htaccess since the dev site is a replica of the live site. On the dev site I'd like to have IP restriction. So I need 1 htaccess that looks similar on both environments, but the behaviour of restriction only kicks in on the dev uri.
How can I achieve this?
Thanks in advance.
order deny,allow
allow from 31.24.232.0/21
allow from 127.0.0.0/20
allow from 192.168.0.0/20
deny from all
you can put this in .htaccess at document root of your subdomain. but remember to change IPs.
That is why I am looking to have 1 htaccess file which contains a 'switch' to turn on restriction based on the visiting URI.
I've been looking for the same thing for a while, but it doesn't seem to be practically possible. Apache's configuration language knows some conditional blocks, but none to do this as far as I can see.
What I have often ended up doing is specifying two different AccessFileName properties on the dev and the production server. For example, on the dev server, I would set
AccessFileName .htaccess.local
the dev server rules would then go into .htaccess.local, and the production server ones into ? htaccess.

CodeIgniter not working on PHP 4 server without .htaccess availability

Basically i developed my app on a localhost wamp server with PHP 5. ON uploading to the actual host i notice that
The server is running php 4.4.9
Everytime i upload my .htaccess file, the server removes it completely.. seems to not be allowed
When i test out the set all i get is a 404 page not found
Any help on how to make it work on this PHP 4 server?
I did a test with CI 1.7.2, default installation.. works on my local server but when uploaded does not work, does this mean that the server does not support it?
I'm sure this isn't what you want to here, but get a new server. Here are the reasons why:
PHP 4 is no longer well supported. It's insecure.
If the server is removing .htaccess files, they are also unsupported on that server, giving you one more reason to move.
Code Igniter runs best with PHP 5 and with an .htaccess file.
The gist of this is you are going to have to hack your code back into the dark ages to get this to work, and then you will still have pretty URL issues and overall system instability. If you can make the switch, do.
If you cannot use .htaccess files with CodeIgniter, in system/application/config/config.php there is a configuration key called index_page. You need to set that to whatever page you have bootstrapping CodeIgniter (usually /index.php)
Then, make sure all your links that get routed through CI either target index.php/controller/action/params... or utilize the URL helper (with site_url or anchor) to automatically put in the index.php
Joe Mills is exactly right in his answer, though. CI works best with PHP 5 and .htaccess.
See CI URLs and CI URL Helper for documentation.
Well i found out how to fix several things
The issue with .htaccess would be to just not use modrewrite as such i put "query_string" option in my path variavable and this works.
The other issue, which was the major issue was that i was using Datamapper library which is a php 5 only library.

Resources