I have a website in angular using a api. Now i want to create automated landing pages.
My api url is made like this (https://) system.mydomain.com/api - its a rest api using slim framework
now i have created routes for the landing pages like (https://) system.mydomain.com/content/seo-name-of-item
this works but i dont want to show "system.mydomain.com" in this case (so in the URI "content") but then i want it to be (https://) mydomain.com/content/seo-name-of-item or/and (https://) www.mydomain.com/content/seo-name-of-item
what is the best approach to get this behaviour?
Most elegant probably is to use apaches proxy module in combination with rewriting rules. That leaves the URL visible in the browser unchanged but internally proxies the requests between otherwise separate http hosts.
Use such a rule in the hosts www.example.com and/or example.com host:
RewriteEngine on
RewriteRule ^/?content/seo-name-of-item https://system.example.com/api [END,P]
The syntax should work in the real http host configuration or in htaccess style files. But a general hint: you should always prefer to place such rules inside the http servers host configuration instead of using .htaccess style files. Those files are notoriously error prone, hard to debug and they really slow down the server. They are only provided 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).
If you get an internal server error with that (http status 500), you might have to replace the END flag with the older L flag.
You need validatable ssl certificates for the externally visible host name, so www.example.com and/or example.com.
You can also decide to use http internally, for the internal proxy connection, since ssl encryption does not really make sense there.
Oh, and obviously you need the proxy module installed.
An alternative would be to use the proxy module only. Take a look at the documentation and examples of the ProxyPass rule: https://httpd.apache.org/docs/current/mod/mod_proxy.html
Related
We have a Java/Jetty server. The servlets on this server are called by some of our internal applications over http.
I have been asked to create a webapp /website which will use many of these servlets / api.
However this is an external customer facing website and needs to be served over https / ssl. The servelet urls look like
http://internalServer:9999?parameters.
Now my webapp is ready and has been deployed on Apache on Debian. Everything works fine but as soon as I enable
https/ssl the backend calls do not go through. On chrome I get "Mixed content. Page was loaded on https but is requestig resource over http...". On Safari I get -could not load resource due to access control checks.
I understand the reasons for these errors but I would like to know ways to solve this.
I have full control over apache server and website code.
I have very limited control over internal jetty server and no control over servelt code.(don't want to mess with existing apps).
Is there something I can do just with apache configuration? can I use it as a reverse proxy for the Jetty(http) server?
Thanks for your help.
"Mixed content. Page was loaded on https but is requestig resource over http..."
That error message means your HTML has resources that are being requested over http://... specifically.
You'll need to fix your HTML (and any references in javascript and css) that request resources (or references resources) to also use https://....
If you try to call an http service from an https site you will have Mixed content error.
You can avoid that error using apache2 proxy settings inside your example.org.conf
You can find it inside the folder /apache2/sites-enabled
Add some code:
<VirtualHost *:443>
...
ProxyPass /service1 http://internalServer:9999
ProxyPassReverse /service1 http://internalServer:9999
</VirtuaHost>
From your https site you have to fetch the url
https://example.org/service1`
to reach the service.
In that way you can call your services http from a https site.
We needed to implement SSL for our Zabbix monitoring frontend and it's caused havok on some of our backend scripting (which would be more trouble than it's worth to fix).
I'm currently working under the theory that I should be able to use some redirection magic in order to:
Access our normal Zabbix Frontend via HTTPS
Access our API via HTTP (this is the key hangup right now).
Initially - redirection was easy enough:
<VirtualHost *:80>
ServerName <servername>
RedirectMatch /zabbix/(.*) https://<servername>/zabbix/$1
</VirtualHost>
But this causes all sorts of issues with our API calls needing to still be done via HTTP (which is being done via a scripts calling API values to drive interface selections in other tools). I actually end up getting a 412 response.
So I thought I could maybe do something like this:
RedirectMatch /zabbix/(!api_jsonrpc.php)(.*) https://<servername>/zabbix/$2
While this will still let my API succeed over HTTP, it doesn't redirect my zabbix frontend to HTTPS.
This has been driving me nuts! Any help would be appreciated.
Sample URLS:
https://<servername>/zabbix/zabbix.php?action=dashboard.view
https://<servername>/zabbix/index.php
http://<servername>/zabbix/api_jsonrpc.php
Ultimately - anything that isn't "api_jsonrpc.php" needs redirected to HTTPS, and anything with that value needs to go over HTTP.
We are using Apache 2.2 and upgrading is not currently an option.
Ultimately, the issue I was having was coming down to the fact that you can't really redirect POSTs.
To resolve this, I ended up winning my argument that he library file update (forcing all traffic over HTTPS) and mass push was the only working solution and we're now golden.
You cannot negate strings just by prefixing them with an exclamation mark, lookarounds would have to be used.
I don't think API requests pass any GET parameters - try the following:
RedirectMatch /zabbix/(.*)(?<!api_jsonrpc\.php)$ https://<servername>/zabbix/$1
I'm working on a site which shows lots of images hosted on third party CDN's. Right now, the images are not delivered over SSL. Is there a way to use mod_proxy in htaccess to do something like the following -
https://example.com/imageProxy?url=http://www.example.org/some3rdPartyHostedImage.jpg
Where I could take a given image URL and deliver it via my own server? In this way, I could have the images being served via SSL. I realize the security benefits of this is are a little dubious, but I'm trying to figure out if it is even possible at this point.
Weird your CDN doesn't provide SSL access.
Before continuing you must understand setting up a proxy on your Apache will kill most of the CDN benefits. Otherwise yes, you could make it.
I suggest you use your proxy through a rewrite rule, something in the lines of (examples straight from the documentation):
RewriteRule "/(.*)\.(jpg|gif|png)$" "http://images.example.com/$1.$2" [P]
Or (ref):
ProxyPassMatch "^/(.*\.jpg|gif|png)$" "http://backend.example.com/$1.$2"
We have an application runing on Weblogic 10.3, with authentication provided on the application itself. We want to put the Weblogic behind an Apache server. The idea is that we will have some public content on the Apache server, and the application will be accessed through the reverse proxy. That's pretty much very standard. The issue comes with the fact that there are some contents on the Apache server that can only be accesssed if the user has logged in the application. So basically the Apache server will server three type of contents, on diferent URIs:
/ -> Will contain the public information, and will be server by the Apache
/myApp - > Will be redirected by the Apache to the weblogic behind
/private - > Will contain the private static information. This should only be accessed if the user has previously logged successfully in myApp.
My question (I'm a total newbie with Apache) is if this possible. My idea is that the application can put a cookie on the responses indicating if the user has logged on the application, and that the Apache will check for that cookie when the user tries to access /private.
Any thoughts?
The / public information is no problem, it's straightforward. Using ProxyPass or ProxyPassMatch to reverse proxy "/myApp" to your internal Weblogic server is also straightforward. You may need to use a couple of other options to make sure proxy hostname and cookie domains are setup correctly. But setting up static protected infrormation in "/private" is going to be a little more tricky.
1) You can check the existence of the cookie set by myApp using mod_rewrite, something like this:
RewriteCond %{HTTP_COOKIE} !the_name_of_the_auth_cookie
RewriteRule ^private - [F,L]
The problem with checking a cookie through something like this is that there's no way to verify that the cookie is actually a valid session. People can arbitrarily create a cookie with that name and be able to access the data in /private.
2) You could set it up so that anything something in "/private" is accessed, the request is rewritten to a php script or something that can check the cookie to ensure that it's a valid session cookie, then serve the requested page. Something like:
RewriteRule ^private/(.*)$ /cookie_check.php?file=$1 [L]
So when someone accesses, for example, "/private/reports.pdf", it gets internally redirected to "/cookie_check.php?file=reports.pdf" and it's up to this php script to access whatever it needs to in order to validate the cookie that /myApp has setup. If the cookie is a valid session, then read the "reports.pdf" file and send it to the browser, otherwise return FORBIDDEN.
I think this is the preferable way of handling this.
3) If you can't run php or any other scripts, or the cookie cannot be verifed (like with a database lookup of session_id or something similar), then you'll have to proxy from within WebLogic. This would be more of less the same basic idea as having access to "/private" through "cookie_check.php" except it's an app on the WebLogic server. Just like /myApp, you'll need to setup a reverse proxy to access it, then this app will get the request (which has been internally rewritten from "/private/some_file") check the cookie's validity, read the "some_file" file ON THE APACHE SERVER, then send it to the browser, or send FORBIDDEN. This is the general idea:
ProxyPass /CheckCookie http://internal_server/check_cookie_app
RewriteCond %{REMOTE_HOST} !internal_server
RewriteRule ^private/(.*)$ /CheckCookie?file=$1 [L]
This condition reroutes all requests for "/private" that didn't originate from "internal_server" through the /CheckCookie app, and since the app is running on "internal_server" it can access the files in "/private" just fine. This is kind of a round-about way of doing this, but if the validity of session cookies issued by /myApp can only be checked on the WebLogic server, you'll have to reroute requests back and forth or something similar.
I'm trying to get my Tomcat to use pretty URLs, similar to Apache's MultiViews option. I tried using AJP to proxy Tomcat to Apache, but the .htaccess file is still ignored.
What are my options for Tomcat?
Use a Filter. Let it listen on /* and redirect any unfriendly URL to an friendly URL and forward any friendly URL to an unfriendly URL. A good opensource example is Tuckey's UrlRewriteFilter which behaves almost exactly like Apache's mod_rewrite.
If this concerns a brand new webapplication which is yet to be developed, then a better way is to adopt a MVC framework which supports RESTFul URL's, like Spring MVC. Or maybe homegrow a front controller servlet which makes use of HttpServletRequest#getPathInfo() to determine the pathinfo.