Dialog vertical positioning changes ?

phiw13 · 2024-12-16 08:51:58

Well, colour me shocked – in the end it is/was a browser extension. But it was not in an expected way: the extension was disabled for the test site (Safari settings > Websites, scroll down to find the extension, set to “Deny” for the target site); that is why I discarded that as a possible issue. But what actually prevents any interaction is the setting “For other sites: Ask / Deny / Approve” set to “Ask”. This is an older – last updated 2years ago – extension based on an older extension spec. I found some other ones having the same behaviour¹. Newer, or recently updated, extensions do not have this issue.

I apologise for sending you on ghost chase.

-^–

¹ RSS button for Safari and Cascasdea – I don’t know of any replacement.

etc · 2024-12-16 21:05:01

No worries, blockers are sometimes playing tricks on me too, thanks for sleuthing. Anyway, Patrick seems to have issues with sandboxing too, so I leave the checkbox there for the moment. You two will be in charge of answering security reports :-)

phiw13 · 2024-12-17 00:44:12

etc wrote #338555:

Anyway, Patrick seems to have issues with sandboxing too, so I leave the checkbox there for the moment. You two will be in charge of answering security reports :-)

Apart from the fact that the iframe (eventually?) has some more privileges, I have to wonder: if an user with sufficient privileges (the top 3 types) browse around the site (public part) while logged in and “something” has been inserted that can do naughty things, isn’t the risk about equally great?

Pat64 · 2024-12-17 05:35:43

etc wrote #338555:

[…] Anyway, Patrick seems to have issues with sandboxing too, so I leave the checkbox there for the moment. You two will be in charge of answering security reports :-)

The only problems I encounter: Firefox can’t load some files. Here is the warning message from the console:

Cross-Origin Request): the “Same Origin” policy does not allow you to load the remote resource...

… For the custom fonts and (my main) external CSS… Despite my .htaccess file has this rule:

<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin 'origin'
</IfModule>

This is a live server for a website in production (your “Commits” dating from December 15). Never mind: the preview iframe is the same as the public site.

Last edited by Pat64 (2024-12-17 06:10:22)

phiw13 · 2024-12-17 08:42:44

This might be of interest: devcodef1.com/news/1438618/iframe-and-csp:@contentsecuritypolicy@ attribute for the iframe; allow-same-origin value for the sandbox attribute. See also this: web.dev/articles/sandboxed-iframes part. regarding the allow-same-origin, and MDN developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/sandbox#allow-same-origin

The Chromium console report for webfonts is a little less obscure than Firefox:

Access to font at 'http://phiw.local/_r/f/PTSansNarrow/pt_sans-narrow-bold.woff2' from origin 'null' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header has a value 'http://phiw.local' that is not equal to the supplied origin.

Instead of fully removing the sandbox attribute, revert to allow-scripts and add allow-same-origin. Maybe ?

Pat64 · 2024-12-17 08:54:13

Update: This resolves all issues encountered:

Within the .htaccess file, instead of this:

Header set Access-Control-Allow-Origin 'origin'

Set it the domain with protocol and a final slash:

Header set Access-Control-Allow-Origin 'https://example.com/'

… but not when “Sandbox” is checked…

Last edited by Pat64 (2024-12-17 08:58:06)

phiw13 · 2024-12-17 09:20:31

Pat64 wrote #338559:

Update: This resolves all issues encountered:

Within the .htaccess file, instead of this:

Header set Access-Control-Allow-Origin 'origin'...

Set it the domain with protocol and a final slash:

Header set Access-Control-Allow-Origin 'https://example.com/'...

… but not when “Sandbox” is checked…

Yes you should specify the domain, and I don’t think 'origin' is even valid (I could be wrong, though). Not sure too if you need the ' surrounding the domain, it works for me without.

As for the sandbox issue, see my post above.

etc · 2024-12-17 09:30:46

phiw13 wrote #338556:

if an user with sufficient privileges (the top 3 types) browse around the site (public part) while logged in and “something” has been inserted that can do naughty things, isn’t the risk about equally great?

Oh, these are two big differences. An undsandboxed iframe can access its parent window, which, in the preview case, is your admin-side. Try previewing this (in the article body) in iframe and on the public side:

<script>
alert(parent.textpattern._txp_token);
</script>

So, a tiny script can, say, steal your txp token and bypass our csrf protection. A more elaborated one can ruin almost everything.

Instead of fully removing the sandbox attribute, revert to allow-scripts and add allow-same-origin. Maybe ?

Nope, it’s one or other. Setting them both allows a script to unsandbox the frame.

etc · 2024-12-17 11:47:45

The main difficulty is that (currently) for most users, the public and the admin side have same origin (scheme/host/port). We should consider separating them in txp5.

Bloke · 2024-12-17 17:20:48

etc wrote #338562:

The main difficulty is that (currently) for most users, the public and the admin side have same origin (scheme/host/port). We should consider separating them in txp5.

Hmmm, how would we practically do that? Short of forcing a different port for the admin side or using a subdomain (which is an additional level of messing around with peoples’ .htaccess files and leaves Nginx out in the cold) I can’t see a neat way to separate the two. Unless I’m missing something, it would significantly raise the installation barrier.

etc · 2024-12-17 18:49:21

Bloke wrote #338563:

it would significantly raise the installation barrier.

Certo, it shouldn’t be mandatory. But if one has this possibility (subdomain), can we make it work?

Bloke · 2024-12-17 19:34:06

etc wrote #338564:

Certo, it shouldn’t be mandatory. But if one has this possibility (subdomain), can we make it work?

I expect so. We only have a single “site url” pref at present. The multi-site installation offers support for an admin side URL (or path? Both? Can’t remember) variable, so we could probably tweak that to allow separation of the two areas if that variable is set in the config file.

Textpattern CMS

Textpattern CMS support forum

#49 2024-12-16 08:51:58

Re: Dialog vertical positioning changes ?

#50 2024-12-16 21:05:01

Re: Dialog vertical positioning changes ?

#51 2024-12-17 00:44:12

Re: Dialog vertical positioning changes ?

etc wrote #338555:

#52 2024-12-17 05:35:43

Re: Dialog vertical positioning changes ?

etc wrote #338555:

#53 2024-12-17 08:42:44

Re: Dialog vertical positioning changes ?

#54 2024-12-17 08:54:13

Re: Dialog vertical positioning changes ?

#55 2024-12-17 09:20:31

Re: Dialog vertical positioning changes ?

Pat64 wrote #338559:

#56 2024-12-17 09:30:46

Re: Dialog vertical positioning changes ?

phiw13 wrote #338556:

#57 2024-12-17 11:47:45

Re: Dialog vertical positioning changes ?

#58 2024-12-17 17:20:48

Re: Dialog vertical positioning changes ?

etc wrote #338562:

#59 2024-12-17 18:49:21

Re: Dialog vertical positioning changes ?

Bloke wrote #338563:

#60 2024-12-17 19:34:06

Re: Dialog vertical positioning changes ?

etc wrote #338564:

Board footer