I am trying to do the following
setup a proxy so i can go to this url
http://localhost/shopify-api-myshopifystore
that points to https://myshopifystore.myshopify.com
this code below works BUT I want to be able to go to
http://localhost/shopify-api-myshopifystore/admin/api/2021-01/orders/4371107971258.json
that points to
https://myshopifystore.myshopify.com/admin/api/2021-01/orders/4371107971258.json
so anything after
/admin/api/2021-01/orders/4371107971258.json
can be a wildcard
and the below code doesnt do that my webpage just shows 404 Not Found
ProxyPassMatch "/shopify-api-$/" "https://$1.myshopify.com"
ProxyPassReverse "/shopify-api-$/" "https://$1.myshopify.com"
I am stuck in this problem for past few days, I am using reverse proxy of Apache server and I managed to run the reverse proxy by making the following changes in config file:
ProxyPass: /server-01/ server-01.{My server}
ProxyPassReverse: /server-01/ server-01.{My server}
ProxyPass: /server-02/ server-02.{My server}
ProxyPassReverse: /server-02/ server-02.{My server}
ProxyPass: /server-03/ server-03.{My server}
ProxyPassReverse: /server-03/ server-03.{My server}
ProxyPass: /server-04/ server-04.{My server}
ProxyPassReverse: /server-04/ server-04.{My server}
All this is working but I want to make this dynamic so that I dont have to add new code and restart Apache when a new proxy server is added!
In order to use a regex you must use ProxyPassMatch:
ProxyPassMatch ^/server-(\d+)/$ server-$1.{My server}
The purpose of ProxyPassReverse is to fix any Location headers that the proxy server issues for itself. For example if I proxy mywebsite.com to bluewebsite.com and bluewebsite.com issues a redirect to bluewebsite.com/1, ProxyPassReverse will intercept it and redirect me to mywebsite.com/1 instead.
If your proxy server issues redirects to the proper front-end URLs (or does not use redirects) then ProxyPassReverse is not needed. If you do need it, you are out of luck in this example because it does not accept regexes.
Here is another question that might help you:
ProxyPassMatch with ProxyPassReverse
I am working on a PCI project and I have been asked to not log any GET request on an Apache 2 server as long as there is a query string parameter present on the URL.
I have been trying to use SetEnvIf and SetEnvIfNoCase as noted below with no success at all, the requests keep getting logged on the access.log for apache.
I am at a lost here, so any help would be appreciated. by the way, I am not versed on Apache by any means.
SetEnvIfNocase Referer "^(SECRET=)$" dontlog
CustomLog /path/to/logs combined env=!dontlog
The anchors ^ and $ prevent the referrer from matching. Right now, you only match referrers that are exactly "SECRET=", and I doubt that's the idea. Remove the anchors and it should work.
I've setup Apache as a reverse proxy for a non public backend server, using mod_proxy. However one of my ProxyPassMatch directives always returns 404:
ProxyPassMatch ^/app/files/public/orders/06_production/jobs/([a-zA-Z0-9\-]+)/Preview%20PNG/(V[0-9]+)/([a-zA-Z0-9_\-]+.png)$ http://192.168.2.42/app/files/public/orders/06_production/jobs/$1/Preview%20PNG/$2/$3
This should match an incoming request like this:
/app/files/public/orders/06_production/jobs/P116087/Preview%20PNG/V1/bla.png
Any idea what's wrong with my Regex?
Figured it out:
ProxyPassMatch "\A/app/files/public/orders/06_production/jobs/([a-zA-Z0-9\-]+)/Preview PNG/(V[0-9]+)/([a-zA-Z0-9_\-]+.png)\z" "http://192.168.2.42/app/files/public/orders/06_production/jobs/$1/Preview PNG/$2/$3"
I have a django web application that's running on apache 2.2.14 and I want to run the admin application over https.
Having read considerable discussions on using a proxy, writing middleware, running alternative wsgi scripts, the chaps in #httpd came to my rescue. The solution is so simple, I was surprised I didn't find it online, so I'm curious to see if I've made some glaring assumptions or errors.
One complication was that I also wanted to run one of my django apps in the site over https, that is everything on /checkout.
Essentially, if a user requests a URI starting with /admin or /checkout on http, they are to be redirected to that URI but on https. Conversely, if a user requests a URI that does not start with /admin or /checkout on https, they are to be redirected to that URI but on http.
The key to solving this problem was to use Redirect and RedirectMatch directives in my VirtualHost configuration.
<VirtualHost *:80>
... host config stuff ...
Redirect /admin https://www.mywebsite.com/admin
Redirect /checkout https://www.mywebsite.com/checkout
</VirtualHost>
<VirtualHost *:443>
... ssl host config stuff ...
RedirectMatch ^(/(?!admin|checkout).*) http://www.mywebsite.com$1
</VirtualHost>
Another approach is to use #secure_required decorator. This will automatically rewrite the requested url and redirect to https://... version of the URL. Then you don't have to have Redirect in *:80 configuration. *:443 configuration may still be required for performance purpose if you want other traffic to go through normal http traffic.
I tried your solution, but ran into several problems. First, the formatting on the admin site disappeared, as if it could not find the admin static files. Second, if I tried to reach the non-admin site through https, the browser would not find it and redirect me to Yahoo search. Oddly, if I edited the yahoo search URL to eliminate all text except my correct URL (minus the http://), it would continue to search through yahoo for my site. However, typing the exact same URL afresh sent me to my site.
I solved all of these issues by simply removing the
RedirectMatch ^(/(?!admin|checkout).*) http://www.mywebsite.com$1
directive.
I should mention that I don't have a /checkout section on my site and am only trying to secure /admin. ... and yes, I did substitute my URL for "mywebsite.com"
What you described should work, but there may be a problem in the future if you need to make changes to which paths are/are not HTTPS. Because this method requires the ability to correctly modify the Apache config file it means you do not want novices in the loop. Screw up the config file and your site can go 500-error in the blink of an eye.
We chose to have a simple text file that had a list of the must-be-HTTPS paths. Anyone on the project can edit it and it is checked for correctness when it is loaded. We handle any needed redirects to/from HTTPS in middleware and it seems to work just fine. This method will also work if you are running anything other than Apache.