Mixed content error thrown when communicating over 6PN

Questions / Help
1

I’ve managed to set up two fly instances, one is the main rails app, the second one being minio instance with volume attached that would serve as a file server that listens on 9000 port. I’m using aws-s3-sdk gem to connect from main app to minio instance with this config:

# config/storage.yml

minio:
  service: S3
  access_key_id: <%= ENV.fetch('AWS_S3_ACCESS_KEY_ID') %>
  secret_access_key: <%= ENV.fetch('AWS_S3_ACCESS_KEY') %>
  bucket: <%= ENV.fetch('AWS_S3_BUCKET') %>
  region: <%= ENV.fetch('AWS_S3_REGION') %>
  endpoint: "http://<app-name>.internal:9000",
  force_path_style: true

And everything works fine, my main app is able to connect to the minio app and upload/download files/images. The problem comes when displaying those images in the browser, as I receive an error: Loading mixed (insecure) display content [...], which basically means that the browser finds it insecure to connect to not secured app over http (not https).

What would be the fly.io way to connect to my second instance in secured way (basically to see images in the browser)? I’ve checked that at this point my minio app does not allow connections over https.

# minio app fly.toml

app = <app-name>
primary_region = "waw"

[mounts]
  source = "miniodata"
  destination = "/data"

Edit: Is possible that the reason why it happens is because my ip6 address for minio instance is pulbic, not private?

2

If you’re using .fly.dev domains you should be able to use HTTPS so might be a matter of an URL being wrote wrong? Even if you use a custom domain, we offer HTTPS by setting certificates too.

If I’m understanding it correctly you don’t have a HTTP services section on your toml for minio so that could be a reason you’re not receiving HTTPS support.

One option to show files uploaded to mínio is to make it’s app public by adding http_services to the fly toml and ensuring you have public IPv6 and ipv4. That comes with concerns that someone could hack into your mínio instance if they know how to exploit it but definitely makes things easier.

Another option you could do is keep mínio private and route certain requests to it using fly replay. That’s takes some chore work on your app. Here’s an example:

1 Like
3

You were right in that I didn’t have http_service section defined in my minio instance toml.
I added config as follows:

app = <app-name>
primary_region = "waw"

[mounts]
  source = "miniodata"
  destination = "/data"

[http_service]
  internal_port = 9000
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 0
  [http_service.concurrency]
    type = "requests"
    soft_limit = 200
    hard_limit = 250

but with no change - app still doesn’t respond to https requests:

/usr/local/lib/ruby/3.2.0/net/protocol.rb:46:in `connect_nonblock': SSL_connect returned=1 errno=0 peeraddr=[fdaa:2:20b2:a7b:84:b23f:1e0f:2]:9000 state=error: wrong version number (Seahorse::Client::NetworkingError)

And just to clarify, what I’m trying to do is to only connect to minio instance with my main app instance which is within the same organisation. I’m not intending to have minio instance publicly open, only main app will have access and make requests to minio instance.

4

Active Storage has two ways to serve files: redirecting and proxying. Active Storage Overview — Ruby on Rails Guides

What redirect will do is cause the browser to attempt to fetch the data directly from s3 (or in this case minio). As the only endpoint known to rails is an http one, that will be what is provided to the browser.

1 Like
5

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.