[REQUEST] Cal.com (formerly Calendso)

[avinyc]

23 hours ago, NexusEFR said:

Okay, I'll put some more APIs, but I tried to put the Ghipy and it didn't work well, I said I couldn't find it and that's why I thought it was only for paid cal.com licenses (the api was put inside the cal.com web console, not in docker variables, and that's what I did also with Google's,  many of them can be entered into the web console itself). 
I have the reverse proxy with NPM (Nginx proxy manager) and it works well in bridge mode with many more dockers that I have running (freescout, pingvin-share, projectsend, s-pdf,etc.) but I didn't know what was better to cal.com a custom dedicated network (local network ip range). And I've tried setting up cal.com with custom networking, but the login error still continues. 
Thanks again.

I started experiencing issues with the database and searched for the problem. I came across this issue on github:

 

https://github.com/calcom/docker/issues/329

 

The recommendation is to switch the image calcom/cal.com:latest with image: calcom/cal.com:v3.7.11 until they can figure out why the container is failing.  You were right to narrow down the problem starting with version v3.7.15 and I would stick to 3.7.11 for the time being.  I downgraded and zero errors in my logs now, so this should be the image to stick with while troubleshooting how to get your container running correctly.

[avinyc]

23 hours ago, NexusEFR said:

Okay, I'll put some more APIs, but I tried to put the Ghipy and it didn't work well, I said I couldn't find it and that's why I thought it was only for paid cal.com licenses (the api was put inside the cal.com web console, not in docker variables, and that's what I did also with Google's,  many of them can be entered into the web console itself). 
I have the reverse proxy with NPM (Nginx proxy manager) and it works well in bridge mode with many more dockers that I have running (freescout, pingvin-share, projectsend, s-pdf,etc.) but I didn't know what was better to cal.com a custom dedicated network (local network ip range). And I've tried setting up cal.com with custom networking, but the login error still continues. 
Thanks again.

I missed a note at the end of that issue, one commenter said a new variable needs to be added now:

 

DATABASE_DIRECT_URL="postgresql://postgres:@localhost:5450/calendso"

 

So we need to add this and keep the duplicate DATABASE_URL in our template also.  Looks like this change happened 2 weeks ago, but I haven't tested to see if this allows things to run correctly after v.3.7.11.

 

[NexusEFR]

On 2/23/2024 at 4:58 PM, avinyc said:

I missed a note at the end of that issue, one commenter said a new variable needs to be added now:

 

DATABASE_DIRECT_URL="postgresql://postgres:@localhost:5450/calendso"

 

So we need to add this and keep the duplicate DATABASE_URL in our template also.  Looks like this change happened 2 weeks ago, but I haven't tested to see if this allows things to run correctly after v.3.7.11.

 

Wow great! Works! Adding the environment variable does not give a login error on the page and works without giving prism or DB errors. Only notices of duplicate values continue to appear in the common.json as mentioned by mariushosting on GitHub.

Thank you for reporting this problem also in unraid, without your help I would not have been able to continue updating the platform. Best regards

[avinyc]

On 2/28/2024 at 5:49 AM, NexusEFR said:

Wow great! Works! Adding the environment variable does not give a login error on the page and works without giving prism or DB errors. Only notices of duplicate values continue to appear in the common.json as mentioned by mariushosting on GitHub.

Thank you for reporting this problem also in unraid, without your help I would not have been able to continue updating the platform. Best regards

Yep, i switched back to the latest tag and no prisma errors as well with the new variable added to the template.  The duplicate values in common.json are annoying in the logs, but I don't think it is causing any performance issues.  Let me know if you have any difficulty getting giphy or other apps running.

 

[NexusEFR]

On 3/1/2024 at 8:07 PM, avinyc said:

Yep, i switched back to the latest tag and no prisma errors as well with the new variable added to the template.  The duplicate values in common.json are annoying in the logs, but I don't think it is causing any performance issues.  Let me know if you have any difficulty getting giphy or other apps running.

 

 

Thanks, yes, the case is that the IDS, the Google API Keys if they work and I can connect Google calendars. But the Giphy API does not work, I thought it was precisely the docker in v3.7.11 and that with the new tag would be resolved. The Giphy API is in normal mode, not in production mode because I understand that it is not necessary, besides complicated to send the requirements that they ask. On the other hand, I still have some notices of NextJS, I hit you, you have any similar?

 

 

 

 

 

