I'm using PrettyFaces in my project. We recently started using SSL (Https), however, when calling, for example pretty:main-page in a commandlink the https protocol is modified to http. If I used a normal call without pretty: the protocol is not modified.
The answer of PrettyFaces leader was:
"AFAIK there are basically two ways to work around this issue:
You could configure Glassfish to assume the https scheme for the http listeners. AFAIK there is a scheme property on the http listener in the latest Glassfish version. See this issue for details.
If you are using a load balances / reverse proxy, you could rewrite the Location header before sending it back to the requesting client. That should be easy but depends on you load balances setup. If you are using mod_proxy, you can use the ProxyPassReverse command to achieve this."
github.com/ocpsoft/rewrite/issues/257#issuecomment-355737351
OK!
Related
I've run into an issue where the post-login redirect in Flask-Security is not keeping to HTTPS and is instead making an HTTP request. In some instances this is causing an error.
Ideally my nginx config would redirect all requests on :80 to :443 automatically, but apparently this is problematic as well. While I sort out the nginx issue I would really like to force Flask Security to always use HTTPS.
My current var for this is just:
SECURITY_POST_LOGIN_VIEW = '/logged-in'
The documentation says an endpoint name can be used as well, but it does not say what the format for that is. Do you just provide the endpoint name or is it wrapped in a url_for()?
Is there a way to force Flask Security to always use HTTPS, either in this particular instance or as a whole?
I have the same issue before. In fact, because of this limitation. I started to use flask-jwt instead of flask-security. Here is the link to the project https://pythonhosted.org/Flask-JWT/
I don't have an answer about Flask-Security itself, but you can force all HTTP traffic to redirect to HTTPS with Google's Flask-Talisman. That will fix the problem no matter what library you're using.
An old but important questions. I spent too much time working through this but here goes:
The answer is that Flask's url_for() is returning a relative url such as '/logged-in'.
werkzeug by default (via its autocorrect_location_header = True Response option) creates a fully qualified URL.
Where does it get the scheme and server?
It gets it by calling wsgi.get_current_url() -
which for scheme uses: environ["wsgi.url_scheme”]
Assuming you are using uwsgi https://uwsgi-docs.readthedocs.io/en/latest/ - it seems to look at the variables
UWSGI_SCHEME and HTTP_X_FORWARDED_PROTO and if neither are set then look at the variable HTTPS, else set wsgi.url_scheme=“http”
Most examples of setting up uwsgi+python say to place this (and others) in your
uwsgi_params file that is included in your nginx config:
uwsgi_param HTTPS $https if_not_empty;
I believe that simply setting:
uwsgi_param UWSGI_SCHEME https;
in your nginx config would force flask to believe the request was https regardless.
I use AWS ALB which seems to set all the relevant X-FORWARDED-xxx headers so
things just work.
If you need to handle both http and https and your LB doesn’t set
the headers - then the werkzeug folks have an answer - https://werkzeug.palletsprojects.com/en/0.15.x/middleware/proxy_fix
Endpoint name is the name of the view function.
Basically, if your desired route is decorating the show_home function,
app.config['SECURITY_POST_LOGIN_VIEW'] = 'show_home'
#app.route('/your-route')
def show_home():
...
PS: I am not sure what was the situation when the question was posted, but I describe the situation for Flask-security-too==4.0
I am injecting some script tags in a website, with source such as http:localhost:3000/css/my-page-css.css . While its working on almost all sites, there's this particular website that is somehow sending all my http requests as https. How do I handle such a case?
I have configured an https server also on my nodejs app which listens to port 8443 and http listens to 3000. But, when I inject my script tags, they have src URLS which point to port 3000. So even if I have an https configured on my nodejs app, it won't work since it would be listening to a different port.
You are using HTTP Strict Transport Security (HSTS)
Using the securityheader.com website on your URL, or Chrome Developer tools we see the following HTTP Header is sent back by your site:
Strict-Transport-Security max-age=7889238
This HTTP Header will be configured in your webserver and is a way of your webserver telling the browser "For the next 7889238 seconds only use HTTPS on this domain. If someone tries to use HTTP (either by typing or by clicking on a link) then automatically switch HTTP to HTTPS before you send it on to the server."
This is a security feature as currently the default (if a scheme is not explicitly given) is HTTP. This allows website owners to switch the default and, even strong that that, prevents it being able to be switched back.
HSTS is set at a domain level and it is not possible to have it on for one port (e.g. 443) but not for another (e.g. 3000) - it's either on for that domain or off.
If you really want to use HTTP then you need to remove this header and remove the remembered value of this header from your browser. While chrome allows you to do this by typing chrome://net-internals/#hsts in the URL and using the delete option, the easiest way to do this is to change the max age from 7889238 to 0, and then load the website again. And then remove the header completely.
This can be especially annoying for sites like localhost where you proxy requests and inadvertently set it for that dummy host name. You should see if your node proxy server allows you to strip off that HTTP header. Some might say it would be better if browser makers ignored HSTS for localhost, however I think it would be better if developers just stopped fighting HTTPS and used that even for development environments using a self-signed certificate that is added to your local trust store. This was you can avoid problems like mixed content, and also use features that are HTTPS only (including Brotli, HTTP/2, Geo Location...etc.) while developing (though some browsers like Chrome still allow these on http://localhost).
Alternatively set up a local DNS alias for each of your dev sites and use that with or without HTTPS as appropriate for the site in question.
Confluence IIS Reverse Proxy Setup
I have set up a reverse proxy on IIS 7.5 for Atlassian Confluence according to instructions found in the internet.
I wanted to redirect all traffic to "docs.unimaze.com" to "localhost:8090" on the same server.
This is how I did it:
Installed URL Rewrite 2.0
Installed Application Request Routing 3.0
Set up a reverse proxy rule:
Match URL: Matches the pattern (.*) using regular expressions (ignore case)
Conditions: (none)
Server variables: (none)
Action: Rewrite with http://localhost:8090/{R:1} (append to query string and stop processing of subsequent rules.
The only other thing I had to in order to make everything work (from https://serverfault.com/questions/76013/iis6-vs-iis7-and-iis7-5-handling-urls-with-plus-sign-in-base-not-querystr) was to run this command on the server so that URL's with "plus signs" in the URL's would be allowed.
%windir%\system32\inetsrv\appcmd set config "WebSiteName"
-section:system.webServer/security/requestFiltering -allowDoubleEscaping:true
Problem with external redirects
Confluence itself, seems to work perfectly BUT when attempting to edit a module from an external application (LucidChart Diagrams it fails), because a redirection to the external application also is rewritten, e.g. an attempt is made to redirect to this URL:
http://docs.unimaze.com/documents/edit/4b157fd9-8e28-4d70-8587-0fdd0839fbca?callback=...
when the redirect should actually be to the external application, so it should remain untouched by the rewriting rule:
https://www.lucidchart.com/documents/edit/4b157fd9-8e28-4d70-8587-0fdd0839fbca?callback=...
Is there an easy way to solve this?
This here helped: appcmd.exe set config -section:system.webServer/proxy /reverseRewriteHostInResponseHeaders:"False" -commit:apphost
In UI, the setting corresponding to this action on the Application Request Routing in IIS on the server node (select „Server Proxy Settings“) should be unchecked.
However, this had the effect that the page can not be loaded in Internet Explorer 11 L
The page is shown, but with empty space where the diagram is and it tries loading something forever.
In Firefox and Chrome it works fine.
I have no idea why it "freezes" in IE 11. Will check from other machines to see if this is always happening or not.
The easiest way to handle this is to take advantage of IIS host headers and make the proxied site believe it is responding as www.example.com:80 rather than localhost:8080. It turns out the AAR reverse proxy has an equivalent of Apache's ProxyPerserveHost setting it just isn't very well documented nor exposed in the UI.
To enable this setting you will need to open an elevated shell and run:
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/proxy -preserveHostHeader:true
Then configure the target site to listen at 127.0.0.1:80 with the appropriate host header and then configure the proxy to proxy back to localhost with the request and it should line up.
I've got mod_pagespeed installed under apache2/php5-fpm and it's working fine on my domain that isn't using SSL (it's combining css and js no probs), however when I access the SSL version of the same site, it no longer works. I've tried setting the variable:
ModPagespeedFetchHttps enable
But it still is not working. The site is behind basic auth security, would this matter?
I can see in the response headers under the SSL version of the site that mod_pagespeed is there, but it's not working it's magic.
Does accessing resources require authentication? If so, then mod_pagespeed probably is not able to access them (it just does an http fetch for resources to rewrite).
Are the same resources available on http? If so, you're best bet might be MapOriginDomain:
ModPagespeedMapOriginDomain http://www.example.com/ https://www.example.com/
This will fetch all resources with HTTP even when the page is requested with HTTPS. So this would avoid the authentication issue.
See also, https://developers.google.com/speed/pagespeed/module/https_support for more help with various HTTPS issues.
In addition to the above answer, also make sure you have added the directory for the ModPagespeedSslCertFile in your config file.
Check "Configuring SSL Certificates" at
https://developers.google.com/speed/pagespeed/module/https_support
It is possible to do that, invisible to the users (without redirect) ?
I want to save the bandwidth
If you want to avoid a redirect, you will have to proxy the requests. One way to do that is using mod_proxy.
Note that you can combine mod_rewrite and mod_proxy.
As mod_rewrite's documentation describes:
'proxy|P' (force proxy)
This flag forces the substitution part to be internally sent as a proxy request and immediately (rewrite processing stops here) put through the proxy module. You must make sure that the substitution string is a valid URI (typically starting with http://hostname) which can be handled by the Apache proxy module. If not, you will get an error from the proxy module. Use this flag to achieve a more powerful implementation of the ProxyPass directive, to map remote content into the namespace of the local server.
Note: mod_proxy must be enabled in order to use this flag.
If you want to spare bandwidth, you need the client to do the actual transfer to your other host instead. To achieve this, you need to tell your client browser to change the url to load. This can only be done via redirect or similar mechanism afaik.
The mod_proxy option will make the data loaded by your server and then dispatched to your client, ending in twice bandwidth use compared to local storage (where you only send to the client).
What is the issue with redirection to the image only ?