Docker: Why does logging in on one Ignition instance cause log out on other Ignition instances?

I'm staging multiple instances of Ignition in docker containers to test server redundancy and Enterprise Admin Module features (EAM). I am using docker compose to create multiple Ignition apps/instances. I am using Chrome and have a tab for each Ignition instance's gateway page. I notice that when I start to authenticate on one Ignition instance I am automatically logged out of the other instances though my aim was to have concurrent access to the gateway config on each instance.

Any idea's on why the Ignition instances are having this unintended cross-impact on other instances and how to resolve it. Note that starting authentication on an incognito browser session does not seem to have the same impact on a non-incognito Ignition session... so perhaps this is more an artifact of Chrome sessions rather than Ignition itself?

Note that these observation are still valid before any other configuration is applied to the Ignition gateways.

Docker compose file:

services:

  gwa:
    # See https://hub.docker.com/r/inductiveautomation/ignition
    # See https://docs.inductiveautomation.com/display/DOC81/Docker+Image
    image: inductiveautomation/ignition:8.1.31
    restart: always
    hostname: dev-ha-gwa
    ports:
      - "9022:8088"
    volumes:
      - gw_a_data:/usr/local/bin/ignition/data
    environment:
      - ACCEPT_IGNITION_EULA=Y
      - IGNITION_EDITION=standard
      - GATEWAY_ADMIN_USERNAME=admin
      - GATEWAY_ADMIN_PASSWORD=ignition
    command: >
      -n 'HA-A'

  gwb:
    # See https://hub.docker.com/r/inductiveautomation/ignition
    # See https://docs.inductiveautomation.com/display/DOC81/Docker+Image
    image: inductiveautomation/ignition:8.1.31
    restart: always
    hostname: dev-ha-gwb
    ports:
      - "9024:8088"
    volumes:
      - gw_b_data:/usr/local/bin/ignition/data
    environment:
      - ACCEPT_IGNITION_EULA=Y
      - IGNITION_EDITION=standard
      - GATEWAY_ADMIN_USERNAME=admin
      - GATEWAY_ADMIN_PASSWORD=ignition
    command: >
      -n 'HA-B'

volumes:
  gw_a_data:
  gw_b_data:

Try using alternative hostnames to reference your gateways. You can use a service like *.localtest.me. So in your example, try opening tabs against http://gwa.localtest.me:9022 and http://gwb.localtest.me:9024 .. You should be able to maintain individual logins to those now that you're using different hostnames (each resolving to localhost / 127.0.0.1).

1 Like

Thanks, my mind was headed in that direction. However the docker containers are hosted on a project dev server, not on my local computer so something like *.localtest.me won't work for my use case. I can add multiple names to the hosts file for the same IP address on my computer (and will) but that provides a solution only for me and not a general solution for any/all team members that might access the docker containers on the same server (unless I have them do the same).

I suppose I could look deeper into something like implementing a reverse-proxy (traefik) on that server to route access to the various docker container provisioned services by name. I am not greatly familiar with implementing that, just aware of it. I believe that would rely on having name resolution working (e.g. DNS) and thus far we have just been using IP address with port connection to access the docker containers.

Does Chrome not recognize the port connection as distinguishing connections to different services?
e.g. <ip address>::8088 vs. <ip address>::9022

I don't think this is Chrome-specific, but rather how HTTP cookies are specified.

In particular:

Similarly, cookies for a given host are shared
across all the ports on that host, even though the usual "same-origin
policy" used by web browsers isolates content retrieved via different
ports.

3 Likes

In the meantime, you can get the equivalent via sslip.io. The URLs are a bit more cumbersome, but it will get you that same unique hostname.

1 Like

This fixed the same issue I was having on localhost while following through the Docker tutorial. Thanks!!