Add tzdata package for timezone

[yogeshbeniwal]

trafficstars

What does this PR do?

Closes #4040

What changes to the GraphQL/Database Schema does this PR introduce?

Does this PR introduce any new environment variables or feature flags?

If any indexes were added, were they added to INDEXES.md?

How do I test this PR?

How do we deploy this PR?

[netlify[bot]]

✅ Deploy Preview for gallant-galileo-14878c canceled.

Name	Link
🔨 Latest commit	f5b3b016367aa1dc2dc36827a1da59c49d761ad0
🔍 Latest deploy log	https://app.netlify.com/sites/gallant-galileo-14878c/deploys/630e4bd8afd3f300094122e9

[nick-funk]

Thanks for contributing to Coral, we love seeing open source patch requests!

I'm a little confused as to why you need to set a timezone on the Docker container. We store the dates for all the comment data in Mongo as UTC and the front-end client translates those dates from UTC to whatever timezone the user is viewing from via <RelativeTime></RelativeTime> and similar UI components.

What is your goal of trying to get the Docker container to run in a different timezone? If I knew what use-case this was for, I could test what the issue was and probably approve this or provide a fix via another fix PR.

[yogeshbeniwal]

@nick-funk This is to try to resolve #4041. OpenID login with Azure AD B2C Integration is resulting in INTERNAL_ERROR: TOKEN_INVALID: jwt not active error. Similar problems stated over forums suggest that this may be because of time difference between host machine and Azure B2C.

[nick-funk]

@nick-funk This is to try to resolve #4041. OpenID login with Azure AD B2C Integration is resulting in INTERNAL_ERROR: TOKEN_INVALID: jwt not active error. Similar problems stated over forums suggest that this may be because of time difference between host machine and Azure B2C.

I could be wrong, but I don't believe it is due to a timezone difference on the container. When we sign and verify the tokens we use date.getTime() / 1000 which irrespective of timezone will always store, generate, and validate tokens by a unix epoch which has no timezone since it's an integer of seconds since 00:00:00 1970-01-01 UTC.

I believe it is more likely that Azure AD B2C is using a different spec implementation of OIDC that is incompatible with our implementation of OIDC. We do not support connecting to Azure Active Directory as their implementation of OIDC differs largely from Google's and that is the spec we primarily support.

For instance, Azure AD OIDC requires you to support client_secret_post in the token_endpoint_auth_methods_supported which we do not implement for Coral's OIDC, we only support private_key_jwt.

This is likely causing our verifier to reject the token you're providing as it will not work with our OIDC flow. We implemented the minimal OIDC flow to ensure that Coral is not managing user data or handling host site secrets. This was to ensure that Coral kept its fingers out of any of our SaaS customers sensitive key info.

Another thing that makes me feel like timezone settings isn't the issue is we have many clients and our own instances which are using OIDC in America/New_York and we have no issues when they follow the minimal spec or use Google OIDC to connect to it. It's a regular part of our auth testing and it is working fine for us and our SaaS clients.

I could be wrong though, so I will check again that OIDC + New York instances works with our supported OIDC connectors.

[yogeshbeniwal]

@nick-funk Thank you for making effort to test with Azure B2C, moving to Google OIDC will require effort to move other apps in addition to Coral Talk. Looking forward for your result before making decision.

[yogeshbeniwal]

@nick-funk Could you check on it? Pls let me know.

[losowsky]

hi yogesh,

The package you're adding seems to have several security vulnerabilities, so we have to reject this. Beyond that, the issue you're reporting just isn't one that we've faced, despite having customers and open source users running this in every major continent, and we can't pledge to support all versions of OIDC due to the complexities that result.

I'm afraid we're not going to merge this or address it further. Thanks again for reporting and trying to resolve. Best wishes.

[losowsky]

Hi Yogesh, we designed Coral to work with all the major identity providers. Our customers and open source users usually have their own identity providers already, and Coral should work with them all.