Support contact does not set CORS headers #865
Labels
No labels
Bug
Cherry-picking
Database
Dependencies
Difficulty
Easy
Difficulty
Hard
Difficulty
Medium
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/Federation
Matrix/MSC
Matrix/Media
Meta
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
Wont fix
old/ci/cd
old/rust
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: continuwuation/continuwuity#865
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
@Jade could you attach some context?
Well known support contact endpoint (and apparently all of the matrix endpoints) don't have the appropriate CORS headers set to allow browser JS clients to read them. Instead this is done by the reverse proxy config, which is different per user.
My reverse proxy config through some accident or another sets the cors for matrix.ellis.link but not for the ellis.link well known files.
What should be happening is that continuity itself should be setting the CORS headers, but only on endpoints where it makes sense (i.e. client endpoints). This would fix this little bug and future proof for if we end up doing something more complicated in the web UI. (Note we would need CSRF protection for that anyway, CORS prevents reads not writes).
I had a little look at fixing this this evening, and likely this requires some changes to ruwuma. It could be hacked over the top of it, but the ideal situation would have the CORS information in the route definitions
Support contact do not set CORS headersto Support contact does not set CORS headers