When I run docfx docfx.json --serve and go to localhost:8080, I see two items on the top menu: "Articles" and "Api Documentation". When I navigate in the filesystem to _site\ and click on index.html to open it in Chrome, these menu items are missing. How can I make sure the menu is properly set when I run it as a static site?
I need to be able to package the html files and send them to people for them to view locally without them having to download the repo and install docFX.
Reason: The page needs extra JS files to the navigation bar, but it is blocked by Chrome. You can see these errors in Chrome console (F12):
docfx.vendor.js:4 Access to XMLHttpRequest at 'file:///C:/git/docfx-seed/_site/toc.html' from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https.
send # docfx.vendor.js:4
docfx.vendor.js:4 Access to XMLHttpRequest at 'file:///C:/git/docfx-seed/_site/logo.svg' from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https.
Solution: Use template statictoc, which already embedded all the required parts into HTML file:
docfx docfx.json -t statictoc
Related
I've got a JavaScript bookmarklet that prompts for a bookmark name, then using XMLHttpRequest, POSTs the name and current page URL to a Java servlet running in Tomcat on localhost. The servlet stores the name and URL in a DB. This works fine for most webpages, but fails if the page that's currently loaded has added Content Security Policy "connect-src" restrictions.
Here's the error: Refused to connect to 'http://localhost:8080/MyServlet' because it violates the following Content Security Policy directive: "connect-src 'self'
I obviously don't want to disable CSP completely. And since I won't know if I want to bookmark the page until it's fully loaded, anything that tinkers with CSP in the response headers or meta tags is doing the work too soon.
Is there some way I can tell the browser to ignore the "connect-src" restriction for just my localhost case, or disable/enable it on either side of my XMLHttpRequest POST?
I'm in Chrome "90.0.4430.72 (Official Build) (64-bit)".
The website https://www.example.com with header content-security-policy: frame-ancestors 'self'; is unable to open with <iframe>
This website contain a shareable url like https://www.example.com/#/shareablelink which should be allowed to open in <iframe> but as header content-security-policy: frame-ancestors 'self'; also applied to this page, it is not working as expected.
Is there any way do so?
Its frontend is build on angular 5+
HTTP headers publish on the backend (server), so only the site owner can change those.
Link (https://www.example.com/#/shareablelink) with hash # works tricky:
part before # is served by server - be sends to server on click and will get reply from server (if you do not handle onClick by script in browser)
part after # is served locally in browser (by script or by built-in browser navigation) and never be sent to server
Therefore CSP HTTP header on the page https://www.example.com/#/shareablelink always will be the same as on https://www.example.com/. The part #/shareablelink normally is a scroll to '/shareablelink' anchor, or could be handled by javascript for any purposes (even send XMLHttpRequest to server, get response and change the page's content but not the HTTP header)
I have two web pages hosted on a.example.com and b.example. Each web page is including a script with a <script> tag, hosted on another domain and served with correct CORS headers.
At a certain point, user navigates from a.example.com to b.example.com.
Safari has here a strange behavior: the referrer and origin headers in preflight request are filled with a.example.com, making the server sending a bad value in Access-Control-Allow-Origin (and so the script can't be executed).
Is there a way to force Safari browser to send correct origin header in that kind of scenario ?
Does the cache policy for the script include Vary: Origin?
Respectively is there actually a second request after navigating to b.example.com?
If not, there is a chance that Safari is actually serving the script from cache - despite the Access-Control-Allow-Origin policy forbidding it to access the resource. Which is a conforming behavior, if the cache policy isn't configured correctly.
It seemed to be indeed a Safari bug.
The issue is not reproductible on Safari 10.0. It repro only on Safari 9.1.1 / 9.1.3.
I have mixed content in my https website, but once I have http conent like external link to outside, the browser will warning "this is not a trusted site"
As the links of http cannot be removed, how can I walk around this issue?
Thanks for any suggestion.
You can have links to http content. The most common thing when this happens is that you have src attributes with http in them. If you're for instance getting jquery code from an API, try switching to https.
The web-site has ssl certificate.
Any http page is redirected to the same, but https page (if not https) by .htaccess.
Everything works fine, but 404.shtml gets a security warning "This webpage contains content that will not be delivered using a secure HTTPS connection..." in IE. The same behavior is in any other browser.
How to exclude that error?
404.shtml web-page was created using web-hosting control panel wizard. The file 404.shtml was created automatically.
Most likely the automatically generated file includes links, images or other resources fetched via http. If you can change them to https links, you should avoid the problem. There's afaik no other way to make the browser not warn about this, at least in a cross browser way.