[calendar3-cli] Insufficient authentication scopes for calendar ids with a #

[shaicoleman]

It seems like the calendar3 events list command doesn't handle correctly calendar IDs containing a hash

$ calendar3 events list "en-gb.irish#holiday@group.v.calendar.google.com"
Bad Request (403): Request had insufficient authentication scopes.
    global: Insufficient Permission, insufficientPermissions

I tried running mitmproxy to see what's happening, and it's trying to access this URL: https://www.googleapis.com/calendar/v3/calendars/en-gb.irish?alt=json.

It seems that it's truncating everything after the hash. The workaround is to percent encode the hash:

$ calendar3 events list "en-gb.irish%23holiday@group.v.calendar.google.com" | jq .kind
"calendar#events"

[Byron]

Thank for trying the CLI, and I love that mitmproxy debug work, somehow I didn't think it was possible to intercept these calls.

I traced the parameter (containing the '#') to this line which is where the URL is parsed back from a string. There I believe the truncation happens.

When looking at how this calendar ID is used, it gives me this:

        let mut url = self.hub._base_url.clone() + "calendars/{calendarId}/events";

So apparently for this to work the calendar ID must be escaped in some way to be valid within the URLs path.

Is this something you could try locally to see if that works? If so, we could make this work for all APIs.

[shaicoleman]

I don't have any Rust experience, but I googled the top Rust web framework, which seems to be Rocket, and I checked how it handles it - via the percent-encoding crate.

https://github.com/SergioBenitez/Rocket/commit/3bf577db6e36f1a859fc708fb46fc0b2f3467edb

https://rust-lang-nursery.github.io/rust-cookbook/encoding/strings.html

But it might just be simpler to do a search and replace, # => %23 # may be the only character that needs to be encoded

[Byron]

@shaicoleman Great, that should do. Maybe you can try it yourself with a locally modified version of the crate (the patch section in the cargo manifest can be used to make that easy).

If that's working, the code could then be integrated into the generator, and a simple find & replace should be fine at first if it fixes this issue and clearly is better than the status quo.

[shaicoleman]

I had a quick look, but I'm afraid tackling a new programming language isn't something I have the bandwidth for at the moment