Portus icon indicating copy to clipboard operation
Portus copied to clipboard

Not all assets respect RAILS_RELATIVE_URL_ROOT

Open atheriel opened this issue 5 years ago • 29 comments

Description

This is mentioned in the more recent comments on #1608, but it should be a separate issue. When Portus is deployed with RAILS_RELATIVE_URL_ROOT, not all static assets will respect this relative root. In particular:

  • All assets mentioned in the .css file, including the webfonts and the layout background image.
  • All favicons mentioned in the <head> tag.

Steps to reproduce

  1. Deploy Portus to non-root location with a valid RAILS_RELATIVE_URL_ROOT, with or without Rails serving the static assets.
  2. Open the application in a browser, particularly with dev tools open.
  3. Observe that some assets return 404 (while others work just fine).
  • Expected behavior: Assets are served correctly.
  • Actual behavior: Specific assets will 404 because they are not adhering to the relative root.

I can provide more deployment/configuration details if necessary, but I doubt that they are useful in this case.

Portus version: 2.4.

atheriel avatar Oct 28 '18 01:10 atheriel

@atheriel could you give more details about the errors themselves and your deployment? Because I've tried to reproduce in the docker-compose file I use for dev and it works with rails serving the assets.

vitoravelino avatar Oct 29 '18 18:10 vitoravelino

Actually, the css, webfonts and images work fine but the favicons are indeed not found.

vitoravelino avatar Oct 29 '18 18:10 vitoravelino

Sure, I'm trying to get Portus deployed as a stack inside a swarm cluster. It looks like this:

version: '3.1'

services:
  portus:
    image: opensuse/portus:latest
    environment:
      - PORTUS_MACHINE_FQDN_VALUE=xxx.x.x.x
      - PORTUS_CHECK_SSL_USAGE_ENABLED=false
      - CCONFIG_PREFIX=PORTUS
      - PORTUS_DB_HOST=db
      - PORTUS_DB_DATABSE=portus
      - PORTUS_DB_PASSWORD=portus
      - PORTUS_DB_POOL=5
      - PORTUS_SECRET_KEY_BASE_FILE=/run/secrets/key_base
      - PORTUS_PASSWORD_FILE=/run/secrets/user_password
      - PORTUS_KEY_PATH=/certificates/portus.key
      - RAILS_SERVE_STATIC_FILES=true
      - RAILS_RELATIVE_URL_ROOT=/portus/
    ports:
      - 3000:3000
    networks:
      - portus
    secrets:
      - user_password
      - key_base
    logging:
      options:
        max-size: "500k"

  background:
    image: opensuse/portus:latest
    environment:
      - PORTUS_BACKGROUND=true 
      - PORTUS_MACHINE_FQDN_VALUE=xxx.x.x.x
      - CCONFIG_PREFIX=PORTUS
      - PORTUS_DB_HOST=db
      - PORTUS_DB_DATABSE=portus
      - PORTUS_DB_PASSWORD=portus
      - PORTUS_DB_POOL=5
      - PORTUS_SECRET_KEY_BASE_FILE=/run/secrets/key_base
      - PORTUS_PASSWORD_FILE=/run/secrets/user_password
      - PORTUS_KEY_PATH=/certificates/portus.key
    networks:
      - portus
    secrets:
      - user_password
      - key_base
    logging:
      options:
        max-size: "500k"

  db:
    image: library/mariadb:10.0.23
    command: mysqld --character-set-server=utf8 --collation-server=utf8_unicode_ci --init-connect='SET NAMES UTF8;' --innodb-flush-log-at-trx-commit=0
    environment:
      - MYSQL_DATABSE=portus
      - MYSQL_ROOT_PASSWORD=portus
    networks:
      - portus
    logging:
      options:
        max-size: "500k"

secrets:
  user_password:
    file: ./user_password.txt
  key_base:
    file: ./key_base.txt

networks:
  portus: {}

