Not all assets respect RAILS_RELATIVE_URL_ROOT

atheriel commented 6 years ago

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

Deploy Portus to non-root location with a valid RAILS_RELATIVE_URL_ROOT, with or without Rails serving the static assets.
Open the application in a browser, particularly with dev tools open.
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.

vitoravelino commented 6 years ago

@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 commented 6 years ago

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

atheriel commented 6 years ago

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.

vitoravelino commented 6 years ago

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.

atheriel commented 6 years ago

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 commented 6 years ago

This might be related.

lafriks commented 6 years ago

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

vitoravelino commented 6 years ago

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.

Nols1000 commented 5 years ago

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 commented 5 years ago

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

Nols1000 commented 5 years ago

Problems:

[ ] fonts are defined in app/assets/stylesheets/application.scss and are compiled to application.css and looks like this for example @font-face{font-family:'FontAwesome';src:url("/assets/fontawesome-webfont-.... That causes fontawesome-webfont-... to be loaded from an url without respecting RAILS_RELATIVE_URL_ROOT. The same can be seen for all fonts loaded in that way.
[ ] bg.png is defined in app/assets/stylesheets/core/variables.scss or vendor/assets/stylesheets/lifeitup/variables.scss. The files are compiled to absolute path and are not generated with RAILS_RELATIVE_URL_ROOT. (It seems that there is a rule .table .table with background-color: url("bg-...") and I dont know why. This could be worth looking into.)
[ ] favicons are defined in app/views/layouts/application.html.slim, app/views/layouts/authentication.html.slim and app/views/layouts/errors.html.slim. The links to the files are absolute and are not generated with RAILS_RELATIVE_URL_ROOT.

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.

vitoravelino commented 5 years ago

@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.

Nols1000 commented 5 years ago

@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.

stale[bot] commented 5 years ago

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.

lafriks commented 5 years ago

I think it is still not fixed

stale[bot] commented 5 years ago

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.

Nols1000 commented 5 years ago

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

stale[bot] commented 4 years ago

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.

lafriks commented 4 years ago

Still issue

stale[bot] commented 4 years ago

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.

slavniyteo commented 4 years ago

still issue

сб, 18 апр. 2020 г., 8:38 stale[bot] notifications@github.com:

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 .

stale[bot] commented 4 years ago

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.

lafriks commented 4 years ago

Still issue

Nols1000 commented 4 years ago

@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.

lafriks commented 4 years ago

Is there a docker image that points to latest master?

Nols1000 commented 4 years ago

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.

stale[bot] commented 4 years ago

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.

shotor commented 4 years ago

still an issue, tried to build master but it fails

stale[bot] commented 2 years ago

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.

SUSE / Portus

Not all assets respect RAILS_RELATIVE_URL_ROOT #2017

Description

Steps to reproduce