How do I add an Onion-Location header to all my pages in Caddy2 the value of which is $string+request_path
Onion-Location is an easy way to advertise an onion site to the users. You can either configure a web server to show an Onion-Location Header or add an HTML meta attribute in the website.
— Tor Project
The example Nginx configuration shows:
add_header Onion-Location http://<your-onion-address>.onion$request_uri;
I think they meant path, rather than full URI.
Like this:
header Onion-Location http://whatevercrypticname.onion{path}
If you have the $TOR_HOSTNAME saved as an environment variable then use
header Onion-Location http://{$TOR_HOSTNAME}{path}
Related
Hello I am trying to display a part of an website in an iFrame. For example: IP 1.1.1.1 wants to iframe 1.1.1.2.
In apache2 security.conf it is set to:
Header set X-Frame-Options: "sameorigin"
I tried a lot of different forms of ALLOW FROM but nothing worked. I guess those solutions are outdated.
header module from apache 2 is enabled.
Is there any workaround on that? It is really a simple displaying which costs way too much time :D
Tyvm for any hints!
ALLOWFROM is not supported in most browsers. Instead you should set Content-Security-Policy with "frame-ancestors 'self' ", where would be the other host or ip that should be able to frame. You could add multiple sources if you like, not like X-Frame-Options which is limited to one source.
I currently have a web app running in containers with the access-control-allow-origin header correctly configured on it. However, when I check the front door in front of this web app, the same header has the option '*' -- accepting all types of requests, differently from the configured one.
How do I get the front door to propagate this web app header?
Here is the official document about this: Azure Front Door Rule Set
On Azure Front Door, you can create a rule in the Azure Front Door
Rules Set to check the Origin header on the request. If it's a valid
origin, your rule will set the Access-Control-Allow-Origin header with
the correct value. In this case, the Access-Control-Allow-Origin
header from the file's origin server is ignored and the AFD's rules
engine completely manages the allowed CORS origins.
Doris lv's previous answer is correct but I would also like to point out some things:
Be careful not to add the slash (/) at the end of the URL -- I had that added that's why didn't work:
After creating the rule, go to Front Door designer (FDD) and link this new rule with some of the routing rules available
Also in FDD, click on the Purge button clean the previous cache and load the new configurations
Another important thing is that I had to do this configuration due to HDCL AppScan saying that the Access-Control-Allow-Origin header was too permissive; that being said, the scan pointed that the Java Scripts files had this problem which they didn't, only the CSS and TFF files had this header. A closer look at the scan report pointed out that what's was going on is that the Vary header had the value Origin in it, making the scan report a Cross-Origin Resource Sharing (CORS) issue. To fix this just add a new rule in the Rule engine configuration removing this header just like shown:
After this, the scan didn't report any more issues
I want to block my site in the <iframe> tag. On research I found that to do so, I need to set the header as 'x-frame-options' to 'SAMEORIGIN'.
Tried setting the meta tag as
<meta http-equiv="X-Frame-Options" content="deny">
But this method is outdated since April 2016.
When I am trying to search it is giving me the result for httpClient.
But I want the same when Someone hit my url through .
Do I need to set the header through node or need to do some changes in angular.json
My site is working on node server with URL http://localhost:4200/.
You cannot do it on angular side, only on server side.
I think you can use this npm package:
https://www.npmjs.com/package/x-frame-options
If you are using any webserver like Nginx, Apache HTTP Server
example for how to use in Nginx
add_header X-Frame-Options "SAMEORIGIN";
in global scope, or location scope.
Better to do in location scope. Because, as soon as you add some header in location scope, the global scope will not reflect
Additional
You can take care of more things using the header like cross-site scripting
add_header X-XSS-Protection "1; mode=block";
Even though nowadays browsers are helping to reduce cross-site scripting. More detail description in here
Suppose I have a web application at origin.com. When I browse origin.com it request cross-site data from datafeed.origin.com. I have following written in .htaccess of datafeed.origin.com Header set Access-Control-Allow-Origin origin.com. Everything works perfectly till this point.
What I need is protect datafeed.origin.com. How can I prevent this domain from browsing directly from browser or any other application. Only allow access when cross referencing from origin.com.
You can specify the origin when setting the Access-Control-Allow-Origin header:
Access-Control-Allow-Origin: <origin>[, <origin>]*
Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin
Looking at your post it looks like you've done this, so cross origin requests should fail from other domains
I'm trying to set up my IIS server as an origin server for a CDN. I have solved some issues already for example that IIS doesn't give gziped content to proxies (if they have the via header) and also that frequentHitThreshold problem.
My CDN supplier pointed out that another problem with IIS is that it doesn't return a "Vary" header if the client doesn't request the content gziped. According to them the problem is that if for some reason the first client that request the content doesn't want the content gziped the CDN then doesn't request a new version of the file since the Vary header doesn't indicate that it should return two different files depending on "Accept-Encoding".
My only solution so far is to add "Vary: Accept-Encoding" as a custom header but since IIS automatically add this vary header when gziped is requested so i end up with multiple values like "Vary: Accept-Encoding, Accept-Encoding".
Anyone have any solution to this? Or can confirm that it's a real issue.
This is a real issue. IIS gzip module overwrites existing Vary headers. Please vote on this MS Connect issue. Related article here.
This issue is now addressed by an official patch to IIS. To download and further info, visit http://support.microsoft.com/kb/2877816
Erez Benari, IIS PM