I just started to learn Cordova. I created a project according to this url.This project runs OK in the Ripple emulator.But when I try to run it in Google Android Emulator.It can not get weather,and display the following information:
Refused to connect to 'https://query.yahooapis.com/v1/public/yql?q=select+*+from+weather.forecast+where+location=98052&format=json' because it violates the following Content Security Policy directive: "default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'". Note that 'connect-src' was not explicitly set, so 'default-src' is used as a fallback.
jquery-2.1.4.min.js (4,14349)
Should I do something else to make this project run normal in Google Android Emulator.
Check this:
http://content-security-policy.com/#source_list
fix:
in sorce app directory:
www\index.html
in
https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; media-src *">
i change 'self' by '*'
content="default-src *
Related
I have a shiny application running with shiny-proxy and I want to embed this application within another hub application.
I configured the application.yml in shiny-proxy to:
frame-options: allow-from http://127.0.0.1:5501
Content-Security-Policy: frame-ancestors 'self' http://127.0.0.1:5501
The allow from directive is deprecated in chrome and safari and therefore, I used it, as suggested by many StackOverflow answers, I used the Content-Security-Policy option. However, this has not resolved the issue yet.
Chrome is still blocking it:
proxy:
default-webSocket-reconnection-mode: Auto
same-site-cookie: None
# stop-proxies-on-shutdown: false
# recover-running-proxies: true
# recover-running-proxies-from-different-config: true
title: Open Analytics Shiny Proxy
logo-url: https://www.openanalytics.eu/shinyproxy/logo.png
landing-page: /
heartbeat-rate: 10000
heartbeat-timeout: -1
heartbeat-enabled: false
container-wait-time: 20000
servlet.session.timeout: 100000
container-log-path: /var/log/shinyproxy/container-logs
port: 8080
authentication: simple
admin-groups: admin
users:
- name: frank
password: password
groups: scientists
# Docker configuration
# container-backend: docker
container-backend: docker
docker:
cert-path: /home/none
url: http://127.0.0.1:2375
port-range-start: 20000
specs:
- id: something
...
logging:
file:
name: /var/log/shinyproxy/shinyproxy.log
# level:
# root: DEBUG
server:
frame-options: allow-from http://127.0.0.1:5501
Content-Security-Policy: frame-ancestors 'self' http://127.0.0.1:5501
secure-cookies: true
Making everything HTTPS solved it.
I am busy creating a Google chrome extension, and under the new rules of manifest V.3, you are no longer allowed to run any remote script and this gets blocked by the Content Security Policy (CSP).
Firebase Realtime Database has two ways of communicating. Websockets being the primary, and long polling being the fallback or secondary.
The way it usually works is that if a Websockets connection fails, it reverts to long-polling, if long polling is successful it goes back to Websockets. But if your CSP is blocking the long poll, I am then stuck and the app can never connect again.
Refused to load the script '<URL>' because it violates the following Content Security Policy directive: "script-src 'self'". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.
2.b786d402.chunk.js:2 Refused to load the script 'https://xxxx-default-rtdb.europe-west1.firebasedatabase.app/.lp?start=t&ser=75721928&cb=1&v=5&p=1:592645519845:web:db72abd212b7364c72170c&ns=tonews-default-rtdb' because it violates the following Content Security Policy directive: "script-src 'self'". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.
I can revert this by removing the extension and re-installing it.
I have found some posts online, where its mentioned I could just change my configuration.
The solution recommends just changing 'databaseURL' field in the firebase config to start with wss:// instead of https://...
This works, for about a week or so, but thereafter I get stuck in CSP prison again..or does it? Hard to tell since reinstalling the extension solves the problem anyway, and is required to apply the new changes..
"firebase": "^9.6.1",
"name": "xxxx",
"description": "xxxxxxxxxxx",
"version": "1.0",
"manifest_version": 3,
"action": {
"default_popup": "index.html",
"default_title": "Open the popup"
},
"chrome_url_overrides": {
"newtab": "index.html"
},
"content_security_policy": {
"extension_pages": "script-src 'self'; object-src 'self'",
"sandbox": "sandbox allow-scripts; script-src 'self' 'https://apis.google.com/' 'https://www.gstatic.com/' 'https://*.firebaseio.com' 'https://*.firebasedatabase.app' 'https://www.googleapis.com' 'https://ajax.googleapis.com'; object-src 'self'"
},
"icons": {
"16": "favicon-16x16.png",
"48": "favicon-32x32.png",
"128": "android-chrome-192x192.png"
}
}
I'm honestly stuck and very frustrated because even if I do find a fix, it's hard to verify it..
Background
We're hosting a proprietary web application, which we like to customize rudimentary to our CD (mainly colors). Since the application doesn't support this and I don't have access to the source, I'd like to create a custom css stylesheet and include it in the app by manipulating it's ingress (= injecting css/stylesheets into the DOM).
http_sub_module of the Nginx Ingress Controller for Kubernetes
The http_sub_module seems similar to Apaches mod_substitute. When I exec nginx -V inside the nginx ingress pod, there is --with-http_sub_module listed in the configure arguments, so it must be avaliable in the currently deployed 1.19.2 version.
I found a similar question using subs_filter (instead of sub_filter). It seems that the one with s is from nginx plus, also documented here. All linked examples there use subs_, where the regular community documentation uses sub_filter. Both of them worked without an error, I guess the plus one is an alias if no plus subscription is avaliable.
Since sub_filter doesn't seem to work, I tried both of them without success:
annotations:
kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/rewrite-target: /
nginx.ingress.kubernetes.io/configuration-snippet: |
#subs_filter_once on;
#subs_filter_types 'text/html';
# subs_filter 'en' 'de';
# subs_filter '</body>' '<h1>TEST</h1></body>';
sub_filter '</body>' '<h1>TEST</h1></body>';
Further things I've checked/tried
The configuration snippet is applied. I looked into the nginx ingress pod, the server vhost block for my application has the sub_filter/subs_filter directive inside the / location block.
The default type for filtering is sub_filter_types text/html. The website returns Content-Type: text/html so it should match. To be sure, I also set sub_filter_types "text/html"; in the snippet. And even * which matches any mime type according to the docs, both without any difference.
Doesn't this module work with mod_proxy used by k8s? I can't imagine that since the module is relatively old and I see no reason why it shouldn't work when nginx acts as reverse proxy, since it needs to have access to the HTML header/body too.
Found out that the problem was something completely different: The application supports gzip, so this compression was enabled. But the http_sub_module doesn't support gzip, as documented here. It only works with plain text reasponses. If the response is compressed, the module just do nothing. This explains why it doesn't work and there was no error.
Luckily, the compression could be easily disabled without any modifications on the application by setting the following header:
proxy_set_header Accept-Encoding "";
If this is added to the nginx.ingress.kubernetes.io/configuration-snippet section, it accepts only plain text and every application which is compilant to the specification will respect that.
But it doesn't mean that we can't use any compression. The Gzip filter can be used from the ingress to the user, it's only not supported from the ingress to the application.
Full working example annotation snippet
ingres:
# ...
annotations:
kubernetes.io/ingress.class: "nginx"
# http://nginx.org/en/docs/http/ngx_http_sub_module.html
nginx.ingress.kubernetes.io/configuration-snippet: |
sub_filter "</body>" "<style>body{ color: red !important; }</style></body>";
# The http_sub_module doesn't support compression from the ingress to the backend application
proxy_set_header Accept-Encoding "";
This would apply the style block before the closing body tag like this:
<style>body{ color: red !important; }</style></body></html>
For productive usage, we can include a link to a custom css file here, which overrides the applications design to our needs.
I want to use an iframe in my localhost web server (wamp).
This iframe loads a form from a remote web server.
I have access to the remote web server, it uses apache2 (https://help.ubuntu.com/lts/serverguide/httpd.html), and i modify its security.conf file and i load the module 'headers'.
I modify security.conf by this line (the ip is the ip of my local computer):
Header append X-Frame-Options "ALLOW-FROM http://localhost, http://172.18.48.120, 172.18.48.120"
But when i test the changes, always says the same:
Refused to display 'http://externalURL.net/form.php' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
Any idea? Where's the problem?
Just for completeness:
Here are the lines to add to your apache2/conf-available/security.conf file to make your iframed content available in browsers supporting either or both X-Frame-Options and Content-Security-Policy header options (as stated on this survey site)
Header set X-Frame-Options: "ALLOW_FROM https://www.example.com"
Header set Content-Security-Policy: "frame-ancestors
https://www.example.com"
Make sure that header module is enabled
a2enmod headers
restart apache
service apache2 restart
That's it !
Finally i solved it, the solution is:
Load module headers in apache2.
Modify file security.conf, you have to append this line:
Header set X-Frame-Options 'ALLOW-FROM http://externalURL.net'
(it's a valid option if you use a local web server, e.g. wamp:
Header set X-Frame-Options 'ALLOW-FROM http://localhost')
Reload service apache2.
If you want to test it, don't use Google Chrome, it ignores x-frame-options directive and it always says the same message:
Refused to display 'http://externalURL.net/form.php' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
It's ok with Firefox.
Can I embed JupyterLab into a website? Currently it throws frame-ancestors self error. Is it possible to change some configuration to allow embedding this in an iframe?
Yes. The default setup of both JupyterHub and single-user Jupyter Notebook/Lab server is configured to prohibit outside domains from embedding the page. As a workaround, you can include your domain in the frame-ancestors directive:
jupyterhub_config.py:
c.JupyterHub.tornado_settings = {
'headers': {
'Content-Security-Policy':
"frame-ancestors 'self' http://yourdomain.com"
}
}
jupyter_notebook_config.py:
c.NotebookApp.tornado_settings = {
'headers': {
'Content-Security-Policy':
"frame-ancestors 'self' http://yourdomain.com"
}
}
If you are using a Kubernetes-based setup for the deployment, the configuration is slightly different and involves writing/building a Dockerfile of the single-user server with these configurations. You can check out my GitHub repo that I created a while back that will walk you through these steps.