[gateway] CSRFHandler seems not handle proxy context-path

[Adito5393]

I am setting the email configuration in 2 containers: graviteeio/am-management-api & graviteeio/am-gateway (mainly, because I don't know exactly which one is responsible for sending email when a user registers in the AM website within a specific security domain). Following the GitHub platform v3.x example, I have this relevant code in the docker-compose:

am_gateway:
    image: graviteeio/am-gateway:3
    environment:
      # SMTP configuration used to send mails
      - gravitee_email_enabled=true
      - gravitee_email_host=smtp.gmail.com
----------more code---------
am_management:
    image: graviteeio/am-management-api:3
    environment:
      - gravitee_email_enabled=true
      - gravitee_email_host=smtp.gmail.com

Following the technical API guide, within the docker container, I obtain:

1. am_gateway:
   /opt/graviteeio-am-gateway # echo $gravitee_email_enabled
true
/opt/graviteeio-am-gateway # echo $gravitee_email_host
smtp.gmail.com
curl http://admin:adminadmin@localhost:18092/_node/configuration
"email.enabled" : false,
"email.host" : "smtp.my.domain",
2. am-management-api:
   /opt/graviteeio-am-gateway # echo $gravitee_email_enabled
true
/opt/graviteeio-am-gateway # echo $gravitee_email_host
smtp.gmail.com
curl http://admin:adminadmin@localhost:18093/_node/configuration
"email.enabled" : false,
"email.host" : "smtp.my.domain",

Expected Behavior

The curl of the /_node/configuration should match with the docker-compose environment settings.

Current Behavior

The curl of the /_node/configuration does not match with the docker-compose environment settings.

Steps to Reproduce (for bugs)

1. Git clone the platform v3.x example
2. Set the email config via the docker-compose environment value
3. Check that the value is set within the AM component: am-gateway or am-management-api

Context

This issue leads to new users unable to register within a specified security domain:

1. Navigate to: https://am.gravitee.io/auth/SECURITYDOMAIN/register?client_id=**********
2. Fill in info & click register. Error from the chrome console: Failed to load resource: the server responded with a status of 403 ()

Your Environment

• Version used: AM 3.0.3
• Browser Name and version: Chrome Version 83.0.4103.116 (Official Build) (64-bit)
• Operating System and version: Ubuntu 18.04.4 LTS; running Docker version 19.03.11, build 42e35e61f3

[tcompiegne]

Hi @Adito5393 ,

I think the email configuration is correctly loaded but the /_node/configuration only display the content of the gravitee.yml file, it's related to this issue #3419

The node dependency is currently not update to date for the AM v3.

The 403 response is not related to the email settings. Do you have more logs ?

[Adito5393]

I've checked all 3 AM containers and none of them generate any logs from the register of a user action (based on the timestamp of the displayed logs).

Could you run the platform docker-compose example, define an AM security domain and register a new user at URL: https://am.gravitee.io/auth/SECURITYDOMAIN/register?client_id=********** ?

Or advice on how to provide the logs?

[tcompiegne]

Can you try with the Incognito mode (private browsing) ?

[Adito5393]

I usually use the Incognito mode. Here's a screenshot:

Is it helpful?

Could you reproduce the issue using a clean build from the docker-compose platform example?

@tcompiegne I've managed to reproduce the error on your nightly version server
Give it a try and let me know if you manage to register a new user in any application.

Or just skip to the register link of the WEB application I've created: TestRegisterNewUser register link

[Adito5393]

@tcompiegne @brasseld Could you guys manage to reproduce the error or it is my setup faulty?

[jhaeyaert]

In addition, the problem is indeed due to csrf cookie which is not set with the appropriate path.

In this case, cookie path should be /gateway/gravitee (not just /gravitee). The CookieHandler is already responsible of setting the appropriate path using the X-Forwarded-Prefix header but it is currently not enabled on this path (eg: /register). The solution is to enable CookieHandler globally to fix this issue and be sure that all cookies will now be rewritten for all paths.