@calcom/web:start: [next-auth][error][JWT_SESSION_ERROR] 
@calcom/web:start: https://next-auth.js.org/errors#jwt_session_error "exp" claim timestamp check failed {
@calcom/web:start:   message: '"exp" claim timestamp check failed',
@calcom/web:start:   stack: 'JWTExpired: "exp" claim timestamp check failed\n' +
@calcom/web:start:     '    at exports.default (/calcom/node_modules/jose/dist/node/cjs/lib/jwt_claims_set.js:79:19)\n' +
@calcom/web:start:     '    at jwtDecrypt (/calcom/node_modules/jose/dist/node/cjs/jwt/decrypt.js:9:53)\n' +
@calcom/web:start:     '    at async Object.decode (/calcom/node_modules/next-auth/jwt/index.js:64:7)\n' +
@calcom/web:start:     '    at async Object.session (/calcom/node_modules/next-auth/core/routes/session.js:43:28)\n' +
@calcom/web:start:     '    at async AuthHandler (/calcom/node_modules/next-auth/core/index.js:165:27)\n' +
@calcom/web:start:     '    at async NextAuthApiHandler (/calcom/node_modules/next-auth/next/index.js:22:19)\n' +
@calcom/web:start:     '    at async NextAuth._args$ (/calcom/node_modules/next-auth/next/index.js:106:14)',
@calcom/web:start:   name: 'JWTExpired'
@calcom/web:start: }

 

These two are also usually out in the log console.

 

@calcom/web:start: Warning: data for page "/auth/login" is 140 kB which exceeds the threshold of 128 kB, this amount of data can reduce performance.
@calcom/web:start: See more info here: https://nextjs.org/docs/messages/large-page-data
@calcom/web:start: 12:49:09:827 WARNRateLimit Disabled due to not finding UPSTASH env variables
@calcom/web:start: [PERF]: getByViewer(1) took 57.60049295425415ms
@calcom/web:start: [PERF]: getByViewer(1) took 4.371723890304565ms
@calcom/web:start: [PERF]: getByViewer(1) took 7.092308044433594ms
@calcom/web:start: [PERF]: getByViewer(1) took 5.01249098777771ms
@calcom/web:start: [PERF]: getByViewer(1) took 4.469022035598755ms
@calcom/web:start: [PERF]: getByViewer(1) took 9.372783184051514ms
@calcom/web:start: 
@calcom/web:start:  ⚠ metadata.metadataBase is not set for resolving social open graph or twitter images, using "http://localhost:3000". See https://nextjs.org/docs/app/api-reference/functions/generate-metadata#metadatabase
@calcom/web:start: `themeBasis` is required for booking page theme support. Not providing it will cause theme flicker.
@calcom/web:start: react-i18next:: You will need to pass in an i18next instance by using initReactI18next

 

[avinyc]

1 hour ago, NexusEFR said:

 

Thanks, yes, the case is that the IDS, the Google API Keys if they work and I can connect Google calendars. But the Giphy API does not work, I thought it was precisely the docker in v3.7.11 and that with the new tag would be resolved. The Giphy API is in normal mode, not in production mode because I understand that it is not necessary, besides complicated to send the requirements that they ask. On the other hand, I still have some notices of NextJS, I hit you, you have any similar?

Did you upgrade the giphy api to production?  See instructions here: https://developers.giphy.com/docs/api

 

If you generated the secret keys for CALENDSO_ENCRYPTION_KEY and NEXTAUTH_SECRET correctly, maybe try this section I saw in the sample template here:

 

# - APP CREDENTIAL SYNC ***********************************************************************************
# Used for self-hosters that are implementing Cal.com into their applications that already have certain integrations
# Under settings/admin/apps ensure that all app secrets are set the same as the parent application
# You can use: `openssl rand -base64 32` to generate one
CALCOM_WEBHOOK_SECRET=""
# This is the header name that will be used to verify the webhook secret. Should be in lowercase
CALCOM_WEBHOOK_HEADER_NAME="calcom-webhook-secret"
CALCOM_CREDENTIAL_SYNC_ENDPOINT=""
# Key should match on Cal.com and your application
# must be 24 bytes for AES256 encryption algorithm
# You can use: `openssl rand -base64 24` to generate one
CALCOM_APP_CREDENTIAL_ENCRYPTION_KEY=""

 

[NexusEFR]

1 hour ago, avinyc said:

¿Actualizaste la API de giphy a producción? Vea las instrucciones aquí:  https://developers.giphy.com/docs/api

 

Si generó las claves secretas para CALENDSO_ENCRYPTION_KEY y NEXTAUTH_SECRET correctamente, tal vez pruebe esta sección que vi en la plantilla de muestra aquí :

 

 

The problem of putting in production the api of giphy is that they ask for a video where the environment is shown in production where it is displayed by sending a gif, I do not think that admits a capture of the screen where the api in cal. com... but something will try.
Regarding openssl keys, you mean to put the same in all these variables (adding new variables to the template unraid logically) as the variables used by CALENDSO_ENCRYPTION_KEY and NEXTAUTH_SECRET ? 
 

[avinyc]

23 minutes ago, NexusEFR said:

The problem of putting in production the api of giphy is that they ask for a video where the environment is shown in production where it is displayed by sending a gif, I do not think that admits a capture of the screen where the api in cal. com... but something will try.
Regarding openssl keys, you mean to put the same in all these variables (adding new variables to the template unraid logically) as the variables used by CALENDSO_ENCRYPTION_KEY and NEXTAUTH_SECRET ? 
 

