Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Link to attachment via copy & paste not correct #17057

Closed
2 tasks done
nsolthe opened this issue Sep 15, 2021 · 6 comments · Fixed by #17572
Closed
2 tasks done

Link to attachment via copy & paste not correct #17057

nsolthe opened this issue Sep 15, 2021 · 6 comments · Fixed by #17572
Labels
issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail

Comments

@nsolthe
Copy link

nsolthe commented Sep 15, 2021

  • Gitea version (or commit ref): 1.15.2
  • Git version: 2.17.1
  • Operating system: Linux
    • Downloaded gitea from binary (https://dl.gitea.io/gitea/1.15.2/gitea-1.15.2-linux-amd64.xz)
    • Running as systemd service
    • Distro: Ubuntu Server 18.04.5 LTS
  • Database:
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • No
  • Log gist:

Description

I'm working on a Windows PC.
While creating an issue or creating/editing a comment I like to add screenshots. I copy the image file by selecting it in the file explorer, press "Ctrl + c" on keyboard, change to Windows Edge where I am creating the comment, press "Ctrl + v" after the cursor is in the location where I want the image.

The image gets added as and the link is added after file upload completes. When selecting preview the image does not get displayed but I see a "broken image link" pictogram.

I have noticed that I need to edit the automatically generated link from /gitea/attachments/<image_id> to /attachments/<image_id> and then I get the image preview.

Images added in older comments/issues are currently displayed with the "broken image link" pictogram.
It seems that there have been some changes to how the links are being created.

Hosting environment

We are using an apache as reverse proxy for http to https redirect.

The gitea base-URL is configured as: https://<hostname>/gitea/

Screenshots

image

image

@zeripath
Copy link
Contributor

What is your [server] ROOT_URL?

Are you running gitea behind a reverse proxy with some url-rewriting?

@nsolthe
Copy link
Author

nsolthe commented Sep 15, 2021

What is your [server] ROOT_URL?

It is:

[server]
ROOT_URL = https://<HOST>.<DOMAIN>/gitea/

Are you running gitea behind a reverse proxy with some url-rewriting?

Yes. The apache config looks like:

Redirect permanent "/gitea" "/gitea/"
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>

<Proxy *>
Order allow,denyAllow from all
</Proxy>

ProxyPass /gitea/ http://localhost:3000/ nocanon
ProxyPassReverse /gitea/ http://localhost:3000/
AllowEncodedSlashes NoDecode

@Sol7469
Copy link

Sol7469 commented Sep 22, 2021

I am a coworker of @nsolthe and I have copied the gitea instance with this problem to another Linux machine to investigate, if our reverse proxy is causing this. For this copy I used a dump and the original config file with just minor changes and of course no reverse proxy. Here is the output from a diff of both used config files:

SSH_DOMAIN       = <simple host name for testing>               |  SSH_DOMAIN       = <original hostname>
ROOT_URL         = /                                            |  ROOT_URL         = https://<=valid FQDN=>/gitea/
DISABLE_SSH      = true                                         |  DISABLE_SSH      = false

[mailer]                                                           [mailer]
ENABLED = false                                                 |  ENABLED = true

For me, only ROOT_URL seems to be of interest here.

Without a reverse proxy that adds /gitea/ at the end of the URL, attachments can be pasted into comments and can be displayed without any problems. Maybe there is a little mistake in generating links in comments for pasted attachments. For me, it looks like protocol and hostname from ROOT_URL are stripped and a remaining string is put in front of a URL of an attachment. But if you are at a page of an issue, there already is a /gitea/ at the beginning of this URL path followed by organisation name and repository name. So an additional /gitea/ is wrong here.

Hope that helps to find this little problem.

@ryshi
Copy link

ryshi commented Nov 2, 2021

I met this problem on v1.15.6. I just copied a image and pasted into the issue editor, but image url was broken.

  • attachement url by upload : <host>/gitea/attachments/434cc057-5783-43d6-aaf1-3a743d4a9425
  • attachement url showed in editor : <host>/gitea/ryan/test/gitea/attachments/434cc057-5783-43d6-aaf1-3a743d4a9425
  • correct url should be : <host>/gitea/ryan/test/attachments/434cc057-5783-43d6-aaf1-3a743d4a9425

image

@lunny
Copy link
Member

lunny commented Nov 4, 2021

I met this problem on v1.15.6. I just copied a image and pasted into the issue editor, but image url was broken.

  • attachement url by upload : <host>/gitea/attachments/434cc057-5783-43d6-aaf1-3a743d4a9425
  • attachement url showed in editor : <host>/gitea/ryan/test/gitea/attachments/434cc057-5783-43d6-aaf1-3a743d4a9425
  • correct url should be : <host>/gitea/ryan/test/attachments/434cc057-5783-43d6-aaf1-3a743d4a9425

image

Could you reproduce it on https://try.gitea.io ?

@lunny lunny added the issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail label Nov 4, 2021
@zeripath zeripath changed the title Link to attachement via copy & paste not correct Link to attachment via copy & paste not correct Nov 6, 2021
zeripath added a commit to zeripath/gitea that referenced this issue Nov 6, 2021
Since we fixed the url base for the links in repositories we no longer need to add
the appsuburl to pasted image links.

Fix go-gitea#17057

Signed-off-by: Andrew Thornton <art27@cantab.net>
@zeripath
Copy link
Contributor

zeripath commented Nov 6, 2021

Sorry this is due to us changing the base url for absolute path links from within repositories. Previously these would be relative to the host but now they're relative to the repository. Thus the appsuburl is no longer needed and is in fact incorrect.

wxiaoguang pushed a commit that referenced this issue Nov 8, 2021
* Remove appSubUrl from pasted images

Since we fixed the url base for the links in repositories we no longer need to add
the appsuburl to pasted image links.

Fix #17057

Signed-off-by: Andrew Thornton <art27@cantab.net>
zeripath added a commit to zeripath/gitea that referenced this issue Nov 8, 2021
Backport go-gitea#17572

* Remove appSubUrl from pasted images

Since we fixed the url base for the links in repositories we no longer need to add
the appsuburl to pasted image links.

Fix go-gitea#17057

Signed-off-by: Andrew Thornton <art27@cantab.net>
zeripath added a commit that referenced this issue Nov 8, 2021
Backport #17572

* Remove appSubUrl from pasted images

Since we fixed the url base for the links in repositories we no longer need to add
the appsuburl to pasted image links.

Fix #17057

Signed-off-by: Andrew Thornton <art27@cantab.net>
Chianina pushed a commit to Chianina/gitea that referenced this issue Mar 28, 2022
* Remove appSubUrl from pasted images

Since we fixed the url base for the links in repositories we no longer need to add
the appsuburl to pasted image links.

Fix go-gitea#17057

Signed-off-by: Andrew Thornton <art27@cantab.net>
@go-gitea go-gitea locked and limited conversation to collaborators Apr 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants