Digikey Oauth provides http:// redirect_uri

[bson]

Describe the bug

I've create an org and app at DK, and obtained the keys and set them up.

When I go to the information provider list and click to connect DK, it produces this request:

https://api.digikey.com/v1/oauth2/authorize?state=b6425636c1ca271e47564eebc6def6e2&response_type=code&approval_prompt=auto&redirect_uri=http%3A%2F%2Fpartdb.rockgarden.net%2Fen%2Foauth%2Fclient%2Fip_digikey_oauth%2Fcheck&client_id=5JdYArKQuzlF6xXw0xqgcXjVGhlWTCFr

The redirect_uri is an http:// URL which the DK API doesn't like. The result is a 400 with this in the body: {"ErrorCode" : "invalid_request", "Error" :"Invalid redirection uri http://partdb.rockgarden.net/en/oauth/client/ip_digikey_oauth/check"}

If I change the request to have an https:// redirect_uri and rerun it it succeeds on the DK end, but then Part-DB fails the redirect url with a 500 when hit by the browser. (This looks looks like bog standard 3-legged Oath 2.0.) Part-DB provides no particular information other than the generic fail screen and a suggestion to look in var/log/prod.log, which is empty.

Is this actually a bug, or did I misconfigure something? How is it deciding to use a non-https redirect_uri in the first place? The browser is connected to the server using SSL, using a valid Let's Encrypt server cert, so it's not clear where it's getting it from...

[jbtronics]

How is it deciding to use a non-https redirect_uri in the first place?

This happens, if symfony router cannot decide what the access schema is. If you are using reverse proxy, you must configure its IP as trusted proxy and need to ensure, that the reverse proxy gives a x-forwarded-proto header to Part-DB

[jbtronics]

Part-DB provides no particular information other than the generic fail screen and a suggestion to look in var/log/prod.log, which is empty.

If you are using docker, then the logs are available via docker logs, as they get printed to stderr, instead of the log file.

[bson]

Okay, since Synology Web Station can't properly populate headers I set up an SSL (HSTS) reverse proxy on port 8080 to forward directly to the container (at 172.17.0.2:80), with the headers X-Forwarded-Proto and X-Forwarded-Host hard-wired. Here's what I see in the log:

172.17.0.1 - - [24/Aug/2024:19:19:45 +0000] "GET /en/oauth/client/ip_digikey_oauth/connect HTTP/1.1" 302 2035 "https://partdb.rockgarden.net:8080/en/tools/info_providers/providers" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36"

It sends me to:

https://api.digikey.com/v1/oauth2/authorize?state=c204724fd20360be76a8660601e09678&response_type=code&approval_prompt=auto&redirect_uri=http%3A%2F%2Fpartdb.rockgarden.net%3A8080%2Fen%2Foauth%2Fclient%2Fip_digikey_oauth%2Fcheck&client_id=xxxxxxxxxx

• which has an http redirect_uri.

Here's the 400 error body I get from DK:

{"ErrorCode" : "invalid_request", "Error" :"Invalid redirection uri http://partdb.rockgarden.net:8080/en/oauth/client/ip_digikey_oauth/check"}

So it got the port host name but STILL picks http... I wonder if this is entirely due to it being on port 80 using HTTP?

Maybe the easiest here would be to simply define the OAuth redirect server host name in the env, similar to how it's done for email and other uses.

Here's the nginx reverse proxy config generated, in its entirety. I don't see anything wrong here...

server {
    listen 8080 ssl;
    listen [::]:8080 ssl;

    server_name partdb.rockgarden.net ;

    if ( $host !~ "(^partdb.rockgarden.net$)" ) { return 404; }

    include /usr/syno/etc/www/certificate/ReverseProxy_c5f162c2-fe2f-4675-8ad3-9954eeffe1d3/cert.conf*;

    include /usr/syno/etc/security-profile/tls-profile/config/ReverseProxy_c5f162c2-fe2f-4675-8ad3-9954eeffe1d3.conf*;

    add_header Strict-Transport-Security "max-age=15768000; includeSubdomains; preload" always;

    proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

    include conf.d/.acl.7c0a474e-15ab-46ab-855d-19ea41c12b18.conf*;

    location / {

        proxy_connect_timeout 60;

        proxy_read_timeout 60;

        proxy_send_timeout 60;

        proxy_intercept_errors off;

        proxy_http_version 1.1;

        proxy_set_header        X-Forwarded-Host            partdb.rockgarden.net:8080;

        proxy_set_header        X-Forwarded-Proto            https;

        proxy_set_header        Host            $http_host;

        proxy_set_header        X-Real-IP            $remote_addr;

        proxy_set_header        X-Forwarded-For            $proxy_add_x_forwarded_for;

        proxy_pass http://172.17.0.2:80;

    }

    error_page 403 404 500 502 503 504 /dsm_error_page;

    location /dsm_error_page {
        internal;
        root /usr/syno/share/nginx;
        rewrite (.*) /error.html break;
        allow all;
    }

}

[jbtronics]

Have you configured the TRUSTED_PROXIES env for part-db correctly?

[bson]

Have you configured the TRUSTED_PROXIES env for part-db correctly?

Ooooh, this makes it work!

TRUSTED_PROXIES=127.0.0.0/8,::1,10.0.0.0/8,172.16.0.0/12

This should probably be automatically set in any docker image...

[jamesn81]

Thanks heaps for posting thisTRUSTED_PROXIES ENV solution ... got my setup behind Caddy working perfectly after being confused as to why it was throwing http:// all the time!

[jayalcock]

Have you configured the TRUSTED_PROXIES env for part-db correctly?

Ooooh, this makes it work!

TRUSTED_PROXIES=127.0.0.0/8,::1,10.0.0.0/8,172.16.0.0/12

This should probably be automatically set in any docker image...

This worked perfectly, thank you!

[mkne]

Can this issue be closed? It seems to be solved.

[bson]

Is it actually solved? I had to add TRUSTED_PROXIES again after upgrading to 2.0.2... Why not put it in the system configuration at least so it can be retained over the next docker image update? (I assume the system configuration settings are stored in the DB.) I'll create an enhancement ticket...