I also have nginx sitting between this cluster and the outside world, redicting /portus/ to port 3000.

location /portus/ {
    proxy_pass http://127.0.0.1:3000/portus/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $server_name;
}

For the most part, this is working fine. But in devtools (and in nginx logs), plenty of asset calls are returning 404 because they are being retrieved from /assets/ instead of /portus/assets/ (in this case). So it is my suspicion that these assets are not respecting RAILS_RELATIVE_URL_ROOT.

By the way, two users describe identical patterns to what I have seen here and here.

atheriel avatar Oct 29 '18 22:10 atheriel

If you are using nginx to serve static files, RAILS_SERVE_STATIC_FILES should be set to false. After changing that, what are the requests being made for the webfonts?

This seems to be a wrong configuration in your nginx setup and not a Portus issue itself (except the favicons). I never set up a similar case so I can't provide you the exact right solution for that. From what I could search you need to create an alias or rewrite the url and point to the right location.

vitoravelino avatar Oct 30 '18 07:10 vitoravelino

To clarify, I'm not using nginx to serve static files -- I'm just using it as a reverse proxy to forward requests that would otherwise be blocked by a firewall. Portus should still be serving the static assets. So for instance I can curl the assets just fine if I correct the URL:

$ curl -I "http://127.0.0.1:3000/portus/assets/fontawesome-webfont-aa58f33f239a0fb02f5c7a6c45c043d7a9ac9a093335806694ecd6d4edc0d6a8.ttf"
HTTP/1.1 200 OK
Last-Modified: Tue, 16 Oct 2018 13:16:40 GMT
Content-Type: application/octet-stream
Content-Length: 165548
$ curl -I "http://127.0.0.1:3000/portus/favicon/favicon-16x16.png"
HTTP/1.1 200 OK
Last-Modified: Tue, 16 Oct 2018 13:02:10 GMT
Content-Type: image/png
Content-Length: 1131

So the favicons issue is the same as the webfonts issue, in my view.

After changing that, what are the requests being made for the webfonts?

If I set RAILS_SERVE_STATIC_FILES=false I see the same behaviour.

This seems to be a wrong configuration in your nginx setup and not a Portus issue itself (except the favicons).

I think it is possible to configure nginx to do this, but I'm not sure that really changes the fact that using RAILS_RELATIVE_URL_ROOT does not actually work as advertised.

atheriel avatar Oct 30 '18 15:10 atheriel

This might be related.

atheriel avatar Oct 30 '18 15:10 atheriel

Assets are served correctly but problem is that URLs generated in page etc are wrong at least for web font files, icon images and favicons

lafriks avatar Oct 30 '18 20:10 lafriks

Could you try RAILS_RELATIVE_URL_ROOT=/portus without the slash in the end? I tried with the slash in the end locally and my assets got broken but in my case /portus/portus/assets/... was being requested.

vitoravelino avatar Oct 31 '18 06:10 vitoravelino

For me this assets fail to load

fontawesome-webfont-2adefcbc041e7d18fcf2d417879dc5a09997aa64d675b7a3c4b6ce33da13f3fe.woff2:1 Failed to load resource: the server responded with a status of 404 ()
raleway-bold-9e7254441b1fa37f69d19f8220d45daac9be7f0eea55f7080b9fe9c09c46d2a0.woff2:1 Failed to load resource: the server responded with a status of 404 ()
bg-8cb22ad4875ecdeb164569d4c6c1684a0359047eadb7013c783986be07b0203b.png:1 Failed to load resource: the server responded with a status of 404 ()
fontawesome-webfont-ba0c59deb5450f5cb41b3f93609ee2d0d995415877ddfa223e8a8a7533474f07.woff:1 Failed to load resource: the server responded with a status of 404 ()
fontawesome-webfont-aa58f33f239a0fb02f5c7a6c45c043d7a9ac9a093335806694ecd6d4edc0d6a8.ttf:1 Failed to load resource: the server responded with a status of 404 ()

