Uploaded image for project: 'Red Hat 3scale API Management'
  1. Red Hat 3scale API Management
  2. THREESCALE-8523

Resolve deprecation warnings from DomainSubstitution

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Done
    • Icon: Major Major
    • 2.13.0 GA
    • None
    • System
    • None
    • False
    • None
    • False
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • No

      Context

      In any debugging environment development or preview,

      • database has account super domain set to example.com
      • you access the UI or with another super domain like proxied-domain.com

      You still want to point your browser to *http://provider-admin.proxied-domain.com*
      and expect it to work.

      In a "proxied" request, we used to monkey patch request.host with
      ThreeScale::Middleware::DevDomain and ThreeScale::DevDomain, leading to:

      • weird behavior
      • feature needing to know the environment.
        Is it preview or development or production?
      • monkey patching feature to make it testable locally or in preview
      • library failures in preview (sidekiq-web not working well)

      Using a prroxy as a solution?

      Why not using a proxy (e.g. nginx) to replace the URL?

      Well, it would not work for server responses.
      When the code is using account.domain or the likes, it will then use
      provider-admin.3scale.net instead of provider-admin.example.com

      Features that do not work well

      • sidekiq web and any middleware that relies on request.host
      • email views will render link with the incorrect domain:
        url are rendered with host: account.domain
      • service discovery Authentication needs to craft some the url
        with :host option
      • SSO login will not work for the same reason
      • whenever you use url_for(host: account.domain) there is an issue

      So what solution?

      This module adds some convenient methods to be used in the correct context
      i.e. the writer will have the responsibility to use the correct method

      • {Account#external_domain}

        or

        {Account#internal_domain}
      • {Account#external_admin_domain}

        or

        {Account#internal_admin_domain}

      Most of the use cases:

      • in the context of a request, use Account#internal_* methods
      • in the context of a response, use Account#external_* methods

      Examples:

      Config file: config/domain_substitution.yml

            development: 
              enabled: true
              request_pattern: "\\.proxied-domain\\.com"
              request_replacement: ".example.com"
              response_pattern: "\\.example\\.com"
              response_replacement: ".proxied-domain.com"
        
      

      In Ruby:

            request.host
            # => provider-admin.proxied-domain.com
        
            request.internal_host
            # => provider-admin.example.com
        
            account.provider?
            # => true
        
            account['domain']
            # => "provider.example.com"
        
            account['self_domain']
            # => "provider-admin.example.com"
        
            account.external_domain
            # => "provider.proxied-domain.com"
        
            account.external_admin_domain
            # => "provider-admin.proxied-domain.com"
      

              Unassigned Unassigned
              jgallaso Jose Miguel Gallas Olmedo
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: