In reply to @asbjorn:olli.ng
Cactus is not really in active development any more. I don't use it for anything myself, and I'm not making any money on it (nor am I planning to).

Does the spaces MR on the appservice project https://gitlab.com/cactus-comments/cactus-appservice/-/merge_requests/13 need anything to move it forward?

It seems like a useful change. but I'm not sure where it sits or how involved the changes are

In reply to @asbjorn:olli.ng
Cactus is not really in active development any more. I don't use it for anything myself, and I'm not making any money on it (nor am I planning to).

In reply to @wolf:wolfspyre.io

Does the spaces MR on the appservice project https://gitlab.com/cactus-comments/cactus-appservice/-/merge_requests/13 need anything to move it forward?

It seems like a useful change. but I'm not sure where it sits or how involved the changes are

https://github.com/matrix-org/matrix-appservice-discord/issues/896 Looks like this might be related.

The workaround is to enable use_appservice_legacy_authorization: true in the Synapse config, but ideally this is a temporary solution.
should probably switch to the Authorization header mentioned in that changelog link.

https://matrix-org.github.io/synapse/latest/upgrade#upgrading-to-v1900

https://spec.matrix.org/v1.6/application-service-api/#authorization

attrs==21.2.0 # via pytest
certifi==2021.5.30 # via requests
chardet==4.0.0 # via requests
click==8.0.1 # via flask
coverage[toml]==6.3.1 # via pytest-cov
flask==2.0.1 # via -r requirements.in
gunicorn==20.1.0 # via -r requirements.in
idna==2.10 # via requests
iniconfig==1.1.1 # via pytest
itsdangerous==2.0.1 # via flask
jinja2==3.0.1 # via flask
markupsafe==2.0.1 # via jinja2
packaging==20.9 # via pytest
pluggy==0.13.1 # via pytest
py==1.10.0 # via pytest
pyparsing==2.4.7 # via packaging
pytest==6.2.4 # via  -r requirements.in pytest-cov
pytest-cov==3.0.0 # via -r requirements.in
requests==2.25.1 # via -r requirements.in
toml==0.10.2 # via pytest
tomli==2.0.0 # via coverage
urllib3==1.26.5 # via requests
werkzeug==2.0.1 # via flask

->

blinker==1.8.2  # via flask
certifi==2024.7.4  # via requests
charset-normalizer==3.3.2  # via requests
click==8.1.7  # via flask
coverage[toml]==7.6.0  # via pytest-cov
flask==3.0.3  # via -r requirements.in
gunicorn==22.0.0  # via -r requirements.in
idna==3.7  # via requests
iniconfig==2.0.0  # via pytest
itsdangerous==2.2.0  # via flask
jinja2==3.1.4  # via flask
markupsafe==2.1.5  # via jinja2 werkzeug
packaging==24.1  # via gunicorn pytest
pluggy==1.5.0  # via pytest
pytest==8.3.2  # via -r requirements.in pytest-cov
pytest-cov==5.0.0  # via -r requirements.in
requests==2.32.3  # via -r requirements.in
urllib3==2.2.2  # via requests
werkzeug==3.0.3  # via flask

In reply to @grange85:matrix.org
Hi all, I've just installed Cactus Comments so apologies for potential naivety - to deal with CSP issues I extracted the inline js into a separate file and all is working pretty much as expected except that the Log-in button loads further up the entire page - rather than in the visible window - and so for most of my content the dialog is invisible (this caused me many headaches thinking it was more CSP issues).

You can see the problem in action here:
https://www.fullofwishes.co.uk/2024/08/01/my-record-collection-158-luna-lunapark-deluxe-2xlp/

If you scroll down and choose log-in nothing appears to happen but if you scroll back up you can see the dialog. I assume this might be to do with removing the inline js??

