I'm trying to setup Traefik to replace my Nginx reverse proxy setup.
I have my domain setup like this:
- I can access different services using http://example.com and detecting which service I should proxy to, by using subpath.
I tried to recreate same setup with Traefik. First by using ReplacePathRegex and then StripPrefix. My api requests work fine, but when I try to use Portainer, requests made from web browser omit /portainer part which causes web ui to break.
For example:
I make request to http://example.com/portainer.
I get response and then consecutive requests should be made like this: http://example.com/portainer/vendor1.css
and instead it makes request like this:
http://example.com/vendor1.css
Is there any way to setup Traefik behavior to exactly match Nginx proxy_pass?
I found this post that gives me a partial solution: Is there an equivalent to ReverseProxyPass for Apache in Traefik?. Portainer seems to be working when I make request to http://example.com/portainer/ by adding "/" to the end.
I tried to fix it with forceSlash, but it did not make any change
Is it possible to make it work with or without trailing "/"?
This is how requests look like in /portainer and /portainer/:
This is my current Traefik configuration (I'm only using Docker):
Stripprefix middleware is for removing prefixes from the path before forwarding the request. According to your configuration, everything after /portainer and /portainer itself will be stripped.
In your case, it will also remove the trailing slash. If you need to forward / to the Portainer, then you need to use portainer (without slash) as to configure the prefix of stripprefix middleware.
I found a solution: https://community.containo.us/t/middleware-to-add-the-if-needed/1895
This is what I had to add to labels in my portainer container to make it work:
- traefik.http.middlewares.strip-prefix.chain.middlewares=strip-prefix-1,strip-prefix-2
- traefik.http.middlewares.strip-prefix-1.redirectregex.regex=^(https?://[^/]+/[a-z0-9_]+)$$
- traefik.http.middlewares.strip-prefix-1.redirectregex.replacement=$${1}/
- traefik.http.middlewares.strip-prefix-1.redirectregex.permanent=true
- traefik.http.middlewares.strip-prefix-2.stripprefixregex.regex=/[a-z0-9_]+
It is not ideal solution as I think there should be an easier way to achieve it, but for the time being it satisfies my needs.
Related
If Nginx works as reverse proxy between Apache and the web, where should i add X-Robots-Tag (to add some additional headers) - in the htaccess of Apache or in the Nginx configuration file?
You can do it in either place. Although, for a header like X-Robots-Tag, which is very much page specific then it would probably be easier to set this at the application server (in your application/CMS). Devs may not have access to the proxy server in order to apply specific headers.
Alternatively, you might choose to do this in the front-end proxy if you wanted to apply this to every request, or to a specific pattern.
But you should not apply the same header in both places, as that becomes hard to maintain (and debug).
I'm trying to use Charles to map requests for my server to localhost on my Mac.
The server is on HTTPS and the local is HTTP.
I'm trying that from the Chrome browser, iOS simulator and Postman.
it always fails.
I set map remote in charles from my-server.com/* to http://localhost:PORT.
If I try https://my-server.com/, charles maps the request but I get error in CONNECT request.
If I try http://my-server.com, the request succeeds.
EDIT:
There is an answer that suggests rewrite instead of map remote. it is good and working, but it feels to me as a workaround. I would like to use map remote as usual. I guess it require both Charles setup and machine setup
You should try using the Rewrite function like this:
As #kubano suggested, I'm using REWRITE tool with URL rewrite.
In order to map all subpaths, I'm using regex group to replace the hostname but re-attach all that comes after '.com'.
When wrapping something with () it is referred as 'group' and you can use it with $1 $2 ... and so on. in this case, what ever comes after '.com' is referred as $1 in the replace section
I suggest using Map Remote from Proxyman to map between HTTP <-> HTTPS which is easier to setup.
Just create a rule, set HTTPS to HTTP, and the host. It will map from https://your-server.com to http://localhost:3000
Doc: https://docs.proxyman.io/advanced-features/map-remote
Disclaimer: I'm the creator of Proxyman and hopefully it would help you.
In case somebody comes here to search for how to map local (file) from an https location (which did not work for me out of the box):
Similar to the rewrite rule (in Charles 4 at least) it works with map remote, mapping https to an http location (e.g localhost) and then mapping that (localhost) url to a file
I have configured Jboss7 on Openshift yesterday. All I need to have an internal rewrite rule to have /members.html -> members.jsp.
This requires user to see members.html while the actual file(members.jsp) is served by Jboss itself.
Dont know correctly how to setup mod_jk if required but surely I would like this thing to work anyways as I have urls submitted in google and shifting site on openshift should not require me to change the URLs.
I don't think you have access to the Apache configuration on the server. You would need root permissions for that. Have you considered an alternative approach via a web application filter. There is UrlRewriteFilter - http://tuckey.org/urlrewrite/ - which might solve your problem.
I'm trying to use Liferay for http and https
if I include in portal-ext.properties:
company.security.auth.requires.https=true
web.server.protocol=https
Will be working ok with https but in http is showing incorrect themes due is trying to load https://domain.com/theme
If I remove this two lines is working ok for http but not for https.
What can I do?
IMHO mixed mode, e.g. offering http as well as https never gives you what you expect: You expect security from https, but you always risk leaking session information, e.g. being vulnerable to session-hijacking attacks (ala Firesheep). My actual advice would be to go https only if you do https for security. Read on if that's not an option for you, but don't complain when you find information leaking (this is not dependent on Liferay, but for any web-based environment)
What is the exact problem that you have with the themes? (images/css through http?) Which version of Liferay are you using?
Before you specify more, you might want to configure your theme's "virtual path", this will rewrite all the URLs referring to your theme. It's typically used to serve static resources through a webserver or cdn, but it works with any kind of URL. Simply using a protocol-relative URL should work (I love this mostly unknown http feature):
Add this to your theme's liferay-look-and-feel.xml:
<look-and-feel>
<theme id="my" name="My Theme">
<virtual-path>//domain.com/myTheme</virtual-path>
</theme>
</look-and-feel>
note that the URL omits the protocol part, http: or https:, thus the browser will use the same protocol that the whole page is loaded with.
Edit: corrected the xml. Will investigate if there's a problem with protocol-relative URLs in themes.
Edit 2: Something is weird. It seems, virtual-path does not work like this, but I recall it did earlier. Do you add domain.com as cdn.host.http or cdn.host.https? (this would be concatenated)
On related stuff, please check if you're running Apache in front of your appserver. In this case you might forward some traffic for the portal (e.g. in the virtual host for http) but not forward the traffic in the https virtual host.
I have purchased an ssl certificate, I have enabled the SSL setting in the settings and I have changed both config files to go to https but when I visit http://bit.ly/TCkEBv the first page is https the rest are not. How can I fix this?
I realize this is an old thread but considering the recent google SSL-everywhere indexing changes, i figured it was relevant. The following example will make OC use https in all links. You have to change 3 characters in system/library/url.php. They deleted this on the forums which is understandable, but we have ran it for a week of production traffic on mixed SSL multistores with no issues.
WARNING: Your mods may be different - run through them all in a test after enabling this...especially any redirect managers. Here is the tweak for 1.5.6:
Open store/system/library/url.php and find $url = $this->url; in an IF statement somewhere near line 18. Change it to $url = $this->ssl; and there ya go.
PS: Also there is a vastly untested method to send the https-preferred as a header using $response->addHeader('Strict-Transport-Security: max-age=31536000'); but i am unsure of best spot to put it besides index.php. Also, although it works in test, unsure of all-server implications. Header controller seems logical, but not all OC areas use header controller :). Experiment with best placement for that....just dont do it in the $url replicator even if it seems like it works.
As per the forum thread, this is not actually a bug just the way that the cart is set up - that is most pages are not set as HTTPS and will revert to HTTP once you click on a non HTTPS link
Let's say you have a Domain called example.org
Instead of changing the code, in Apache, you could do this...
In addition to your Domain-SSL.conf, you can copy that configuration to Domain.conf and edit it to use port 80 instead of 443
Then, add this line in the Server definitions at the top, right before DirectoryIndex...
Redirect / https://example.org
This will simply redirect every request back to the SSL configuration, adding the https:// in front of every link. No code changes required to OC.
This has been working on my busy production server for several years without a single problem.