I'm testing some client side magic with Nginx forward proxy and a few rewrites, and it works great. Now I want to also mock up JSONP responses. It requires replacing a callback name placeholder in a static JSONP file with a query parameter.
To illustrate, the jsonp.js file:
<CALLBACK>({ "json": [] })
The URL:
http://localhost:8080/jsonp.js?callback=myCustomCallback
I want to serve the file modified like that:
myCustomCallback({ "json": [] })
Is it possible with Nginx? Preferably, using the SSI module and not Perl or Lua.
Take a look at the http_sub_module
Something like this may work:
sub_filter '<CALLBACK>' $arg_callback;
Related
I'm working with Vue JS using the webpack template, and dev mode.
How can I have part of my server using the HTTPS protocol and other part using HTTP?
I know that to use HTTPS is just add "https: true" to the devServer variable of the file build/webpack.dev.conf.js . Example:
devServer: {
https: true,
// other variables...
}
But when I do that just the HTTPS requests are accepted, no HTTP anymore.
How can I work with both protocols? If it's not possible, is there a VueJS way to redirect an HTTP request to an HTTPS?
It doesn't look totally straightforward to configure multiple entry points on your webpack server. Your best bet is likely to reverse-proxy the http requests using whatever other webserver you have handy. IIS will do this for you, for example. Google "reverse proxy [name-of-your-webserver]" :-)
My configuration looks like this:
frontend
traefik.frontend.rule=Host:my.domain;PathPrefixStrip:/mypath/
traefik param
--entrypoints="Name:http Address::80 Redirect.EntryPoint:https Redirect.Regex:http://my.domain/(.*)$ Redirect.Replacement:https://my.domain/$1 Redirect.Permanent:true"
My goal is to redirect HTTP requests on a given path to its HTTPS endpoint. However, the path prefix removal seems to be happening before the "main" redirect.regex/replacement logic, which is breaking some requests. For example:
http://my.domain/mypath/v1/foo
Will become:
https://my.domain/v1/foo
While I expected it to be:
https://my.domain/mypath/v1/foo
Anyway to workaround this issue?
Please note that regex and replacement do not have to be set in the redirect structure if an entrypoint is defined for the redirection (they will not be used in this case).
https://docs.traefik.io/v1.5/configuration/entrypoints/#redirect-http-to-https
Note also that Redirect.Permanent:true come in 1.6
Try something like that:
--entrypoints="Name:http Address::80 Redirect.Regex:http://my.domain/(.*)$ Redirect.Replacement:https://my.domain/mypath/$1 Redirect.Permanent:true"
I'm trying to get force_ssl working. I mean I want to redirect someone trying to connect via http to https with the app itself.
The app is a dockerized released version behind Nginx. Actually Nginx is serving the SSL and I know that I can totally rely on Nginx to terminate the ssl connection and even taking care of the redirection of non https requests. But I want to understand how to make it work so if someday I skip the proxy I'll know how to do it.
My prod/config looks like that:
config :my_app, MyApp.Endpoint,
http: [port: "${PORT}"],
url: [host: "${APP_URL}", port: "${APP_PORT}"],
force_ssl: [hsts: true], #I tried different options without success
server: true,
cache_static_manifest: "priv/static/manifest.json",
root: ".",
version: Mix.Project.config[:version]
Actually when accessing the server via https everything runs as expected. But when using http address, the redirect url looks like: https://%24%7Bapp_url%7D/ and it didn't work.
Maybe this happens because I didn't give a cert file and the whole process cannot be done without it? I was thinking that force_ssl is just a basic redirection if the request isn't https.
Finally I'm also trying to generate https url for instance in a mailer I've got something like this:
<%= password_url(MyApp.Endpoint, :reset_password_from_email, token: #token, email: #email) %>
But since my configuration seems not good it only generate http links not https.
Maybe should I separate this completely, making this 100% on Nginx side or 100% on the app side but not trying to mix them both?
Any help/idea/comment is welcome!
EDIT:
Last test with this:
force_ssl: [rewrite_on: [:x_forwarded_proto], subdomains: true, hsts: true, host: "${APP_URL}"]
result with the bad url: https://%24%7Bapp_url%7D/. So I think this is working but the var: "${APP_URL}"isn't converted to the real value. I'm digging on this.
By hardcoding the host: "${APP_URL}" value resolves the problem as suspected in my last edit.
There's something wrong here because all other ENV_VAR are replaced by their values but not this one.
I've managed to extend TokenAuthentication and I have a working model when using the request session to store my tokens, however when I attempt to pass Authorization as a header parameter as described here, I noticed that my Responses come back without the META variable HTTP_AUTHORIZATION. I also noticed that if I pass "Authorization2" as a header parameter that it is visible in the request:
{
'_content_type': '',
'accepted_media_type': 'application/json',
'_request': <WSGIRequest
path:/api/test_auth/,
GET:<QueryDict: {}>,
POST:<QueryDict: {}>,
COOKIES:{
'MOD_AUTH_CAS_S': 'ba90237b5b6a15017f8ca1d5ef0b95c1',
'csrftoken': 'VswgfoOGHQmbWpCXksGUycj94XlwBwMh',
'sessionid': 'de1f3a8eee48730dd34f6b4d41caa210'
},
META:{
'DOCUMENT_ROOT': '/etc/apache2/htdocs',
'GATEWAY_INTERFACE': 'CGI/1.1',
'HTTPS': '1',
'HTTP_ACCEPT': '*/*',
'HTTP_ACCEPT_CHARSET': 'ISO-8859-1,utf-8;q=0.7,*;q=0.3',
'HTTP_ACCEPT_ENCODING': 'gzip,deflate,sdch',
'HTTP_ACCEPT_LANGUAGE': 'en-US,en;q=0.8',
'HTTP_AUTHORIZATION2': 'Token 9944b09199c62bcf9418ad846dd0e4bbdfc6ee4c',
...
My first guess is that the authorization header is being removed by apache, and I have read a few S/O questions that state that apache will throw out the value if it does not match basic authorization and authenticate, but I have no idea how to allow the Authorization header to 'pass through' to Django and the WSGIRequest. Does anyone know how to solve this problem?
I also use mod_auth_cas and mod_proxy, if that changes anything..
If you are using Apache and mod_wsgi, then I found the easy solution to this in the official Django REST framework website
Apache mod_wsgi specific configuration
Note that if deploying to Apache using mod_wsgi, the authorization header is not passed through to a WSGI application by default, as it is assumed that authentication will be handled by Apache, rather than at an application level.
If you are deploying to Apache, and using any non-session based authentication, you will need to explicitly configure mod_wsgi to pass the required headers through to the application. This can be done by specifying the WSGIPassAuthorization directive in the appropriate context and setting it to 'On'.
# this can go in either server config, virtual host, directory or .htaccess
WSGIPassAuthorization On
Sorry to answer my own question minutes after asking it. But it turns out it was apache2 after all! After crawling the webs and looking through a few search results I found this in a comment:
RewriteEngine on
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]
Adding the above lines to my conf file seemed to solve all of my problems! Hopefully this helps users down the road!
It depends on which kind of Django/Apache deployment you did. You need to tell the correct Apache module to allow to pass "Authentication" HTTP header:
Apache/mod_wsgi:
WSGIPassAuthorization On
Apache/mod_fcgid:
FcgidPassHeader Authorization
In other words: many Apache modules filters "Authentication" HTTP header, so Django will not receive it. You have to be sure your Django App is receiving it in request.
See:
django_rest doc and Apache fcgid doc.
NOTE:
After modifying Apache configuration you'll need to restart apache daemon or tell to reload your .cgi file (i.e: touch my_site_fcgifile.fcgi).
The issue is the underscore in the HTTP header HTTP_AUTHORIZATION. Most webservers just ignores the headers with underscores.
Django dev server also exhibits the same, omitting headers with underscores.
This is the reason why Authorization2 works.
A Quick work around is to replace _ underscores in headers with - dashes,
Ex. changing the HTTP_AUTHORIZATION to HTTP-AUTHORIZATION
I am running freeNAS7 / lighttpd with some perl scripts that run on various ports localhost:5000, or localhost:8080 for example.
Now i tried to add cross-domian policy to the header but i cant get it to work, because most likley I am doing it incorrectly.I am not familiar with perl, if it were PHP then its pretty easy adding a header.(in terms of me understaning where to put it)
I was just thinking is there a way to rewrite for example something like
localhost/sabnzdb to display localhost:8080/ so that i can use client side to manipulate the iframe.
In lighttpd it's possible through mod_redirect. You can read about it here.
url.redirect = ( "^/sabnzdb$" => "http://localhost:8080" )
and put that in your localhost vhost (if you use vhosts) otherwise any place in your config should be ok.