(you can see my inline js here: https://github.com/grange85/no-style-please/blob/master/assets/js/comment.js)

Any clues on cause and resolution appreciated.

On a related CSP note - in order to login I had to add my homeserver (matrix.org) to my CSP - but I guess that means that any other homeserver won't be able to login because of CSP blocking? And I'm obv not going to add every possible homeserver to my CSP!!

Any tips on how best to handle Cactus and CSP - I'm using it on a static site generated with Jekyll so am limited on what I can do dynamically

Thanks

In reply to @wolf:wolfspyre.io
what's others experience been here? are y'all using anything different?
has anyone else already explored the access_token header?
should I try to fix the param->header in 3.9 and then up to 3.11?
would you prefer a mr upping to 3.11 and then another for the access_token?
or is a single changeset including both preferred to reduce extra effort/churn?

what's others experience been here? are y'all using anything different?

cactus.chat is just using the docker image that we build

has anyone else already explored the access_token header?

I haven't looked into it deeply. We should definitely update the appservice to do the right thing. My own deployments just use legacy auth

should I try to fix the param->header in 3.9 and then up to 3.11?
would you prefer a mr upping to 3.11 and then another for the access_token?

doing this as two MRs would be preferrable. Any reason you're bumping to 3.11, and not 3.12?

In reply to @wolf:wolfspyre.io
what's others experience been here? are y'all using anything different?
has anyone else already explored the access_token header?
should I try to fix the param->header in 3.9 and then up to 3.11?
would you prefer a mr upping to 3.11 and then another for the access_token?
or is a single changeset including both preferred to reduce extra effort/churn?

what's others experience been here? are y'all using anything different?

cactus.chat is just using the docker image that we build

has anyone else already explored the access_token header?

I haven't looked into it deeply. We should definitely update the appservice to do the new thing. My own deployments just use legacy auth

should I try to fix the param->header in 3.9 and then up to 3.11?
would you prefer a mr upping to 3.11 and then another for the access_token?

doing this as two MRs would be preferrable. Any reason you're bumping to 3.11, and not 3.12?

what's others experience been here? are y'all using anything different?

cactus.chat is just using the docker image that we build

has anyone else already explored the access_token header?

I haven't looked into it deeply. We should definitely update the appservice to do the new thing. My own deployments just use legacy auth, with the new synapse config line. I think it's kind of awkward.

should I try to fix the param->header in 3.9 and then up to 3.11?
would you prefer a mr upping to 3.11 and then another for the access_token?

doing this as two MRs would be preferrable. Any reason you're bumping to 3.11, and not 3.12?

In reply to @asbjorn:olli.ng
I think you do need to add the connect-src * and img-src * CSP in order for cactus comments to work properly

Thanks, although I have CSP working, the only outstanding problem is that it seems that connect-src would require every possible homeserver that a user might log in with, which is impractical.

I don't think img-src is required.

In reply to @asbjorn:olli.ng

what's others experience been here? are y'all using anything different?

cactus.chat is just using the docker image that we build

has anyone else already explored the access_token header?

I haven't looked into it deeply. We should definitely update the appservice to do the new thing. My own deployments just use legacy auth, with the new synapse config line. I think it's kind of awkward.

should I try to fix the param->header in 3.9 and then up to 3.11?
would you prefer a mr upping to 3.11 and then another for the access_token?

doing this as two MRs would be preferrable. Any reason you're bumping to 3.11, and not 3.12?

In reply to @asbjorn:olli.ng

what's others experience been here? are y'all using anything different?

cactus.chat is just using the docker image that we build

has anyone else already explored the access_token header?

I haven't looked into it deeply. We should definitely update the appservice to do the new thing. My own deployments just use legacy auth, with the new synapse config line. I think it's kind of awkward.

should I try to fix the param->header in 3.9 and then up to 3.11?
would you prefer a mr upping to 3.11 and then another for the access_token?

doing this as two MRs would be preferrable. Any reason you're bumping to 3.11, and not 3.12?

wilco.
stopped at 3.11 as I know in other projects, a nonzero volume of stuff busted between 3.11 / 3.12 and I wanted to identify how to fix the existing problem before making new ones for myself without an obvious upside ;)
once I get tests worky, I'll slice off my change set, bump to 3.12 sub that as its own thing, then bolt my changeset back in.

are you opposed to setting the test rig's listen address explicitly to 0.0.0.0?

otherwise, synapse will bind to v6 and v4, which is noworky in gitlab runner envs where ipv6 is disabled.