cronofy / cronofy-node Goto Github PK

Hi,
Recently we tried upgrading the cronofy package we use in our application to version 3.0.1, but this resulted in almost all google calender id's to be encoded incorrectly in the cronofy API requests.
We reverted to version 2.5.1 to quickly fix this.
We tried debugging and it seemed that the query string transformation (here: https://github.com/cronofy/cronofy-node/blob/master/src/index.js#L39-L43) has some trouble, when a request is made with an array of id's.

A request like:

• GET /v1/events?calendar_ids[0]=cal_WadMsTnUCBCpAAEQ_pRJpqAObLfeK0n@ZueaiwQ&tzid=Etc/UTC
  would get transformed to:
• GET /v1/events?calendar_ids%5B0%5D=cal_WddMsTnUCBCPAAed_pRJpqAObLfeK0n%40ZueaiwQ&tzid=Etc%2FUTC
  Is this a known issue?

https://github.com/cronofy/cronofy-node#refreshaccesstokencallback

this doc lacks the parameter of options wich is crucial.

This is according to the documentation, and confirmed with testing.

Hey there, I noticed that when managing multiple large calendars for one user it takes a while to paginate and fetch all events using client.readEvents.

It's already useful to be able to specify date range but it would also be great if we could specify the calendar_id to do the filtering server-side.

There already seems to be a way to do it with the REST API:

https://www.cronofy.com/developers/api/#read-events-calendar_ids[]

Not sure what happened but I assume the build command did not run somehow and now I get type errors on the import keyword on node 4.5.x

Whenever I try to get an auth token, I am seeing this error.

Is this common? What might be causing me to not be able to authenticate a user?

Code: (with the id and secret from the cronofy website replaced with placeholders.)

app.get('/cal',function(req,res){
  var options = {
    client_id: 'CLIENT_STRING',
    client_secret: 'CLIENT_SECRET',
    grant_type: 'authorization_code',
    code: req.query.code,
    redirect_uri: 'http://localhost:5000'
  };


  cronofy.requestAccessToken(options)
      .then(function(response){
          console.log(response);
          res.json(response);
        });

});

In the using example there is a minor issue with quotes in this line:

client_secret: 'aPPwd-ASDFAsdfasdfasdfsadfasdfASDFSADF_asdfasdfasdf"

Is there a way to call the oauth/authorize API within this lib? Didn't find it in the source.

When trying to create an event, I get a 403 error. Based on the doc https://docs.cronofy.com/developers/api/events/upsert-event/#status-403 I need to request auth again.

Maybe am missing something.

Thanks for your input!

rest lib is always called giving an entity, even for GET resources.
E.g. for GET /v1/events the from and tzid (and all other optional parameters) are given in the body of the GET (weird, but seems to work), and fails to parse for example the include_managed param.

I open a PR for the fix to use params when GET method rest doc

When I try to use

https://app.cronofy.com/oauth/authorize
?response_type=code
&client_id={CLIENT_ID}
&redirect_uri={REDIRECT_URI}
&scope={SCOPE}
&state={STATE}

This returns us a code which is used to obtain an access token and after that a new 'sub' is created and now when I try to add multiple calendars then it gets added to the same sub which is perfectly fine as "app.cronofy.com" sessions gets maintained until then, now when I try to login in my application again with another user, then it keeps on adding the calendars in the same subId which is not desired, I do not wish to add it because these addition of calendars should be added to new 'sub'

Then after investigation found that there is another param 'avoid_linking' which when set true creates new 'sub' at every call, but this does not add calendar to a particular sub but creates a new sub everytime.

My requirement here is to create a 'sub' for each user of my application, I can store the account_id somewhere with me in my DB for that user, and now if the user tries to add a calendar then it should must be added to the same sub rather than creating a new one.

@warbrett HI ,
I am not able to run the Code https://github.com/cronofy/cronofy-node

Steps Fallowed:

Clone the Code
install npm
npm test
getting error

Add createCalendar function

Attaching a PR

Not sure what happened but the published build folder does not contain the latest changes.
Could you publish a patch version with the correct build asap?

Running snyk test on an application using [email protected] reports a high severity vulnerability:

✗ Prototype Pollution [High Severity][https://snyk.io/vuln/SNYK-JS-AJV-584908] in [email protected]
    introduced by [email protected] > [email protected] > [email protected] > [email protected] and 2 other path(s)
  This issue was fixed in versions: 6.12.3

As request package is deprecated and no longer receiving updates, the best option is to replace request with another library that does not include vulnerabilities.

In createEvent, the wrapper is posting to https://api.cronofy.com/v1/calendars instead of https://api.cronofy.com/v1/calendars/__calendarId__/events, resulting in an error.

View the API docs at: https://www.cronofy.com/developers/api/#upsert-event

The API wrapper is doing a POST instead of a DELETE.

Are you planning to add support for typescript types @victor-cronofy ?

The documentation for refreshAccessToken() lists the options as follows:

Options Object
client_id - Your client id.
client_secret - Your client secret.
grant_type - a string of "refresh_token".
refresh_Token - The refresh token for the user.

However the refresh token must be passed in as refresh_token or the request will fail.

All the functions in this library modify the options object passed in as an argument to inject one or more additional properties. If this object is then re-used, the injected value will override any value set on the client itself.

The place where I ran into this bug is in code designed to catch when the token expires and automatically refresh the token, then re-execute the function. I wrap all relevant calls it the library with a function that catches 401 responses, refreshes the token and then re-executes the call:

export async function callWithTokenRefresh(
  userId: string,
  accountId: string,
  client: Cronofy,
  method: Function,
  args: any[],
  retryCount: number = 0,
) {
  try {
    return await method.apply(client, args);
  } catch (e) {
    if (e.statusCode !== 401) {
      throw e;
    }
    else if (retryCount > 1) {
      throw new HttpsError('permission-denied',
                           `Too many retries trying to refresh token for user ${userId}`);
    }

    await refreshAccessToken(userId, accountId, client);

    return await callWithTokenRefresh(userId, accountId, client, method, args, retryCount + 1);
  }
}

What this code does is to attempt to call a function on cronofy-node. If it receives a 401 error, it refreshes and saves a new acccess token, then attempts the call again.

The second call was failing, however, because the wrong access_token was being provided. I finally tracked it down to the options argument in args being modified by cronofy-node to add an access_token key, which was then used instead of client.config.access_token (which had the correct updated access token).

This bug report is just to document the bug. I'll be submitting a PR in a minute that fixes the issue.

$ yarn add cronofy
yarn add v0.27.5
info No lockfile found.
[1/4] Resolving packages...
error Received malformed response from registry for undefined. The registry may be down.
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

npm install cronofy is fine.

Errors need to be more consistent, currently returning rejected rest promises.

We experienced some unexpected behavior recently when using the undocumented client.availability(...) endpoint.

Based on the source code, it appears that bearer_token: "<client-secret>" may be used to achieve application authentication. Unfortunately this can be problematic because requests will use config.access_token instead if it's been defined. We don't initialize the client with an access_token, but ultimately we realized that the refreshAccessToken method will populate config.access_token on its own.

So the result is that availability(...) works the first time, but if refreshAccessToken is used, a subsequent call to availability(...) may use an expired access token (or potentially one for a user that's not even involved in the availability request).

This seems potentially OK since there's no documentation around passing in bearer_token, but I did want to clarify if there's a best practice here or anything I might be missing.

1. Do we need to refresh access tokens for all users included in an availability request? (we haven't observed this to be necessary)
2. Our solution is to pass access_token: "<client-secret>" to the availability(...) request. Does this sound like the right approach, or would it be better to use an access_token of one the users included in the request?

Thank you!

I would like to be able to change details of an event, but I can only delete and create events.
So when I update for example the time, do I have to delete the event and create a new event with the same id?

What about the metadata which is maybe only in the original agenda provider?

If I specify an array of calendar_ids[] for the free-busy function, it produces a request with a parameter like: calendar_ids[]=cal_calendar_a_id%2Ccal_calendar_b_id
which doesn't work. It gets interpreted as one calendar_id with a comma in the middle, which doesn't exist. I think the calendar_ids[] parameter should be specified once for each element.

I updated to v 2.3.2 from 1.3.0 making adjustment to call constructor. But I get the following error. Do I need to pass extra parms/options now or ideas ?

    api: 'https://api' + (config.dataCenter ? '-' + config.dataCenter : '') + '.cronofy.com'
                                ^
.../node_modules/cronofy/src/index.js:21
    api: 'https://api' + (config.dataCenter ? '-' + config.dataCenter : '') + '.cronofy.com'
                                ^

TypeError: Cannot read property 'dataCenter' of undefined
    at new cronofy (.../node_modules/cronofy/src/index.js:21:33)
    at .../run/compiled_dev/parts/hat_node/cronofy.js:12:29
    at ContextifyScript.Script.runInThisContext (vm.js:44:33)
    at Object.runInThisContext (vm.js:116:38)
    at nodeGlobalRequire (.../run/compiled_dev/parts/goog/bootstrap/nodejs.js:87:6)
....
Process finished with exit code 1```

My use case:
A user can import a CSV file which represents all events for a given week (or a day). My app creates managed events via the createEvent API. Also so the user can reload the events (user can modify events outside the calendar and then produce an updated CSV) I use the deleteEvent API to clear existing events in the target date range.

For a full cycle I currently need to:

• listEvents to get all event_id for each existing managed event.
• For each event listed issue deleteEvent (about 1 sec per round trip)
• For each new event from CSV use createEvent (about 1 sec per round trip)
• For an average of 30 events in a CSV this represents an operation that takes a minute.

Please consider better support for bulk events in the API:

• augment the bulk event delete to also allow optional date range, same as list events
• alternately consider augmenting deleteEvent to support optional list of event ids
• augment createEvent to take list of events or create a bulk create event API

I realise this is not a cronofy-node specific issue and would require support in the underlying cronofy API but that's not OSS as afaict.

I find it curious that when running the availability queries (https://docs.cronofy.com/developers/api/scheduling/availability/) that the query_period params do not accept a standard JS ISO format, ie (new Date()).toISOString() as it is supposedly compliant with the ISO 8601. In my testing the following works

Using dayjs library, dayjs().format()
2022-02-10T16:20:35-05:00
2022-02-10T18:59:59-05:00

Using dayjs library, dayjs().utc().format()
2022-02-10T21:20:35Z
2022-02-10T23:59:59Z

But not (new Date()).toISOString())
2022-02-10T21:20:35.000Z
2022-02-10T23:59:59.999Z

So who is not following the standard? Cronofy or Javascript?

If you provide a next page option https://github.com/cronofy/cronofy-node/blob/master/src/index.js#L183 (which I get back from the api in a previous call)
It will still prefix the provided path with the cronofy host here https://github.com/cronofy/cronofy-node/blob/master/src/index.js#L28

I think the easiest solution is to just see if the next page options starts with this.urls.api and then cut it off.

If you set the 'next_page' option, the request is made to .
-->'https://api-de.cronofy.comhttps://api-de.cronofy.com/v1/free_busy/pages/pageId'

The exact same code (but with readEvents()) works fine.

Code:
let freeBusy = [];

const options = {
from: moment().toISOString(),
to: moment().add(1, 'day').toISOString(),
tzid: this.tzid
};

while(true) {
const freeBusyList = await this.cronofyClient.freeBusy(options);
freeBusy = freeBusy.concat(freeBusyList.free_busy);

/*
Fails at 2nd run with error:
{ url: 'https://api-de.cronofy.comhttps://api-de.cronofy.com/v1/free_busy/pages/pageId',
entity: undefined } }
*/

options['next_page'] = freeBusyList.pages.next_page || null;
if (!freeBusyList.pages.next_page) {
break;
}
}

revokeAuthorization docs should say it requires token key in options object

Hi folks! 👋🏼

I think we're missing the available periods endpoint.

If you want I can open a PR with that, just let me know! 😄