Yeah I don't have giphy running on my instance, so I'm just taking guesses here on how to help.

 

For the variables, all of mine are uniquely generated for each one.

 

Use openssl rand -base64 32 to generate a key and add it under NEXTAUTH_SECRET.

Use openssl rand -base64 32 to generate a key and add it under CALENDSO_ENCRYPTION_KEY.

 

And then another 2 times for the following new ones:

 

Use openssl rand -base64 32 to generate a key and add it under CALCOM_WEBHOOK_SECRET

Use openssl rand -base64 24 to generate a key and add it under CALCOM_APP_CREDENTIAL_ENCRYPTION_KEY

 

[psweet]

Have you guys updated to the latest builds? I am trying to get this up and running but keep getting the following error despite everything I've tried.

 

@calcom/web:start: SyntaxError: Unexpected token . in JSON at position 8
@calcom/web:start:     at JSON.parse (<anonymous>)
@calcom/web:start:     at 855236 (/calcom/apps/web/.next/server/chunks/39209.js:11:4257)
@calcom/web:start:     at __webpack_require__ (/calcom/apps/web/.next/server/webpack-runtime.js:1:161)
@calcom/web:start:     at 139209 (/calcom/apps/web/.next/server/chunks/39209.js:1:175)
@calcom/web:start:     at __webpack_require__ (/calcom/apps/web/.next/server/webpack-runtime.js:1:161)
@calcom/web:start:     at __webpack_exec__ (/calcom/apps/web/.next/server/pages/_document.js:1:575)
@calcom/web:start:     at /calcom/apps/web/.next/server/pages/_document.js:1:608
@calcom/web:start:     at __webpack_require__.X (/calcom/apps/web/.next/server/webpack-runtime.js:1:2791)
@calcom/web:start:     at /calcom/apps/web/.next/server/pages/_document.js:1:588
@calcom/web:start:     at Object.<anonymous> (/calcom/apps/web/.next/server/pages/_document.js:1:652)

I swear I've tried everything, including the older 3.7.11 images you all said worked with the XML provided further up.

Any ideas?

[avinyc]

On 4/17/2024 at 12:06 AM, psweet said:

Have you guys updated to the latest builds? I am trying to get this up and running but keep getting the following error despite everything I've tried.

 

@calcom/web:start: SyntaxError: Unexpected token . in JSON at position 8
@calcom/web:start:     at JSON.parse (<anonymous>)
@calcom/web:start:     at 855236 (/calcom/apps/web/.next/server/chunks/39209.js:11:4257)
@calcom/web:start:     at __webpack_require__ (/calcom/apps/web/.next/server/webpack-runtime.js:1:161)
@calcom/web:start:     at 139209 (/calcom/apps/web/.next/server/chunks/39209.js:1:175)
@calcom/web:start:     at __webpack_require__ (/calcom/apps/web/.next/server/webpack-runtime.js:1:161)
@calcom/web:start:     at __webpack_exec__ (/calcom/apps/web/.next/server/pages/_document.js:1:575)
@calcom/web:start:     at /calcom/apps/web/.next/server/pages/_document.js:1:608
@calcom/web:start:     at __webpack_require__.X (/calcom/apps/web/.next/server/webpack-runtime.js:1:2791)
@calcom/web:start:     at /calcom/apps/web/.next/server/pages/_document.js:1:588
@calcom/web:start:     at Object.<anonymous> (/calcom/apps/web/.next/server/pages/_document.js:1:652)

I swear I've tried everything, including the older 3.7.11 images you all said worked with the XML provided further up.

Any ideas?

Two things, there is an issue with the docker images so they are not up to date yet, but the developers are working on a solution, see details here: https://github.com/calcom/docker/issues/347

 

As to the syntax error, please check your variables to make sure they are correctly added.  One person had a similar issue and it was an error due to the ALLOWED_HOSTNAMES variable: https://github.com/calcom/cal.com/issues/11330

 

You should be able to currently install up to version 3.9.1 and make sure you have the DATABASE_DIRECT_URL variable included in your configuration.

[psweet]

1 hour ago, avinyc said:

Two things, there is an issue with the docker images so they are not up to date yet, but the developers are working on a solution, see details here: https://github.com/calcom/docker/issues/347

 

As to the syntax error, please check your variables to make sure they are correctly added.  One person had a similar issue and it was an error due to the ALLOWED_HOSTNAMES variable: https://github.com/calcom/cal.com/issues/11330

 

You should be able to currently install up to version 3.9.1 and make sure you have the DATABASE_DIRECT_URL variable included in your configuration.

Wow, I spent hours debugging and looking through Github issues, and never in a million years did I consider that ALLOWED_HOSTNAMES had to be in quotes...

 

Thanks!