I have a server. Lets call it http://A.com
I also have an 'Enjin' forum board. Lets call it http://A.B.com.
The server is useful for many scripts and functional components for the admins. The forum boards are for the community, but I can only add HTML modules to it. No custom scripting.
Currently, I have it set up to redirect the index of http://A.com to http://A.B.com using HTML redirection, and so those who navigate to the root of A.com will be sent to the forums.
I would like to make it so if you navigate to http://A.com, it'll show the contents of http://A.B.com. We once used an iFrame, but that had a detrimental affect on the forums, so currently we just redirect them. I've seen someone using the same system have a URL such as http://C.com/forums/viewforum/212877 showing the contents of http://C.B.com/forums/viewforum/212877
I assume mod_rewrite could be capable of this, but how exactly?
It sounds like you want to set up a reverse proxy wherein a client requests a page from http://A.com/ retrieves the page from http://A.B.com/ using HTTP, and then returns that content as it own response to the client.
See http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxyvia
"A reverse proxy is activated using the ProxyPass directive or the [P] flag to the RewriteRule directive. It is not necessary to turn ProxyRequests on in order to configure a reverse proxy."
You would need to check what happens regarding links on pages. If http://A.B.com/ uses absolute links then they will be to pages inside http://A.B.com/ . But relative links will still be under http://A.com/ .
Related
I would like to have the following setup using .htaccess.
domain.com/test/hello.php or domain.com/index.php or any other link must show only domain.com in the URL.
Kindly share your views on this.
As implied by Jon Lin, this is not directly possible as the server cannot guess what content should be loaded. The simple rule of HTTP is that each request has its own response.
Furthermore, it should be noted that, if it were possible (by some kind of magic - perhaps by the use of AJAX), it wouldn't be good for SEO, as Google/Bing/whatever wouldn't be able to index your site.
If you really wanted to mimic the behaviour, you could run the following HTML5 History API method in JavaScript:
window.history.pushState("", document.title, "/");
This will change the address bar to show only your domain name, and will more than likely have side-effects.
I am trying to enforce SSL on a folder (blog admin). That part is fine - all pages are SSL, but the site is generating error messages for insecure contents on the page. I can go after all those links individually, to enforce SSL on the links.
I was wondering if that could be done through htaccess alone?
This is what I have done for SSL enforcing on the admin folder:
#forcing https for admin folder
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_URI} admin
RewriteRule ^(.*)$ https://mysite.com/blog/admin/$1 [R,L]
How can I convert all the non ssl links to ssl on the same page ?
Addition:
1) I am using wordpress 3.6 with different plugins that come along with it. Only the admin areas is SSL, and the rest of it, other than login page (that is outside of admin is also SSL) are non SSL (for example the Blog feed for the end users).
2) A few of insecure contents are coming from my own site, but then there are others which are coming from the plugins I am using. For example disqus commenting system, and flickr.
3) I can force the internal links for images, css, and jscript by simply using 'setting for permalink' on wordpress (noticed the url was provided as http and not https). Similarly, I can locate and fix the other links like this one:
The page at https://mysite.com/blog/wp-login.php ran insecure content
from
http://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js?ver=3.6
4) The issue is:
If I use permalink setting, then the blog links are created as https
instead of http, and that breaks the plugins I am using for the non
SSL pages, for example disqus comment feed don't show up on the blog
page. Secondly, The painful process of fixing all the non ssl links.
Also, I can always miss out on some of them, since I am doing it
manually. It would be really helpful, if I could enforce SSL for all
these non SSL links using htaccess, perhaps the only easy solution.
Rewrite rules (which are in in fact redirections, when it's about HTTP to HTTPS) won't help, since by the time the initial plain HTTP request reaches the server, it's too late.
It's the links on the page you serve that must be addressed. This is generally up to the application (e.g. your PHP/CGI applcation) running on the server, not up to the server itself. The server would need to be able to process the content of the responses it sends to replace these links, not just redirect the requests (like mod_rewrite does).
mod_proxy_html (distributed with Apache 2.4 or separately in earlier versions) is a module that can to in-depth processing of the response, but I'm not sure whether it can be used as a post-processing tool for PHP running on the same server, to rewrite the links it sends.
Of course, this won't fix links to external resources that are not available via https:// anyway.
how can i view the real URL without the functionality of .htaccess rewrite file ?
while using url rewrite with the .htaccess file you able to see sites like this :
example.com/i/154/b/6574534
i want to see the "source" of the url , such as
example.com/index.php?i=15&b=6574534
It sounds like you want to reverse the URL rewriting, without having server-level access to the server you are interested in. If this is the case, what you're asking for is not possible unless the server provides an API, a custom HTTP header in the response, another link on the page, or some other method to find the non-rewritten URL. The ability to do otherwise would defeat many purposes of URL rewriting.
I've been asked to figure out how the Concrete5 system works for an employer, and I can't figure something out.
I have Concrete5 installed to a directory on the server called /realprofessionals. When the Concrete5 system makes new pages, it gives them their own absolute paths, for instance:
http://www.wmcpartners.com/realprofessionals/footer
However, it hasn't actually made a folder in the /realprofessionals directory called footer. So how does that work? How can http://www.wmcpartners.com/realprofessionals/footer be a working link?
Short answer: All page requests are actually going through the one and only index.php file. Page content is stored in the database, not in files on the server.
Long answer:
Concrete5 (and most PHP-based CMS's for that matter) work like this: all requests are routed through the index.php file. This routing is enforced with some mod_rewrite rules in the .htaccess file. The rules say "for any request, don't actually go to that page, but instead go to index.php and pass the rest of the requested path as $_GET parameters". Then in the index.php code (or some other code that is included by the index.php file), the requested page is determined based on the path that was put into the $_GET parameters by Apache (as per the mod_rewrite rule in .htaccess), and the appropriate content is retrieved from the database.
Storing content in the database as opposed to files on the server has several advantages. For example, you can re-use the same html template -- header, footer, sidebar -- on every page, and if you change the template it will automatically be reflected on all pages it's used on. Also, it makes it easier to shuffle pages around and to give them whatever URL you want (e.g. no ".php" extension at the end, or /2010/11/date/based/paths/for/blog/posts).
The disadvantage of course is that every request requires many database queries, but for most sites (those without zillions of page views), the trade-off is well worth it (and various types of caching can help reduce the performance hit).
Jordan's answer is excellent, I would add that you probably don't see index.php in the url because you've enabled pretty URLs (type 'pretty' on concrete5's searchbox to check that).
Anyhow, the best way to programmatically add link to internal pages is:
<a href="<?=$this->url('page-name');?>">
page name
</a>
It works both on localhost and online, with or without pretty URLs.
(For the page-name go to dashboard/full sitemap/page-name/properties/page paths and location.)
I have a simple rewrite rule that writes to an external domain using the Helicon Isapi_Rewrite 3 RewriteProxy derictive.
Example: RewriteProxy blog http://blog.com
However, links on the external site are not masked by the proxy as I would have expected them to be. They are still pointing to http://blog.com/link1 rather than http://mysite/blog/link1.
Could anyone point me in the right direction of a solution to this?
Thanks
This discussion on the Helicon Tech forums addresses the same issue.
http://www.helicontech.com/forum/8460-rewrite_proxy_to_2d_machine.html
The first example provides code for ISAPI Rewrite 2, but the thread includes ISAPI Rewrite 3 syntax further down the page. Here's an adaptation of their version 3 code for your example.
RewriteEngine on
RewriteBase /
RewriteRule ^blog$ http://mysite/blog/ [NC,R=301]
RewriteProxy ^/blog(/.*)?$ http\://blog.com$1 [NC,U]
(This is untested because I am running ISAPI Rewrite 2.) Note that I hit some snags when attempting to reverse proxy another site under my "main" domain. You might discover these issues as well.
1) Non-Relative Links
Unless the application has been coded from the ground up to assume reverse proxying, I found it likely to break. A bare-bones HTML page using all relative links like will work. However, serving HTML through a reverse proxy that contains this code will map to http://mysite/page_from_the_root.html. ISAPI Rewrite does not know to intercept that request, but it would proxy content if the user's browser hit http://mysite/blog/page_from_the_root.html
2) Cookies
Blog.com might write cookies from the blog.com domain. A page served through the MySite domain might not be able to access these cookies, depending on the user's browser settings.
3) JavaScript and AJAX
4) SSL Certificates