How to make frontend send cookies to backend?

[human-77]

This may seem as a strange question, as blockscout is meant for public networks, but we are using it within our company and we wanted to implement an authentication system around it.

Basically, we have configured 2 nginx servers, one in front of the fronted and another in front of the backend. When a request comes in, we use a subrequest to authenticate it on our authenticator server, redirecting the request and it's cookies, if the answer is 200, nginx allow the request to pass, otherwise, redirect user to login page.

It works perferctly on the frontend page, however it does not work on the backend, because the fetch functions do not use the 'include' option, as can be seen here (that is, the code doesn't forward the cookies) so my frontend can't call the APIs of the backend.

Is there any way to enable the forwarding of cookies? If no, is there any plan of bringing this in the future? How can I suggest this as a feature?

server {
    listen       {{ .Values.frontend.service.port }};
    server_name  {{ .Values.frontend.proxy.env.SERVER_NAME }};
    proxy_http_version 1.1;

    location / {
        # CHECKING COOKIES
        proxy_set_header Cookie $http_cookie;
        auth_request /auth_check;
        error_page 400 401 402 403 405 500 501 502 503 504 = /unauthorized;

        proxy_pass            https://my-app.com; 
    }

    location = /auth_check {
        proxy_pass                     https://authentication-server.com;
        proxy_set_header Content-Type application/json;
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
    }

    location /unauthorized {
        return 301 https://login-endpoint.com;
    }
}

[tom2drum]

Hi @human-77. I believe you are referring to the credentials option for the fetch function. If so, the correct place to check in the code is here. Currently, we use cookies solely for authorization purposes in the user account within the explorer. Therefore, we do not send them by default in cross-origin requests. Is your frontend app and backend app hosted on the same origin?

[human-77]

Hi, @tom2drum !

1 - No, the frontend app and backend app are on different domains, but, we change it so they use the same nginx.

2 - We don't want the account function, we want the info in blockscout to be public, which is why we are protecting behind a login. From what you said, I understand the there is no such function in the calls to the blockscout API itself (where we need the cookies to be send in order to protect the data), Am I correct?

[tom2drum]

1 - I see
2 - Yes, correct.

We've added a condition to include cookies only when the account feature is present in the app to simplify setup. If cookies are sent by default, the server must set the appropriate headers, Access-Control-Allow-Credentials and Access-Control-Allow-Origin, if it operates on a different origin.

[human-77]

Wait, so, if we enable the account configuration... it would start using the 'include' function? If yes, I think that is worth a try, I will update if that works!

Access-Control-Allow-Credentials and Access-Control-Allow-Origin

We know, the code I posted was simplified to not clutter the post with unnecessary detail.

[tom2drum]

Yes, that should work. I apologize for this workaround. We are considering adding a separate ENV variable to control this behavior.

[human-77]

For anyone keeping up with this thread, I have tried to activate the account feature, as suggested by tom2drum and it worked, however, the app is still rough on the edges, so we are smoothing things a bit.

Once we have solved the remaining problems I will do a complete explanation, but, if you are working on the cloud, I suggest that is easier to use the same nginx for both the frontend and blockscout.

[human-77]

Solution:

The first step was enable the usage of accounts in the frontend, we did that by:

NEXT_PUBLIC_IS_ACCOUNT_SUPPORTED: "true"
NEXT_PUBLIC_RE_CAPTCHA_APP_SITE_KEY: "12312121213131"

We are not using captcha but it wouldn't enable "my account" without a string there.

After that, we edited the proxy of the backend (blockscout itself) as bellow:

server {
          listen       8080;
          server_name  {{ .Values.blockscout.proxy.env.SERVER_NAME }};
          add_header 'Access-Control-Allow-Origin' '{{ .Values.blockscout.proxy.env.CORS_ORIGIN }}' always;
          proxy_http_version 1.1;
          
          location / {
              # CHECKING COOKIES
              proxy_set_header Cookie $http_cookie;
              auth_request /auth_check;
              error_page 400 401 402 403 405 500 501 502 503 504 = /unauthorized;
              proxy_pass            {{ .Values.blockscout.proxy.env.SERVICE_APPLICATION }};
              ...REST OF CONFIGURATION...
          }

          location = /auth_check {
            proxy_pass {{ .Values.blockscout.proxy.env.AUTHENTICATION_API}};
            proxy_set_header Content-Type application/json;
            proxy_pass_request_body off;
            proxy_set_header Content-Length "";
          }

          location /unauthorized {
            return 301 {{ .Values.blockscout.proxy.env.LOGIN_ENDPOINT }};
          }
}

We tried using the exact same configuration in the frontend proxy, however, for some reason, it kept getting a CORS error. After many failed attempts we decided to use the proxy of the frontend as a reverse proxy, creating a redirect endpoint. In other words, we configured our endpoint to call itself rather than the blockscout directly and we used the endpoint location ~ ^/(api|socket... to redirect calls to the actual blockscout:

server {
          listen       {{ .Values.frontend.service.port }};
          server_name  {{ .Values.frontend.proxy.env.SERVER_NAME }};
          proxy_http_version 1.1;

          location / {
              # CHECANDO COOKIES
              proxy_set_header Cookie $http_cookie;
              auth_request /auth_check;
              error_page 400 401 402 403 405 500 501 502 503 504 = /unauthorized;
              proxy_pass            {{ .Values.frontend.proxy.env.SERVICE_APPLICATION }};
              ...REST OF CONFIGURATION...
          }

          location = /auth_check {
            proxy_pass {{ .Values.frontend.proxy.env.AUTHENTICATION_API}};
            proxy_set_header Content-Type application/json;
            proxy_pass_request_body off;
            proxy_set_header Content-Length "";
          }

          location /unauthorized {
            return 301 {{ .Values.frontend.proxy.env.LOGIN_ENDPOINT }};
          }

          location ~ ^/(api|socket|sitemap.xml|auth/auth0|auth/auth0/callback|auth/logout) {
              proxy_pass                        "https://{{ .Values.frontend.proxy.env.BLOCKSCOUT_DOMAIN }}";
              proxy_set_header Host             {{ .Values.frontend.proxy.env.BLOCKSCOUT_DOMAIN }};
              proxy_set_header X-Real-IP        $remote_addr;
              proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;

              # WebSocket headers
              proxy_http_version                1.1;
              proxy_set_header Upgrade          $http_upgrade;
              proxy_set_header Connection       "upgrade";

              # Forward cookies
              proxy_pass_request_headers        on;
              proxy_cookie_domain               {{ .Values.frontend.proxy.env.SERVER_NAME }} {{ .Values.frontend.proxy.env.BLOCKSCOUT_DOMAIN }};
              proxy_hide_header                  Access-Control-Allow-Origin;
          }
}

Albeit slower at times, it works perfectly.

We are still looking towards an enviroment variable to control de usage of 'include' in the fetch requests. Thank you for the help!