I have several Flare projects, many of which I inherited from other writers.
When I upgraded to 2024, I noticed some outputs had changed with text that is no longer centered on the web page.
Previously the output looked like this.
Not every project did this, and I found that this was the key. If "Add content to head:" was checked on the Advanced tab of my HTML project some of the text was no longer centered. The text in the box was
<meta http-equiv="Content-Security-Policy" content="default-src 'self'" />
I'm not sure why a previous writer would have checked the box. That's the only reason I haven't created a bug yet. If I remove the check, then my output looks correct.
Flare 2024 issue?
Flare 2024 issue?
You do not have the required permissions to view the files attached to this post.
Re: Flare 2024 issue?
The meta tag is setting a security policy for the page, and it looks like it's restricting the page from loading content from other locations outside of 'self' (the current location).
See: https://developer.mozilla.org/en-US/doc ... ity-Policy
So maybe check the browser Console to see if there are any errors saying it can't load resources.
See: https://developer.mozilla.org/en-US/doc ... ity-Policy
So maybe check the browser Console to see if there are any errors saying it can't load resources.
Re: Flare 2024 issue?
It appears that any inline formatting is broken with this change from 2023 to 2024 due to changes in content security.
Unfortunately I have to rely on inline formatting due to off capitalization rules for product names. I could eliminate the centering issue here by using styles rather than the inline text centering the original developer used.
Looks like time to revisit some of these old projects.
I have found the difference.
When I open the project in Flare 2023 the "Add content to head" box contains:
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
When I open the project in Flare 2024 the content of that box is now:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'" />
So without me changing anything, I see different contents in that box depending on the version of Flare I am using.
Unfortunately I have to rely on inline formatting due to off capitalization rules for product names. I could eliminate the centering issue here by using styles rather than the inline text centering the original developer used.
Looks like time to revisit some of these old projects.
I have found the difference.
When I open the project in Flare 2023 the "Add content to head" box contains:
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
When I open the project in Flare 2024 the content of that box is now:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'" />
So without me changing anything, I see different contents in that box depending on the version of Flare I am using.
Re: Flare 2024 issue?
Yeah, I just checked using 2024, and by default Flare will add that new meta tag.
This new meta tag appears to cause some console errors in Flare's own generated styles for the HTML5 skin responsive header!
I see console errors like this: "Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". ..."
I'd suggest reporting the bug to MadCap, if you haven't already.
This new meta tag appears to cause some console errors in Flare's own generated styles for the HTML5 skin responsive header!
I see console errors like this: "Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". ..."
I'd suggest reporting the bug to MadCap, if you haven't already.
Re: Flare 2024 issue?
I just found the same issue today, and found my way to this forum post. If you clear the "Add content to head" check box in Flare 2024, then your project will once again show the inline styles as they were built in Flare 2023.
I tried to report a Content Security Policy bug to MadCap last year but I didn't do a very good job of explaining myself so it didn't go very far. In very simple terms, inline styles are a backdoor where hackers can insert malicious code in your websites to do very bad things. Content Security Policies will prevent inline styles from being applied, which in turn will prevent any malicious code from being run. So in this case, if you clear the "Add content to head" check box in Flare 2024, you can prevent the new Content Security Policy line from being applied to your builds, which will once again allow your inline styles to be shown.
I'm not advocating whether you should disable the Content Security Policy. That's a complicated issue for you and your security teams to work out. I'm just explaining how you can easily get your inline styles back in Flare 2024.
I tried to report a Content Security Policy bug to MadCap last year but I didn't do a very good job of explaining myself so it didn't go very far. In very simple terms, inline styles are a backdoor where hackers can insert malicious code in your websites to do very bad things. Content Security Policies will prevent inline styles from being applied, which in turn will prevent any malicious code from being run. So in this case, if you clear the "Add content to head" check box in Flare 2024, you can prevent the new Content Security Policy line from being applied to your builds, which will once again allow your inline styles to be shown.
I'm not advocating whether you should disable the Content Security Policy. That's a complicated issue for you and your security teams to work out. I'm just explaining how you can easily get your inline styles back in Flare 2024.
Re: Flare 2024 issue?
Yes, that is what I already figured out.
My larger question is why Flare has decided to, by default, put different text in that box depending on the version of Flare running with no documentation on this that I can find in their release documents.
My larger question is why Flare has decided to, by default, put different text in that box depending on the version of Flare running with no documentation on this that I can find in their release documents.
Re: Flare 2024 issue?
It's in the help, but doesn't adequately explain why it's there, or the side effects.
Help: https://help.madcapsoftware.com/flare20 ... hlight=CSP
I reported it as a bug, as it causes console errors with Flare's own HTML code for the skin header and navigation.
Help: https://help.madcapsoftware.com/flare20 ... hlight=CSP
I reported it as a bug, as it causes console errors with Flare's own HTML code for the skin header and navigation.
Re: Flare 2024 issue?
I did a little bit of testing...
In Flare 2023R2 (and earlier), the target has the "Add content to head" enabled by default, with the following meta tag.
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
In Flare 2024, the target has the "Add content to head" disabled by default, with the following meta tag.
<meta http-equiv="Content-Security-Policy" content="default-src 'self'" />
Note that although the previous "IE=edge" meta tag is not displayed in the target setting any more, it is now always automatically included in the output.
When you move from 2023R2 to 2024...
(1) Target has "Add content to head" enabled, and you also added your own custom meta tags. => Nothing changes, and new CSP meta tag is not added to your custom tags.
(2) Target has "Add content to head" enabled, with only the default "IE=edge" meta tag => The "Add content to head" setting is now disabled, but shows the new CSP meta tag (so this is added if enabled).
(3) Target has "Add content to head" disabled => Setting still disabled, but shows the new CSP meta tag (so this is added if enabled).
Anyway, at least it looks like this new CSP tag should not be added to the output without you knowing when you update to 2024, as you have to enable the setting whilst using 2024. However, this setting is still going to catch people out.
In Flare 2023R2 (and earlier), the target has the "Add content to head" enabled by default, with the following meta tag.
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
In Flare 2024, the target has the "Add content to head" disabled by default, with the following meta tag.
<meta http-equiv="Content-Security-Policy" content="default-src 'self'" />
Note that although the previous "IE=edge" meta tag is not displayed in the target setting any more, it is now always automatically included in the output.
When you move from 2023R2 to 2024...
(1) Target has "Add content to head" enabled, and you also added your own custom meta tags. => Nothing changes, and new CSP meta tag is not added to your custom tags.
(2) Target has "Add content to head" enabled, with only the default "IE=edge" meta tag => The "Add content to head" setting is now disabled, but shows the new CSP meta tag (so this is added if enabled).
(3) Target has "Add content to head" disabled => Setting still disabled, but shows the new CSP meta tag (so this is added if enabled).
Anyway, at least it looks like this new CSP tag should not be added to the output without you knowing when you update to 2024, as you have to enable the setting whilst using 2024. However, this setting is still going to catch people out.
Re: Flare 2024 issue?
(2) Target has "Add content to head" enabled, with only the default "IE=edge" meta tag => The "Add content to head" setting is now disabled, but shows the new CSP meta tag (so this is added if enabled).
This WAS NOT my case.
I had projects with the 2023 default tag enabled in 2023R2. When I opened those projects and generated output in 2024, the default tag was changed and the setting remained enabled. Therefore the output was incorrectly formatted. Fortunately the project had inline styling on the front page, so the problem was noticeable. Inside the project product names (which require odd mix of lower case and capitals applied inline) had lost their formatting as well.
This WAS NOT my case.
I had projects with the 2023 default tag enabled in 2023R2. When I opened those projects and generated output in 2024, the default tag was changed and the setting remained enabled. Therefore the output was incorrectly formatted. Fortunately the project had inline styling on the front page, so the problem was noticeable. Inside the project product names (which require odd mix of lower case and capitals applied inline) had lost their formatting as well.
Re: Flare 2024 issue?
Ah, for (2) it looks like there are two different behaviours, depending on whether you ever changed the setting in 2023.
In Flare 2023, the default state for "Add content to head" is enabled.
(2A) If you have never edited this setting in the target, the setting state is not recorded in the target. So when you open the same target in 2024, the default state for "Add content to head" is now disabled.
(2B) If you edit this setting to disable it and then enable it again, but you also do not make any change to the default meta tag content, then the enabled state is recorded in the target as follows:
So if you open that target in 2024, the setting is enabled, and the default CSP meta tag in 204 is then applied.
So it looks like this only occurs if you disabled and then enabled the setting, but don't actually make changes to the meta tag content. If you do make changes to the meta tag content, then it preserves your old meta tags and doesn't add the new CSP meta tag.
In Flare 2023, the default state for "Add content to head" is enabled.
(2A) If you have never edited this setting in the target, the setting state is not recorded in the target. So when you open the same target in 2024, the default state for "Add content to head" is now disabled.
(2B) If you edit this setting to disable it and then enable it again, but you also do not make any change to the default meta tag content, then the enabled state is recorded in the target as follows:
Code: Select all
<MetaTags
Enabled="true" />So it looks like this only occurs if you disabled and then enabled the setting, but don't actually make changes to the meta tag content. If you do make changes to the meta tag content, then it preserves your old meta tags and doesn't add the new CSP meta tag.
Re: Flare 2024 issue?
"I reported it as a bug, as it causes console errors with Flare's own HTML code for the skin header and navigation."
That's what i also tried to report in my bug from last year. My company enabled CSP on the servers where we were uploading our Help files, so we've already been dealing with this for the last year. We found that Flare is adding a lot of inline styles automatically when you build an HTML5 target. My security team wanted no console errors at all, so we had to find workarounds to eliminate every inline style but still build the Help files the way we wanted. It took a lot of hacking of the CSS files but we made it work. I tried to report where all the inline styles were coming from so maybe Madcap could address that, but it looks like they're still there in Flare 2024.
That's what i also tried to report in my bug from last year. My company enabled CSP on the servers where we were uploading our Help files, so we've already been dealing with this for the last year. We found that Flare is adding a lot of inline styles automatically when you build an HTML5 target. My security team wanted no console errors at all, so we had to find workarounds to eliminate every inline style but still build the Help files the way we wanted. It took a lot of hacking of the CSS files but we made it work. I tried to report where all the inline styles were coming from so maybe Madcap could address that, but it looks like they're still there in Flare 2024.
-
jimgilliam
- Propeller Head
- Posts: 86
- Joined: Tue Jun 04, 2013 9:49 am
- Location: Arkansas, U.S.A.
Re: Flare 2024 issue?
This is potentially why I've been having CORS issues. This CORS thing I think is a horrible invention.
Our in-house server includes CORS in the server header responses, so it's difficult for us to share docs (employee to employee) from a common HTML5 output. Half the time it thinks subfolders are crossing domains.
As mentioned in this thread, I too am now wondering if what I've done in Flare, what Flare is doing, and what our IT has done are all conflicting.
CORS is confusing to me. Even when I tell it it's okay to use-this-script, it still thinks I'm crossing dang domains (and the script is local... which is external and also crossing-domains!! So stupid.) And I haven't found quality documentation about it at all... MDN is horrible about it, and so is W3. I think it's because they're majorly confused too.
Our in-house server includes CORS in the server header responses, so it's difficult for us to share docs (employee to employee) from a common HTML5 output. Half the time it thinks subfolders are crossing domains.
As mentioned in this thread, I too am now wondering if what I've done in Flare, what Flare is doing, and what our IT has done are all conflicting.
CORS is confusing to me. Even when I tell it it's okay to use-this-script, it still thinks I'm crossing dang domains (and the script is local... which is external and also crossing-domains!! So stupid.) And I haven't found quality documentation about it at all... MDN is horrible about it, and so is W3. I think it's because they're majorly confused too.
