Project

General

Profile

Actions

tickets #161273

closed

Edit Comment doesn't work on code.o.o

Added by sfalken@cloverleaf-linux.org 6 months ago. Updated 6 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Pagure
Target version:
-
Start date:
2024-05-30
Due date:
% Done:

100%

Estimated time:

Description

Pretty much that. Have a comment on a Pagure ticket, or PR, and click the "edit" button, and it always comes up with:

"Could not make Edit Work"

It appears that edit of the "first" post is possible, but not any posts further down in the comment chain.

Please see screenshot


Files

Screenshot_20240530_080640.png (293 KB) Screenshot_20240530_080640.png Screenshot of Error Message sfalken@cloverleaf-linux.org, 2024-05-30 15:07

Related issues 1 (0 open1 closed)

Related to openSUSE admin - tickets #152709: Pagure logout redirects to plain text HTTPResolvedcrameleon2023-12-16

Actions
Actions #1

Updated by crameleon 6 months ago

  • Private changed from Yes to No

I can reproduce this in my test project.

Actions #2

Updated by crameleon 6 months ago

The browser console logs the following:

Content-Security-Policy: The page’s settings blocked the loading of a resource (connect-src) at http://code.opensuse.org/crameleon/test1/issue/1/comment/1963/edit?js=1 because it violates the following directive: “default-src 'self'”
Actions #3

Updated by crameleon 6 months ago

I think the issue is with it calling plain "http", but self would rightfully only match "https". Maybe similar to https://progress.opensuse.org/issues/152709 ?

Actions #4

Updated by sfalken@cloverleaf-linux.org 6 months ago

I will say, I do see a fair number of things kicking me back and forth from https to http when using code.o.o, the only reason I notice is because I have an "https-only" extension running in firefox, so I get a splash screen when it does it.

No idea if that's got anything to do with it.

Actions #5

Updated by crameleon 6 months ago

I identified the issue to be with the nginx being configured to set an X-Forwarded-Proto header:

https://code.opensuse.org/heroes/salt/blob/production/f/pillar/role/pagure.sls#_54

This overwrites the X-Forwarded-Proto header, which our TLS terminating frontend proxy (HAProxy) sets to https:

https://code.opensuse.org/heroes/salt/blob/production/f/pillar/cluster/common/public_proxy.sls#_16

with http, since the backend connection is using plain HTTP.

I tried simply removing the option, however it would still set it - I could not find a way to have nginx preserve the existing X-Forwarded-Proto header from HAProxy. Hardcoding https however works, and I think is an acceptable workaround, since we do not allow any public plain HTTP connectivity anyways through permanent redirect, and since we already implement this practice for lists.opensuse.org, which had the same issue.

I already implemented this temporarily and will follow up with the permanent patch.

Actions #6

Updated by crameleon 6 months ago

  • Status changed from New to In Progress
  • Assignee set to crameleon
  • % Done changed from 0 to 50
Actions #8

Updated by crameleon 6 months ago

  • Related to tickets #152709: Pagure logout redirects to plain text HTTP added
Actions #10

Updated by crameleon 6 months ago

  • Status changed from In Progress to Feedback

This is is now correctly deployed.
Is the issue solved for you as well, @sfalken ?

Actions #11

Updated by sfalken@cloverleaf-linux.org 6 months ago

Yup, appears to be working as expected now.

Actions #12

Updated by crameleon 6 months ago

  • Status changed from Feedback to Resolved
  • % Done changed from 90 to 100

Great, thanks for confirming.

Actions

Also available in: Atom PDF