The request url looks like this:

https://localhost/assets/layout/bg-8cb22ad4875ecdeb164569d4c6c1684a0359047eadb7013c783986be07b0203b.png

And I would expect the request to look like this:

https://localhost/portus/assets/layout/bg-8cb22ad4875ecdeb164569d4c6c1684a0359047eadb7013c783986be07b0203b.png

It seems like there are some urls that are not affected by RAILS_RELATIVE_URL_ROOT.

Nols1000 avatar Nov 28 '18 19:11 Nols1000

@vitoravelino For me the request url is wrong with RAILS_RELATIVE_URL_ROOT=/portus set.

Nols1000 avatar Jan 07 '19 09:01 Nols1000

Problems:

Possible Fixes:

  • Use <base> in combination with relative urls. (This seems to only work for the favicon-problem)
  • Compile the static resources on container start to compile the absolute paths with RAILS_RELATIVE_URL_ROOT
  • Maybe there is a simple way to compile the css with relative urls. (I have not looked into that)

@mssola, @vitoravelino, @cyntss this seems to be an issue with files you where working on. It would be nice if you would join the conversation to help resolving the issue.

Nols1000 avatar Jan 22 '19 12:01 Nols1000

@Nols1000 we really appreciate your feedback. In the meantime what you could do, since you are using nginx, is redirect the requests from /assets/... to /portus/assets/.... But I'm not sure if this is going to conflict with the other apps you have configured there.

vitoravelino avatar Jan 22 '19 14:01 vitoravelino

@vitoravelino Thank you. I'm already doing that, but thats not solving the issue. It's just a workaround. If you need more information or help I'm more than happy to help if I can.

Nols1000 avatar Jan 22 '19 14:01 Nols1000

Thanks for all your contributions! This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

stale[bot] avatar Jul 21 '19 16:07 stale[bot]

I think it is still not fixed

lafriks avatar Jul 21 '19 19:07 lafriks

Thanks for all your contributions! This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

stale[bot] avatar Oct 19 '19 20:10 stale[bot]

It's not fixed please configure your bot or fix this issue already.

Nols1000 avatar Oct 19 '19 20:10 Nols1000

Thanks for all your contributions! This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

stale[bot] avatar Jan 19 '20 00:01 stale[bot]

Still issue

lafriks avatar Jan 19 '20 01:01 lafriks

Thanks for all your contributions! This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

stale[bot] avatar Apr 18 '20 05:04 stale[bot]

still issue

сб, 18 апр. 2020 г., 8:38 stale[bot] [email protected]:

Thanks for all your contributions! This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/SUSE/Portus/issues/2017#issuecomment-615572872, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOGMNWZRPUA5OE3ZIW4YH3RNE4D3ANCNFSM4F7W6MYA .

slavniyteo avatar Apr 18 '20 07:04 slavniyteo

Thanks for all your contributions! This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

stale[bot] avatar Jul 18 '20 06:07 stale[bot]

Still issue

lafriks avatar Jul 18 '20 09:07 lafriks

@lafriks Is it? Have you tested it on master? I had some time to look into it again today and after rewriting the portus development docker image (because the opensuse ruby repo is no reachable), I'm unable to reproduce the issue on master with the docker-compose development deployment.

Nols1000 avatar Jul 18 '20 11:07 Nols1000

Is there a docker image that points to latest master?

lafriks avatar Jul 18 '20 17:07 lafriks

I guess that would have to be the official image with the tag head. It was published over one year ago. It's doesn't have the latest changes.

Nols1000 avatar Jul 18 '20 18:07 Nols1000

Thanks for all your contributions! This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

stale[bot] avatar Oct 17 '20 20:10 stale[bot]

still an issue, tried to build master but it fails

shotor avatar Oct 25 '20 17:10 shotor

Thanks for all your contributions! This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

stale[bot] avatar Jan 09 '22 04:01 stale[bot]